4 ms·

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 b

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.

rep_lodsb 2y ago
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.
- immibis 2y ago
  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.
  - rep_lodsb 2y ago
    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.
    - immibis 2y ago
      Wouldn't it be better to use a header to specify to load multiple sectors at multiple memory addresses?
      - ForOldHack 2y ago
        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)...
    - p_l 2y ago
      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.
- Joker_vD 2y ago
  > 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?
  - p_l 2y ago
    Yes, also probably if you used FDT instead of ACPI despite all the problems that are fixed by ACPI but present with FDT, because "ACPI is evil" :V
  - blueflow 2y ago
    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. FAT originally only can do 8.3 filenames, but take a look at this to see what they hacked on top: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#VFAT_long_file_names https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#... This is all the legacy shit you now have to implement when you want a so-called "legacy-free" boot. Infuriating.
    - p_l 2y ago
      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).
leeter 2y ago
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)
- LiamPowell 2y ago
  I vaguely recall there being some multicore stuff in UEFI, but it's been years since I looked at it.
  - leeter 2y ago
    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. [1] https://uefi.org/specs/UEFI/2.10/index.html https://uefi.org/specs/UEFI/2.10/index.html
    - LiamPowell 2y ago
      It's part of the PI spec rather than the base spec: https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocols.html https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocol...
      - 2y ago

rep_lodsb 2y ago

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.

immibis 2y ago
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.
- rep_lodsb 2y ago
  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.
  - immibis 2y ago
    Wouldn't it be better to use a header to specify to load multiple sectors at multiple memory addresses?
    - ForOldHack 2y ago
      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)...
  - p_l 2y ago
    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.
Joker_vD 2y ago
> 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?
- p_l 2y ago
  Yes, also probably if you used FDT instead of ACPI despite all the problems that are fixed by ACPI but present with FDT, because "ACPI is evil" :V
- blueflow 2y ago
  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. FAT originally only can do 8.3 filenames, but take a look at this to see what they hacked on top: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#VFAT_long_file_names https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#... This is all the legacy shit you now have to implement when you want a so-called "legacy-free" boot. Infuriating.
  - p_l 2y ago
    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).

leeter 2y ago

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)

LiamPowell 2y ago
I vaguely recall there being some multicore stuff in UEFI, but it's been years since I looked at it.
- leeter 2y ago
  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. [1] https://uefi.org/specs/UEFI/2.10/index.html https://uefi.org/specs/UEFI/2.10/index.html
  - LiamPowell 2y ago
    It's part of the PI spec rather than the base spec: https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocols.html https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocol...
    - 2y ago