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.01.
2. 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.
3. 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 OSDevvers (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 NIC's ... 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.