UEFI exists. You just put a Windows-like binary in a folder on a partition and it runs in a hosted environment in 64-bit mode. And of course there's countless bootloaders that can take care of all this for you too.
This is fine if you're only running on a single core, however if you're a multiprocessor OS you still need to deal with legacy when bringing up the other cores. Intel and AMD should consider a mode that disables that and brings up the other cores using a 64bit SIPI. While I applaud Intel on the X86S idea... I think there is room for bits of that without throwing out all the backwards compat. An X86SC which drops real mode and only supports 16bit 'real mode' in virtualization.
Yes, I see the argument that if you go to that point you might as well just use emulation. However running mixed 32bit/16bit code (Windows 98/95) becomes problematic just because of performance reasons. DosBox does well, but good luck supporting games for the Pentium 3 era that still used 16bit libraries because of course they did. (16bit Installshield was so common going into 64bit that MS just has code to replace it so 32bit applications can still be installed despite having a 16bit installer)
Intel did a prototype of a multiprocessor UEFI application that would start up cores and UEFI itself does support synchronization on the assumption that applications/bootloaders will start other cores before calling ExitBootServices. However, there are no protocols as of 2.10 (the current spec[1]) that I can find that would bring up another processor. That said searching it can be a bit arcane.
Interesting, very interesting. Curious that the PI spec doesn't include update dates on the versions. The MP spec was introduced in 1.5 and I have no idea when that was released.
And then you're free from dealing with the somewhat convoluted processor init stuff, but instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API.
Seems like a bad tradeoff, and part of a slippery slope towards a completely locked down system, where writing your own code and getting it to run on the 'bare metal' is flat out impossible.
> instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API.
Sometimes I wonder: if UEFI instead used ELF format, ext2 filesystem, and somewhat less complicated API (let's be honest: UEFI API is pretty straightforward if tedious), would people still complain about such dependencies? Or would it be deemed to be "fine" since it's not Microsoft technology even though it still would require one to use a multi-megabyte toolchain?
Its not the fact that its from Microsoft, its the fact that both FAT and PE are full of legacy cruft that is no less painful than going through real mode in the first place.
Meanwhile ext family, even in ext4, requires that you handle optimizations decisions made for Fujitsu Eagle and its contemporaries.
I could easily read NTFS with hexeditor, calculator and pen&paper. Trivial even (most annoying part was the run length packing in 4-bit nibbles).
I gave up trying to read ext's cylinder-oriented mappings.
And FWIW, everyone has a read/write driver for FAT with LFN (and UEFI generally avoids names outside 8.3 just in case), using a different filesystem would lead to issues with OS support.
PE itself isn't really that much of legacy cruft, especially as far as it is used in UEFI (sure, you have the "program not for MS-DOS header", but that's useful for the rare case someone tries to open it under FreeDOS).
What's wrong with depending on the Windows PE format, FAT filesystem and UEFI? You're always going to have some dependencies. FAT32 is better than having the first sector load some magic reserved sectors. Windows PE is better than a fixed memory address.
It's adding pointless complexity, and baking assumptions about how an OS should work into the firmware. Loading a sector at a fixed memory address and jumping to it (with some function provided so that your code can go on to load other sectors) is both easier to understand, and doesn't require you to use some multi-megabyte toolchain.
Unless you need to load anything else other than what's in that sector, because you can't fit enough I/O drivers into one sector to load the rest of the OS.
Unless you're targeting S/360, but even there XA and newer made it a bit more complex.
Yes, and considering that your boot sector is actually a boot cluster... You need not use compression. You could even steal the entire first cylinder. (Now that is old school)...
Yes, I see the argument that if you go to that point you might as well just use emulation. However running mixed 32bit/16bit code (Windows 98/95) becomes problematic just because of performance reasons. DosBox does well, but good luck supporting games for the Pentium 3 era that still used 16bit libraries because of course they did. (16bit Installshield was so common going into 64bit that MS just has code to replace it so 32bit applications can still be installed despite having a 16bit installer)