Example: Kernel Code

This is the follow-up to “Getting Started: Your hobby OS“

This post is about how to begin, it is not a deep technical tutorial (you’ll find plenty of those on OSDev.org), but rather a clear and practical path you can follow.

By observing the most common answers on the question “How do I get started?”

Step 1: The Goal of This Article

When you want to write an OS, you’re not just writing a normal application. You’re building the foundation and ecosystems for future applications.

That’s a lot! So your first goal should be simple:

The osdev Hello World:

“Boot a kernel that prints text on screen.”

It sounds easy, but it’s a actually quite the milstone: Your build tools work, your CPU has booted, the bootloader has loaded your kernel, and your own code is running.

That’s when your OS is officially alive.

Step 2: Your Toolkit

Here’s the toolkit recommended by both the OSDev wiki and experienced developers: • Compiler: GCC or Clang • Assembler: NASM or GAS • Build system: Make or CMake • Emulator: QEMU (preferred) or Bochs • Cross-compiler toolchain: to build for x86 or x86-64

Want to create a custom cross-compiler: Follow this OSDev guide: Building a Cross Compiler

Once those work, then you are ready for your first “hello world,” and get comfortable with your toolchain.

**

Step 3: The Bootloader**

Although it’s a great learning experience, you actually don’t need to start from scratch with raw 512-byte boot sectors unless you want to.

Most beginners use Limine: a modern bootloader supporting both BIOS and UEFI.

There are ready-to-use templates such as: • Limine Barebones (C)

Else you can of course follow the OSDev Wiki Bare Bones tutorial. It walks you through creating a simple C kernel that boots and prints something like:

#lang:c
void kernel_main(void)
{
/* Initialize terminal interface */
terminal_initialize();

/* Newline support is left as an exercise. */
terminal_writestring("Hello, kernel World!\n");
}

That’s your first OS. It’s real, and it runs.

**

Step 4: Growing the Kernel**

Once you can print text, the real fun begins adding layers of abstractions.

A simple roadmap: 1. Switch CPU modes: real → protected or long mode 2. Set up interrupts: timers, keyboard input, exceptions 3. Memory management: paging + heap allocator 4. Drivers: screen, keyboard, disk I/O 5. Filesystem: even FAT12 support is a huge step 6. User mode: load a program, drop to ring 3, and execute

The Creating an Operating System guide outlines these milestones.

When in doubt, check the official Intel Software Developer’s Manual.

Step 5: Theory (Books and articles)

While you code, have a look at: • Operating Systems: Three Easy Pieces (OSTEP): a free, university-level OS textbook praised in nearly every Reddit thread. • Modern Operating Systems by Andrew Tanenbaum: a deep but readable overview. • If you like Rust: Writing an OS in Rust (blog series) by Phil Opp: step-by-step Rust OS tutorials.

Step 6: Communities

There are lots of great communities out there. • OSHub.org for sharing your newest kernel or search for inspiration. • OSDev.org Forum & Wiki • KernelNewbies: great if you want to learn by contributing to Linux. • SerenityOS: a open-source C++ desktop OS; read the code, fix a bug, or build a feature.

Joining a real project lets you see how kernel, userland, graphics, and networking fit together into a operating system.

Step 7: Common Pitfalls (Reddit Wisdom)

• Don’t expect a single “perfect tutorial.” • Every OS dev journey is custom. The OSDev wiki’s Beginner Mistakes page exists for a reason. • Avoid “toy simulators.” Use QEMU or real hardware paths. • Learn C and assembly properly before diving in. • Stay away from higher-level languages (Java/JS) for kernel work. • Take your time, real understanding comes from iteration, not shortcuts.

Step 8: The Mindset

Writing an OS is learning how computers really work. It’s a great exercise with lots of future benefits. No matter what field of computer science you work in.

You’ll touch CPU modes, memory paging, device drivers, interrupts. You’ll fail a lot, but each failure gets you closer to a working solution.

As one developer put it:

“Stay in application programming for a while, understand how everything runs, then peel the layers. OSDev is the hardest but most rewarding kind of software you can write.”