0. Introductions and Expectations

(the zeroth chapter in our series on How to Write an Operating System)

Writing an operating system is a bit harder than writing a conventional program, by its nature: you're actually writing the code that works the machine and runs other people's code. The lack of debuggers, libraries, and standard code makes it the black art that it has become. You can't debug using traditional methods because you're writing at a lower level than the debugger itself (even the debugger calls the operating system). Libraries are essentially non-existant because each operating system treats the machine in a different manner and it would be extremely difficult to write the libraries for general-purpose use (although there is a move to do just this: see The Flux Operating System Toolkit at the University of Utah). In fact, the only thing we can really do is provide a structure for development and some example working code.

• Programming experience, preferably C or C++ - Since systems programming is harder than conventional programming, it's assumed that if you want to write an operating system, you have at least some programming experience. Hopefully, you know either C or C++ fairly well. You should know pointers, structs and the basic data types, control loops, and the preprocessor well, but don't worry about the standard libraries, ANSI or otherwise, since those are essentially irrelevent in systems programming (you'll most likely have to write these yourself in the later stages).
  
• Knowledge of the architecture - Knowing the assembly language and the architecture of the machine you're developing for is a definite bonus. If you don't know these already, you can pick them up along the way, but it makes development that much harder. SigOPS will be providing a structure for the i386, so if you plan on developing for the PC, you can learn as you go from some of our known good code.
  
• A Machine - You need at least one machine that can be rebooted frequently for testing; preferably, you have another machine for editing and/or compiling. SigOPS may be able to supply one or the other or both of these machines, but that remains to be seen.
  
• Persistence and Mental Stability - I once spent two weeks at work (where I was porting an operating system fulltime) trying to work out a bug that was fixed by changing one bit. Not only that, but all the documentation on the processor that I found was either lacking this critical piece of information or was very misleading, close enough to being actually wrong (and this includes the manufacturer's official documentation). Be prepared to spend a good portion of your time beating your head against a wall.
  

That said, operating system development is some of the most frustrating and also the most rewarding programming you may ever do. To know that your code is the only code running on the machine is a kind of power. It is at once sobering and comforting, knowing that any minor glitch could send it hurtling into a rebooting inferno, but that despite this the machine is still humming blithely along.

By the end of this series, you could have a simple working operating system that runs multiple applications, handling preemptive multitasking, system calls, page faults, interprocess communication, exceptions, and hardware interrupts. It will take a decent stretch of work to get some of the harder bits down, but it is possible, and the feeling of having a working OS that you wrote is incomparable.

Well, you've heard enough introductory stuff to start writing an operating system. So let's begin.

Getting Started