First off, this _is_ a nice tutorial for what it is. It goes a little further than a lot of similar ones and its easy to follow along. Wanna say that clearly before:
I’ve always found it curious that most OS dev tutorials still focus on x86_32, even though nearly all CPUs today are 64-bit. It’s probably because older materials are easier to follow, but starting with x86_64 is more relevant and often cleaner.
Yes, 64-bit requires paging from the start, which adds complexity early on. But you can skip the whole 32-bit protected mode setup and jump straight from real mode to long mode, or better yet, use UEFI. UEFI lets you boot directly into a 64-bit context, and it's much easier to work with than BIOS once you get the hang of it. You’ll learn more by writing your own boot code than copying legacy snippets.
UEFI support is straightforward, and you can still support BIOS if needed (most old machines are x64 anyway? it's been around for ages now...). Since the ESP partition is FAT32, you can place it early on disk and still leave room for a legacy bootsector if you want dual support. You can even run different payloads depending on the boot method.
EDK2 has a learning curve, but once you understand how to resolve protocols and call services, it’s a huge upgrade. Most of it can be written in plain C. I only use a small inline asm trampoline to set up the stack and jump to stage 2.
Also, skip legacy stuff like PIC/PIT. They’re emulated now. Use LAPIC for interrupts and timers, and look into MSI/MSI-X for modern interrupt routing.
One thing I often see missing in older tutorials is a partition table in the bootsector. Without it, AHCI in QEMU won’t detect your disk atleast on some versions, and this again shows how crumbly and differently implemented some things can be (the ahci nor sata specs require this, so it's a tricky one if it hits you :D...). It’s easy to add, and makes sense if you want multiple partitions. UEFI helps here too—you can build a disk image with real partitions (e.g., FAT32 for boot, ext2/4 for root) and implement them properly. If you don't take into account your system will be using partitions and filesystems within those partitions it's gonna be a lot of re-writing.
Structure of the repo also matters. A clean layout makes it easier to grow your OS without it turning into a mess. This project seems to suggest / imply a nice structure from what I can tell, despite it's also ofcourse modelled around the tutorial itself. - thinking of architecture independence is also often forgotten. Especially when working in newer langauges like Rust that might be apealing ,but most C/C++ code can also be easily made portable if you put foresight into your OS running on different platforms. QEMU can emulate a lot of them for you to test things on.
TL;DR: Most tutorials teach you how to build an OS for 1990s hardware. Fun, but not very useful today. If you want to learn how modern OSes work, start with modern protocols and hardware. Some are more complex, but many are easier to use and better documented which can actually speed up development and reduce the need to port higher level systems over to newer low level code once you decide you want it to run on something less than 20 years old. (Athlon64 was 2003!)
Its actually not though. only certain things are complex, but you will need to play with that either way because they just go from complex to more complex, like virtual memory or interrupts in general.
A lot of newer things offer different ways to design your code and systems around it, more logical and readable ways.
To give an example: it's not easily discovered your machine just emulates pit/pic via IO-APIC routing to LAPIC :') - its transparent! So if you don't know, and someone told you something else that seems to work, there's no trigger for you to even consider it until you stumble across it by chance.
There are many of these things, especially when in QEMU or such platforms. (how fast does your lapic timer run on qemu vs what the intel docs tell u about its speed?)
I’ve always found it curious that most OS dev tutorials still focus on x86_32, even though nearly all CPUs today are 64-bit. It’s probably because older materials are easier to follow, but starting with x86_64 is more relevant and often cleaner.
Yes, 64-bit requires paging from the start, which adds complexity early on. But you can skip the whole 32-bit protected mode setup and jump straight from real mode to long mode, or better yet, use UEFI. UEFI lets you boot directly into a 64-bit context, and it's much easier to work with than BIOS once you get the hang of it. You’ll learn more by writing your own boot code than copying legacy snippets. UEFI support is straightforward, and you can still support BIOS if needed (most old machines are x64 anyway? it's been around for ages now...). Since the ESP partition is FAT32, you can place it early on disk and still leave room for a legacy bootsector if you want dual support. You can even run different payloads depending on the boot method. EDK2 has a learning curve, but once you understand how to resolve protocols and call services, it’s a huge upgrade. Most of it can be written in plain C. I only use a small inline asm trampoline to set up the stack and jump to stage 2. Also, skip legacy stuff like PIC/PIT. They’re emulated now. Use LAPIC for interrupts and timers, and look into MSI/MSI-X for modern interrupt routing. One thing I often see missing in older tutorials is a partition table in the bootsector. Without it, AHCI in QEMU won’t detect your disk atleast on some versions, and this again shows how crumbly and differently implemented some things can be (the ahci nor sata specs require this, so it's a tricky one if it hits you :D...). It’s easy to add, and makes sense if you want multiple partitions. UEFI helps here too—you can build a disk image with real partitions (e.g., FAT32 for boot, ext2/4 for root) and implement them properly. If you don't take into account your system will be using partitions and filesystems within those partitions it's gonna be a lot of re-writing.
Structure of the repo also matters. A clean layout makes it easier to grow your OS without it turning into a mess. This project seems to suggest / imply a nice structure from what I can tell, despite it's also ofcourse modelled around the tutorial itself. - thinking of architecture independence is also often forgotten. Especially when working in newer langauges like Rust that might be apealing ,but most C/C++ code can also be easily made portable if you put foresight into your OS running on different platforms. QEMU can emulate a lot of them for you to test things on.
TL;DR: Most tutorials teach you how to build an OS for 1990s hardware. Fun, but not very useful today. If you want to learn how modern OSes work, start with modern protocols and hardware. Some are more complex, but many are easier to use and better documented which can actually speed up development and reduce the need to port higher level systems over to newer low level code once you decide you want it to run on something less than 20 years old. (Athlon64 was 2003!)