What Order Should I Make Things In?

This is a question of style. You can start at the start and dig straight in, writing a bootsector, then a minimal kernel, and build from there. You could skip the bootsector, and use a ready-made bootloader like GRUB (it's open for discussion whether rolling your own bootloader is a valuable experience or a waste of time). You can also write bits and pieces in no specific order, and just put them together at the very end. There is probably no right or wrong way to go about doing it. If you would like an overview of things that are handy to get working (and are practically a must for every OS), you can keep on reading.

For the starter

1. Printing strings and integer numbers (both decimal and hex) on the screen is certainly a must. This is one of most basic ways of debugging, and virtually all of us have gone through a kprint() or kout in version 0.1.0.
2. Outputting to a serial port will save you a lot of debugging time. You don't have to fear losing information due to scrolling. You will be able to test your OS from a console, filter interesting debug messages, and automatize some tests.
3. Having a working and reliable interrupt/exception handling system that can dump the contents of the registers (and perhaps the address of the fault) will be very useful.
4. Plan your memory map (virtual, and physical) : decide where you want the data to be
5. The heap: allocating memory at runtime (malloc and free) is almost impossible to go without. It should be implemented as soon as possible.

Once those steps are completed, whether you'll try to have a working GUI before you have a filesystem, multitasking or module-loading is completely up to you. Try to sketch out what is likely to depend on what, and do things in 'least dependent first' order.

For instance, the GUI could depend on the filesystem to load bitmaps or resources, but you don't necessarily need bitmaps in your very first GUI. Good advice in such a case is to design the interface of the filesystem first (be it open/close/read/write or something else), and then go on with whatever you prefer, respecting the interface on both sides.

Style Extremes

OSDev seems to have "archetypes" among the OSDevers (and the OS they develop). Of course, the idea that most people have of a "complete" kernel includes most (if not all) of the items listed below.

Lino Commando

Main article: Lino Commando

He's been impressed by the "naked beauty" of DOS times. The first thing he wants to have is a blinking cursor after a ">" symbol so that he can type commands. No matter if there's no way to start two programs at the same time: he just needs a text editor and a filesystem driver.

Nick Stacky

Main article: Nick Stacky

His test-machine has no keyboard and no screen (no one needs that). All he needs is NICs (Network Interface Cards)... plenty of NICs... and an Ethernet cable to see if his kernel responds to pings and routes packets correctly. His kernel has powerful multithreading and a complete TCP/IP stack, of course.

James T. Klik

Main article: James T. Klik

Look through the window: see that background with alpha-blending and the anti-aliased fonts? See the corner of the screen? That's Klik's start menu! Hmm, no: I have no so-called 'programs' folder, as I can't load any applications for now, but here's a 16-items list of test cases for my WidgetToolKit.

Eleanore Semaphore

Main article: Eleanore Semaphore

Works in a dark corner of a small room with listings all around. Her system has much evolved since last year, though all she can show you is still the same: bunches of A's and B's displayed in no obvious order on a text console that she controls with magic key combinations. You hear her talking about how she implemented component programming, auto-dependency-resolving and a virtual clock algorithm for her scheduler.

Alta Lang

Main article: Alta Lang

Why would anyone want to write something as complex as an operating system in something as clunky and old as C? Alta wants something different for her system: a new language for a more elegant operating system. She spends at least as much time on language design as on system design, in the hopes that if she can design the language to be clean enough and powerful enough, the system will simply fall into place.

Stan Dard

Main article: Stan Dard

Stan knows how things should be. It's all nicely written down in standards. He sees how they fit together to form a beautiful system, well, if you disregard all the parts where the standard is stupid. He has a reasonably complete implementation of the areas he knows about and not-terribly-impressive code for the areas he is unskilled in.

Richard Theseus

Main article: Richard Theseus

Richard likes his current OS very much, except for one thing: it's not written by him. Bit by bit, he wants to replace the parts of his current OS with his own code. His ultimate aim is to have an identical copy of his host OS, but with his code.

Mister Perfect

Main article: Mister Perfect

Mister Perfect wants to write a perfect operating system, as he looks at all the flaws current operating systems have. He researches many design and implementation possibilities in order to decide what is better. He starts over multiple times in order to assure quality and perfectness.

Andy Microbaum

Main article: Andy Microbaum

Andy is a fan of small kernels who put much stuff done in a monolithic kernel into userspace.

Dizz Tracked

Main article: Dizz Tracked

Dizz gets distracted by unneccessary side projects.

Mono Lizzy

Main article: Mono Lizzy

Lizzy likes to put everything into one big kernel.

Ideas for new Archetypes

• Edward Scissorhands - Sounds like something designed on paper to do everything but completely broken in practice, I see architecture astronauts rather doing vaporware (e.g. you'd never get to see the Scissorhanded implementation the architecture would require)
• Real Man - Writes an entire operating system in Assembly, preferably in real mode. Abhors Quiche Eaters and Pascal.
• Vizier Studio - Visual Studio people.
• Barry Pi - ARM people.
• Racing Carl - Does all in protected mode Assembler and rewrites the latest 3D library and tries to squeeze the last bit of speed out of the code.

Archetypes to avoid

• Cowboy Coder - Someone who eagerly jumps into coding without any plan.
• Dae Dreamer- Someone who spends all their time day dreaming and reading about operating systems, but hasn't yet started one.
• Duct von Tape - Someone that reuses a lot of code and combines it into a horrible frankenstein of a project. Or perhaps lovecraftian?
• Sir Dunning-Kruger - Someone overestimating his/her skills dramatically.