[justinian]

I've seen a number of "build an OS" tutorials pop up recently, and that's awesome! Building an OS will definitely help you understand how to write better user-space programs, and it's fun.

One thing I wish is that more of them would feature UEFI instead of BIOS, or at least come with a warning, as Intel plans to drop support for legacy BIOS in 2020.

Going through UEFI is actually easier anyway, IMHO. ... Maybe I should stop complaining and write that tutorial myself instead. Hmm.

[panic]

Or use the multiboot format (https://www.gnu.org/software/grub/manual/multiboot/multiboot...), which lets you offload the dirty work to GRUB. Writing bootloaders is kind of pointless unless you want to learn about them specifically.

[tazard]

As opposed to writing an OS? I'm pretty sure the target audience for these tutorials are people interested in learning how these things work, not people who know and are writing The Next Big Thing

[exDM69]

The common wisdom with OSdev hobbyists is "if you want to write an OS, don't write a bootloader".

Boot protocols are very uninspiring, arcane knowledge and understanding it does not bring any advantages (unless you want to write bootloaders). Especially dealing with legacy BIOS boot sequence, which is essentially a backwards compatibility emulation layer implemented in the firmware.

It's not like home computers of the 1980s where you'd look at the processor data sheet how the CPU actually boots (which address the program counter starts from, what's the initial machine state, etc).

By far the easiest way to get started in x86 bare metal programming is using the Multiboot header, which is supported by bootloaders (like Grub) and emulators (like QEMU). And you can use GDB for debugging.

Using UEFI is more involved to get started. The initial setup is more involved (you need UEFI headers and libs, etc), the build process is more complex (UEFI images are "Windows" PE executables) and attaching a debugger is not as easy as with a Multiboot-ELF image. UEFI "boot services" provide some nice things that may be helpful to get memory maps and CPU hierarchy so you don't need to go through the hassle of parsing EBDA and MP and ACPI tables.

The legacy BIOS boot protocol is "easy" to get started with (nasm -f bin mykernel.asm), but you have to deal with arcane stuff (like floppy drive BIOS routines, A20 lines), you don't get a debugger. This is by far the worst way to get started. It's not really "doing it from scratch", instead of using a proper bootloader you need to deal with a really bad bootloader implemented in your PC firmware.

[Doxin]

Have you got any reference material on how to get started using the multiboot/qemu/gdb route? I've started (and failed) the BIOS-bootloader route a fair few times now, But I'm not really interested in the boot process itself in the first place.

[msla]

You're allowed to limit how much crap from the 1980s you allow into your life. If you want to learn about the Good Stuff (schedulers, filesystems, TCP algorithms) as soon as possible, jumping a bit and leaving the completely arbitrary bootloader stuff to some pre-written system is completely reasonable.

[nostrademons]

Is there any downside to using the multiboot format for your OS anyway, bootstrapping off GRUB to get started, and then if you really want to learn how everything works, writing a replacement for GRUB? It looks like multiboot is just a protocol that lets you plug in to a bunch of industry-standard software; it can still be quite educational (and easier) to go rewrite both ends of that protocol independently.

[exDM69]

No, there are no disadvantages to using the Multiboot protocol, but there are numerous advantages.

The biggest advantage is that your kernel images are a bootable, debuggable ELF binary.

The emphasis being on "debuggable", you can easily plug in GDB to QEMU and use a proper debugger with your bare metal projects. Using GDB is much better than using the built-in debugging facilities of QEMU or Bochs. You can get the source view, set breakpoints and do everything you normally do in a debugger. In QEMU/Bochs built-in debuggers you have no source view and can only inspect memory and registers - not variables with symbolic names.

Here's some examples and documentation on building a debuggable ELF image for bare metal project, which I contributed to someone else's project:

https://github.com/Overv/MineAssemble/commit/56e317a28d069f4...

[userbinator]

One thing I wish is that more of them would feature UEFI instead of BIOS, or at least come with a warning, as Intel plans to drop support for legacy BIOS in 2020.

The more people keep using BIOS, the more likely it will stay around. IMHO UEFI is a bloated mess compared to BIOS, so I very much hope the latter will continue to live.

[abenedic]

I have my own ideas on why UEFI sucks, mainly around utf-16 and such, but I wouldn't really consider it bloated compared with some BIOS implementations. What is your objection to it?

[bogomipz]

Could you say why the encoding format is an issue for you? Thanks.

[Immortalin]

If you are writing an OS, I highly recommend the Pure64 bootloader from Return Infinity. It's much more straightforward to use compared to GRUB which imposes a lot of conventions on how you structure things.

httpss://github.com/ReturnInfinity/Pure64

[majewsky]

Working link: https://github.com/ReturnInfinity/Pure64

[alias_neo]

Do you know of any tutorials (like OP) that are based off of this?

[tomcam]

Upvoted to encourage you to write that tutorial. Please feel free to harvest my profile email address for any mailing list you might have for it.

[rosege]

AWS and as far as I am aware Azure don't support UEFI so hard to see BIOS going away until that is done.