moonchild wrote:but I have to say I prefer it (UEFI) to the broken mess of variable-quality BIOS implementations.
The truth is, UEFI is even buggier than BIOS. This is because UEFI is lot more complex, there are lot more ways to mess it up. The things you really need to rely on booting your OS are much much stable in BIOS.
In BIOS you have one call, E820, no funny business. That wiki page lists ALL HISTORICAL solutions too, back to the 386. In reality E820 is supported and is all you ever need for a machine manufactured in the last 20 years or so. FYI, the wiki page you linked says: "By far the best way to detect the memory of a PC is by using the INT 0x15, EAX = 0xE820 command. This function
is available on all PCs built since 2002, and on most existing PCs before then.".
No, it won't. Not for you that is. It is true that UEFI may run in long mode, but you simply can't use that environment. You don't know the GDT. There's no IDT. You only have identity paging. At the end of the day you'll have to set everything up for yourself, regardless which firmware you're using.
moonchild wrote:I think it would be quite nice if there were a smaller api without so much unnecessary junk.
So true!
moonchild wrote:But given that things are as they are; given a choice between BIOS interrupts and UEFI, I would choose UEFI every time.
I'm not my own enemy. On qemu, booting from UEFI takes about a minute (!), while BIOS boots almost instantly. When you do rapid development-testing cycles, UEFI could waste your time the big time. Full disclosure, my boot loader supports both, UEFI for real (and new) machines, and BIOS mainly for virtual machines and maybe old real machines.
You don't need to choose between UEFI and BIOS, you can easily support both
moonchild wrote:BIOS is usually (badly) emulated on top of UEFI anyway.
I never had any issues, well ever. All the functions I need are emulated perfectly, however I had issues with UEFI many times (mostly some protocols not supported on real machines). For example, you must be prepared that BlockIO is unavailable under UEFI, however you can always use BIOS int to read sectors.
moonchild wrote:And fwiw I have never had any trouble booting OSes with UEFI.
Then you haven't tried enough real machines.
moonchild wrote:I did have a problem where windows 10 would overwrite my settings to make itself the top priority bootloader—maybe that's what you experienced?—but that's a problem with windows 10, not UEFI.
No, Nexos are talking about Secure Boot in UEFI, where firmware essentially only allows Windows to boot. In theory it could boot anything that's signed by one of the KEK keys, but in practice there's only Microsoft's key installed by the manufacturer, you can't install further keys, and Microsoft only signs its own OS, nothing else. Even if they sign some third party tool (like shim), they always create imaginary problems from time to time to not to boot them (just take a look at their latest Grub "fix" which broke all debian, RedHat, Fedora and Ubuntu machines and had to be recalled.).
moonchild wrote:The UEFI api is very unimaginative. Sometimes it seems like all the functions have the exact same prototype. (Vulkan is similar.) It's not a joy to work with, but it does mean that once you've grokked its model it mostly gets out of your way and you can get out of its way.
Yes, UEFI API is insane. About the last part, I wish that were true. In reality you never can take granted that a protocol (a certain API) is actually supported on a particular firmware, which makes UEFI applications complex.
moonchild wrote:I want to be clear that I'm not happy with any of this. But UEFI is definitely the least bad option for x86 pcs today.
As being someone who wrote both UEFI and BIOS loaders, I disagree. Most third party (non Intel-MS) developers agree with me, including Linux Torvalds. BIOS is simple, and so old-school that nobody wants to use it for any other purposes than booting. UEFI is overcomplicated, and you can't get rid of it during runtime. Even if your OS doesn't use it, UEFI will waste your computer's resources. Look: BIOS needs only 384K memory (1M-640K), while good luck running UEFI with less than 64M of RAM... And there's the thing that BIOS boots almost instantly, while UEFI is slow like a pregnant snail.
Conclusion: UEFI is not better, not smaller, not faster, not simpler than BIOS. But it is the only option forced on us by Microsoft. So like it or not, if you ever want to run your OS on a (relatively modern) real machine, you must support it.
Cheers,
bzt
.
