It's a great write-up (follow the next parts if you've only seen the 1st one)
I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
It's pretty damn easy:
1. You don't write a bootloader since UEFI is that bootloader.
2. You write a portable executable which gets executed by the UEFI bootloader. This executable runs directly in long-mode without any nonsense.
3. You have to link against some different C-libraries, not the standard ones, but that's about it.
Here's an example: http://x86asm.net/articles/uefi-programming-first-steps/
That doesn't really seem very representative of reality. UEFI basically takes care of all the terrible legacy stuff for you, so you don't have to.
You can just focus on the OS, built on a modern architecture.
See my other comment regarding BIOS vs UEFI: https://news.ycombinator.com/item?id=15517300
If you also try to compare UEFI vs BIOS on a deeper technical level, UEFI also seems to come out in a favourable way: https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-...
The only "complex" part about it, is that you already know and have come to terms with all those terrible & complex things which booting a OS from legacy BIOS-mode entails, but UEFI while simplifying a million things is still different and something you haven't learned yet.
But that means complexity. E.g. BIOS just loads the first 512 bytes from a volume into memory; UEFI requires FAT filesystems, with paths &c. BIOS routines can easily be called from assembly; I don't know if UEFI routines can, or if the EFI Development Toolkit is required (I could find out, of course — but that's part of the learning curve).
I have no doubt that once I learn it all I'll prefer UEFI. But, as I said, the learning curve is daunting.