As most people who read this blog will know I’m currently developing a small 32Bit Multi-tasking Operating System called ‘MouthOS’. I figured that I’d start sharing my thoughts and ideas of the development with you all so that, should you be a fool like me, you can write your own OS!

The hardest part of writing an Operating System is where to start! Many people will say ’start wherever you like’. Others will give you warnings about trying to develop ‘Graphical User Interfaces’ straight away. Others will suggest that you do a lot of reading of books relating to Operating System design theory. This is all good advice, and whilst I don’t pretend to be an expert, in my opinion there are three even more important things to consider when starting to develop an Operating System:

1. What do you want your Operating System to achieve? Many will say be realistic here - don’t be thinking graphical user interfaces and to a certain extent they are correct. However, if you do want to have a graphical user interface this will effect your initial development - you will have to think about interrupts etc. Also this will affect your architecture - is your OS for a washing machine or is it for a fully blown desktop computer?
2. This brings me onto the next thing - do you know the architecture that you’re going to be developing for? This means understanding what the registers do on your chosen CPU, how the CPU deals with interrupts, what extra features the CPU may or may not have, how the CPU starts execution (where does it get its first instruction from?), how much RAM can it address, and also knowing the assembly language for your chosen architecture.
3. Once you know your architecture this leads to my final question - what language are you going to develop in? Pure assembly, C, Java, Python? If you’re planning on using Java or Python (or any other interpreted language) you’re going to have to go back to the drawing board - it simply won’t work.

Once you’re comfortable with what your OS is going to achieve, what language its going to be written in, and what it will run on you can start with the boot-loader. In x86 the boot-loader takes over from BIOS. In SPARC the boot-loader takes over from OBP etc. Boot-loaders can be as simple or as complex as you like.

In x86 (as MouthOS is coded in) your boot-loader could directly start calling kernel code, or it could setup the environment, for example setting up the GDT (Global Descriptor Table), IDT (Interrupt Descriptor Table), enable the A20 line and entering into 32Bit Protected Mode. This really depends on what you want your OS to do. If it’s just print some text on screen then there is little point with memory management and 32Bit instructions. However, if you’re planning on having graphics, multiple applications, and if you want to be able to address more than 65K of memory then 32Bit (or even 64Bit) is the way to go. There is loads of information available on the Internet relating to boot-loaders. However, if you’re struggling to find it a good place to start is the wiki and forums at OSDev.Org.

Personally I decided, after the second write of MouthOS, that I was going to use GRUB as my boot-loader. Using GRUB provided a nice way to get into my kernel as GRUB deals with all the above mentioned tasks such as enabling the A20 line, setting up the GDT, getting into 32Bit Protected Mode etc - in essence it puts the system into a known state ready for the kernel. However, even if you’re going to use GRUB at some point (and best sooner than later) you need to re-write the GDT, IDT etc. The reason for this is that you don’t know what GRUB has used for these values and so you could have various things such as users applications overwriting your kernel etc.

This is where I’m going to leave it for now. However, in my next few posts relating to OS development I plan to go over some x86 specific questions like how to implement simple putchar, puts, memcpy functions for your C library. I’ll also cover some other things that you, as budding OS developers, should know - such as how paging and virtual memory work, and where to being when writing a scheduler.

This entry was posted on Thursday, December 27th, 2007 at 4:40 pm and is filed under MouthOS, Operating Systems. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.