Since I was little, I’ve always been interested in operating systems for some reason. When I got started “programming” using Scratch at around the age of 6, I wouldn’t create games. Instead, I would be a part of this Scratch community creating “Operating Systems”. Of course they had not much to do with real operating systems , it was just a “desktop” with some applications, but even though they weren’t useful, and could not be ran standalone, it was a lot of fun doing it back then ( Everything is still here, beware of the cringe).
After I few years I came back to the idea of writing my own OS, this time one that can actually run, and since I got into electronics, mainly microcontrollers I also wanted to learn C. At that time, I have been long running Linux, so setting up a compiling environment was easy (as it turned out later, I actually had no clue) and I just went with a tutorial online, which was actually the first mistake: Never use tutorials. They are usually written by one person ,often inexperienced and can’t be edited by the community, meaning it also comes with all the mistakes. This was enough to get me hooked though, and the same sleepless night I’ve written my first line of code of what was to become Hydrogen. I’ve also found osdev.org, which later turned out to be a goldmine, together with the community on the #osdev channel at freenode on which i tend to hang around pretty often.
Here are some hints and experiences if you want to get into it too:
Hint 0: Don’t look for code
Learn osdev from reputable sources. Use the osdev wiki. Use the osdev forums. Use #osdev. Use the Intel and AMD manuals. Do not follow articles that have not been peer reviewed, or are not community editable.
Hint 1: Read, read, READ
Books are usually really good resources, since they are (usually) written by people that know a lot about a certain subject. As mentioned earlier, the OSdev wiki and community is also a goldmine, and if you are going for something more than “hello world” you are going to find yourself there more than often. I also strongly recommend you stay away from non-community edited tutorials that will often be low-quality, wrong and nobody can correct them!
A good starting point would be this
Hint 2: Write things well
Now, everyone sees “good code” differently, but main point is: Don’t think “I will correct/redo this later, its good enough” because the truth is: You won’t, or it will be really hard (see the next hint) and you will end up doing double/triple work.
Hint 2.5: Don’t leave code behind
If it happens that your coding style from before was bad (it was), don’t leave it behind, correct it instead, it will make life easier for you. It might be something small like “unsigned int” instead of “uint32_t” but it actually matters a lot, and when you have 500 lines of code with that… It’s not fun correcting it.
Hint 4: Don’t skip things.
When I’ve started i used to assume stuff was done for me, for example that memory is 0, hardware has always same settings at boot and i don’t need initialize anything. Turned out i was wrong when my page table had garbage entries.
Hint 5: Be unique
Please, don’t call your system “MyOS”. There are already dozens of these ALL WITH THE SAME NAME. A good example of original naming are: ToaruOS (とあるOS), Moonix, Hydrogen, Sortix, Glaux, Haiku to name a few. See, it can be done! Yes, ToaruOS is “*OS”, but it is actually a joke on “MyOS”.
Hint 6: Know what you want
Know what you want to get from OSdev, don’t let anything other than you decide what you get out of it.
Hint 7: Don’t overcomplicate stuff
Make things as simple as possible, but no simpler.
Hint 8: Know your enemy
Learn how existing systems work, how other people do things, competing ways of doing it. Make a choice, don’t let someone make it for you. After you’ve done that, learn about the practical implementation of the solution.
Some of the above “hints” also apply to programming in general, not OSdev specifically.
I hope this helps someone, OSdev is a hard but fun hobby, and brings you a lot of satisfaction if you are persistent in going forward.
Thanks to sortie for helping me write this.