Is this site legit?

[NUj6URfi]

Is this legit or will it delete my current OS?

http://mikeos.berlios.de/write-your-own-os-winbuild.html

[N36fSL3A]

Your OS shouldn't let a program have that much control.

[NUj6URfi]

What do you mean? I know I would have to learn x86 and modify the code to make a true operating system and not just a line of text but is this legit?

[chrisname]

Ignore Lumpkin; he's just self-assuredly spouting nonsense despite having not understood the article, as usual. It's a tutorial on building an OS called MikeOS on Windows and creating a floppy disk image file and CD image file (ISO) for booting the OS on an emulator. You could also copy the image file to a real floppy disk using a utility like dd and boot it on your actual hardware but that might be ill-advised if, for example, the OS writes to the hard drive willy-nilly. IIRC, MikeOS is an OS specifically created for teaching basic OS development and it is legit, so it probably won't trash anything (from what I can see, this tutorial doesn't even involve hard disk access) but it's still best to stick to emulators for hobbyist OSes until you're sure they're safe.

p.s. berlios.de is a trustworthy site; it's a bit like GitHub or SourceForge but it's specifically for OS development. That said, since its content is user-submitted I'd still be a little wary, although like I said I've heard of MikeOS before and it's legit.

[NUj6URfi]

Thanks. Also, is there any way to write an assembly boot loader but have a c++ os? All I want is an Iso and not something that erases my hard drive though.

[Dy7SLyTq]

firstly, yes you can have an assembly boot loader and a c++ os. this is because bootloaders arent a part of the os, just mount it (someone please correct me if im wrong) and it will only erase your hard drive if you tell it to. if you just want an iso i would suggest making it bootable off a disk instead of a hard drive. and in case you want to know: http://www.jamesmolloy.co.uk/tutorial_html/index.html

[chrisname]

You should probably not write your own bootloader if you want to write the OS because a modern bootloader is about as complex as a smallish OS anyway (and probably without much scope for code reuse since the bootloader generally uses the BIOS whereas an OS wouldn't).

You can write your OS in C++, but it's a little harder because you have to write code to set up constructors and destructors, handle exceptions, etc. so it'll take a little bit longer to get your OS into a working state. Plus, you won't have the standard library, so you'll have to implement much of that yourself (although the same is true of C, the C standard library is much smaller than the C++). Don't let that discourage you from using C++ though - having that platform will make the rest of your OS easier to develop and it would probably be more robust given C++'s extra safety, although having all that extra code increases the risk of bugs. You could probably find a library for it. I'm actually working on my own minimalist implementation of the C++ standard library, but I've not yet implemented even one half of the C standard library, let alone C++.

[BHX]

Like everyone said, ignore Lumpkin. The knowledge he claims to have is becoming obviously absent. That article is good and there were two other sites I used to read at when I thought about making my own OS.

http://wiki.osdev.org/Main_Page OS Dev
http://www.osdever.net/ Bona Fide OS Developer (redesigned, but tutorials section is filled with good articles)

[NUj6URfi]

How do I do it while still implementing Mike's code from:

http://mikeos.berlios.de/write-your-own-os-winbuild.html

[chrisname]

Read the wikis that BHXSpecter linked. That's what I did. Don't just skip to their tutorials, read everything you can and actually understand it rather than just copying it (I made that mistake for a while and ended up with bugs that I couldn't solve, partly due to copying code incorrectly). Get the documentation as well -- if you're developing for x86, get the Intel and AMD manuals (you should read both and cross-reference them because they sometimes make subtly different recommendations or explain things in different ways). If you focus, you can get a smallish OS up-and-running in two years, although you should be able to get *something* in a few weeks, or less depending on your priorities (I did text output first so I had that working in a few hours, but some people like to start with the guts of the kernel and implement a pre-emptive, prioritising scheduler with multithreading first). If you're like me and you switch between projects frequently it will obviously take longer unless you dedicate proportionally more time to it. Basically don't expect to have a fully-functioning OS done in a few weeks. It'll likely take years and years of hard work. The hardest part is debugging because you don't actually have a debugger unless you write it yourself*. Something like Valgrind would be a godsend but it's not really possible.

* most emulators have basic support for inspecting stuff like registers and the stack, and you can even attach GDB to Qemu via the network, but that's not actually that useful for diagnosing most bugs. In my experience, most bugs have had to be caught with lengthy code audits, where you literally just follow the path the CPU takes through the program over and over again until you spot the problem and figure out how to fix it. Writing debugging code often doesn't work because most of your early bugs will take down the entire OS -- I can count on one hand the number of times I actually had time to read an error message because when a certain type of error, called a triple fault, occurs, the CPU just resets. You get past that stage eventually, but honestly, the worst programming experience of my life are from booting the OS over and over, poring over hundreds of lines of code without even the remotest hint of what was actually wrong -- especially when the error only occurs some of the time. I don't mean to discourage anyone, though: most of my best programming experiences have been OS dev related as well. One time I jumped out of my seat, punched the air and screamed "YES!" when I finally fixed a bug that had been plaguing me for months.

[Cubbi]

you don't actually have a debugger unless you write it yourself

Perhaps more hobbyists should make that a priority. I worked for a commercial OS vendor for a while, and breaking into the kernel debugger was the only way to even approach most bugs in the scheduler and other kernel-space components.

[chrisname]

Agreed, but even if I had written a debugger, some of the early bugs that triple faulted the system early on in the boot process would have rendered it useless. The worst bug, the one that had me stumped for months, was in this function:

static void gdt_entry(i32 i, u32 base, u32 limit, u8 access, u8 gran)
{
    gdt_entries[i].base_low     = (base & 0xffff);
    gdt_entries[i].base_mid     = (base >> 16) & 0xff;
    gdt_entries[i].base_high    = (base >> 24) & 0xff;
    gdt_entries[i].limit_low    = (limit & 0xffff);
    gdt_entries[i].granularity  = (limit >> 16) & 0x0f;
    gdt_entries[i].granularity |= gran & 0xf0; /* 0xf0, not 0x0f. */
    gdt_entries[i].access       = access;
}

That comment is in the actual code because I wrote 0x0f by mistake the first time and didn't notice for months.

[NUj6URfi]

Though if I were to write this all in assembly would I use put the assembly code in the same file as my boot loader? I used mikeos for a boot loader for now.


EDIT: Link is above.

[NUj6URfi]

Well?

[NUj6URfi]

Please?

[BHX]

First, we all have lives outside this site and we will reply when we can.
Second, we have given you all the information we can to make you self-reliant, we are not going to do the work for you. The two sites I gave cover the entire process in form of articles and tutorials. Sift through them and you will get a better grasp of what you need to do.

[NUj6URfi]

Problem is:
a) I don't want a kernel
b) I don't know assembly
c) I don't know where to put the os code like in a different file or what
d) I don't know how to get a c++ binary file

[Dy7SLyTq]

a) I don't want a kernel

thats like saying you want a sundae without icecream. you need a kernel for an os to function

b) I don't know assembly

then learn it. os dev isnt meant to be easy

c) I don't know where to put the os code like in a different file or what
d) I don't know how to get a c++ binary file

you put it in the file it tells you to

d) I don't know how to get a c++ binary file

no such thing. are you talking about .bins, exes, coms, a's, o's, etc? and also get what binary file?

[NUj6URfi]

You do not need a kernel. You can just have a few simple text documents that represent passwords and all that stuff. Maybe for drivers you need something but I'm not at that stage yet.

Where can I learn assembly though?

What do you mean where it tells you to? I could just put it right after my bootloader and hope for the best.

.bin stands for .binary.

[NUj6URfi]

Or does a few text documents for password and that stuff count as a kernel?