OSDev.org

Ok I am a Computer Engineer, I have learn OS theory, I know programming and assembly, I know how an OS works, but it is time to practically implement it. I am going to do in these steps, please tell me if they are right.
1. Build a boot loader
2. Build system command call module
3. Build a GUI module
4. Build a small kernel
5. Build I/O module
Will this be a good approach to build an OS? Basically I am going to do step by step process.

Step 1 is unnecessary (but easy enough, and instructive, so why not).
If by 2 you mean System Calls, I would say they were an integral part of the kernel.
Step 3 - no, no, no! That comes much later.
Step 4 - yes (well, fairly obviously).
Step 5 - again this can be part of the kernel or separate modules.

I would say

1. Set up your memory initialization and management (segmentation and/or paging).
2. Write simple functions to allocate and deallocate heap memory for the kernel to use.
3. Build the tasking part of the kernel; integral to this will be a timer.
4. Set up routines, modules, or even separate tasks to handle keyboard and video.
5. Write System Calls to export the requisite functions to user programs.
6. Write a simple library of functions such as malloc(), printf(), etc. for user programs.
7. Write a simple user program or two. Start with just displaying strings then work your way up to a simple command interpreter.
8. Alongside the command interpreter, write some routines to handle ATA disks.
9. Write code to handle a file system. Ext2 or FAT are probably the easiest ones to start with.
10. More System Calls to handle the above.
11. Improve library of functions to interface with the System Calls and provide simple functions like fopen(), fread(), etc.
12. Now you should be able to refine the command interpreter.

and so on, and so on. That lot should keep you busy for a while.

That's just my off-the-cuff list. Others will, I'm sure, have very different suggestions. But forget about GUIs for the time being.

Actually why is building a boot loader unnecessary??
Thanks for the suggestions, Also should I use Visual Studio for this all along? What about the compiler??
Basically for now I am trying to achieve is, OS,booting, only readable type OS.

0. Read the wiki and manuals for some general ideas.
1. Define your goal(eg. learning purpose), target audience and usage, and features.
2. Read the wiki again for details related to (1).
3. Have a taste of it, follow (but not copy&paste) the babystep and do a working environment.
4. Rethink the question.

There are plenty of good boot loaders available, and it's not the most interesting part of OS development. But it is fairly easy (especially with a little Googling) and instructive, so go for it if you need to learn a little assembler.

I believe some people use Visual Studio, but I suspect that more use gcc or some variant of same. Personally I find Linux to be the most versatile development platform. It's easy enough to run it in a Virtual Machine on your Windows box and I suspect you will find that most examples and documentation are easiest to use in conjunction with the GNU tools; and it's very easy to build a platform specific cross-compiler. But if you are thoroughly familiar with the Microsoft compiler and linker and know how to create binary files with it then it's a possibility

Writing a boot loader is only fairly easy if you want one that sucks. If you want a good one, it's a project of its own.

Kevin wrote:Writing a boot loader is only fairly easy if you want one that sucks. If you want a good one, it's a project of its own.

I guess it depends upon what you want out of a boot loader. If you just want one that will load a raw binary image of your OS and jump to the first instruction, then I would say it's fairly simple. You might say that sucks - I would say KISS. It's all you need for a simple OS project, and it can be instructive.

Of course if you want to write a generic boot loader, rather than an Operating System, that will load various formats of object files then I'd agree that it's a more complex task. In which case you would be far better off using GRUB or something similar. Hence my initial response to the question.

"Good" is such a subjective term.

Long term the bare minimum you'll want to have is loading the kernel in an actual file format (probably ELF) from a file system (probably the various FATs or ext2) rather than a raw disk. Depending on your OS design, you might also want to load some modules or an initrd, and very likely pass some options or a command line.

That will make it big enough that it doesn't fit in 512 bytes any more, so you'll have two options: You get serious and make it a real bootloader, with all the work that is needed for it. Or you build your OS around the limited capabilities of the boot loader and use suboptimal hacks. I've seen the latter happen far too often, that this kind of "KISS" boot loader had a negative influence on the OS design, so that I usually recommend writing the OS first (using Multiboot), and if you then still feel you need your own bootloader, you can still do it...

Well, I found it fairly easy to switch from a custom bootloader to GRUB, but I appreciate that others' mileage may vary. And I think I learnt a lot by going through the whole process of bootstrapping the code and initiating the processor through real mode and protected mode to long mode.

But my aim was always an educational one, rather than any attempt to write a real, competitive OS, so I realize it is not a path that suits everyone; but it is a path to be considered. If I want everything done the easiest way I just install Linux and have done with it - I'll never be able to match that, so why bother?

It's possible just to think about interface of stage 1 boot loader for the kernel and to use GRUB for now. For example, a stage 1 boot loader should provide boot disk/partition identifier for your kernel so you can take same identifier from the GRUB by converting its original identifier if it needs. I use built-in command line in kernel body when stage 1 boot loaders are used, but when Multiboot compliant boot loader is used I use a command line provided by the boot loader.

Kevin wrote:Writing a boot loader is only fairly easy if you want one that sucks. If you want a good one, it's a project of its own.

Kevin, you are damn right!

iansjack wrote:I guess it depends upon what you want out of a boot loader. If you just want one that will load a raw binary image of your OS and jump to the first instruction, then I would say it's fairly simple.

You underestimate difficulties standing on the way of boot loader developer. Strange and rare hardware, buggy BIOSes, extreme lack of space even for throwing debug messages on a real hardware, necessity to get access to buggy PCs, a lot of weird formats even within file system standards, designing a good interface bootloader-to-kernel and bootloader-to-bootloader and many others.
Of course this task is simple enough but only to the extent of "writing simple bootloader for FAT12/16 that works in Bochs".

I think this is getting a little off-topic. I did say in my first post that writing your own bootloader was unnecessary and then elaborated that, nevertheless, it was an instructive exrecise.

If we really want an in-depth debate about how to write a bootloader, and the merits of doing so, rather than dealing with the OP's question perhaps it would be pertinent to start a different thread.

bluemoon wrote:0. Read the wiki and manuals for some general ideas.
1. Define your goal(eg. learning purpose), target audience and usage, and features.
2. Read the wiki again for details related to (1).
3. Have a taste of it, follow (but not copy&paste) the babystep and do a working environment.
4. Rethink the question.

When it says anything with floppy will it work with a USB or work with qemu

Kevin wrote:Long term the bare minimum you'll want to have is loading the kernel in an actual file format (probably ELF) from a file system (probably the various FATs or ext2) rather than a raw disk. Depending on your OS design, you might also want to load some modules or an initrd, and very likely pass some options or a command line.

That will make it big enough that it doesn't fit in 512 bytes any more, so you'll have two options: You get serious and make it a real bootloader, with all the work that is needed for it. Or you build your OS around the limited capabilities of the boot loader and use suboptimal hacks. I've seen the latter happen far too often, that this kind of "KISS" boot loader had a negative influence on the OS design, so that I usually recommend writing the OS first (using Multiboot), and if you then still feel you need your own bootloader, you can still do it...

I'd say a custom boot-loader are for standalone installations of the OS, or at least installations where a large part of the setup is modified. For such a setup, the boot-loader doesn't need to understand all types of file systems, rather it is enough to specify which one it should handle (for instance FAT), and how it would search for modules. Putting the OS at raw sectors is also possible, although a little awkward. A custom boot-loader definitely doesn't need to know file formats, unless the OS creator never heard binary file formats.

iansjack wrote:If we really want an in-depth debate about how to write a bootloader...

No, I don't want.

iansjack wrote:I did say in my first post that writing your own bootloader was unnecessary...

I agree. And I recommend to use any multiboot compliant loader for OS development in educational purposes. GRUB2 will be the good choice.
OP can return to boot-loader development later, when writing file system drivers, if multiboot will not suit the needs.