4 ms·

Looking at the download sizes: UEFI "native" 114kb Windows version 1.4mb VHD version 12.6mb None of them are huge but it does emphasize how much difference

Looking at the download sizes: UEFI "native" 114kb Windows version 1.4mb VHD version 12.6mb None of them are huge but it does emphasize how much difference in resource savings is available if your program can run directly on "bare metal" without even an OS at all.

ale42 1mo ago
Not sure why the Windows version would be much bigger than the bare metal one. If you use native code, the code size overhead from using native GDI calls to draw the window is almost zero. Didn't check if the Windows version uses some GUI toolkit that inflates the size.
- skrellm 1mo ago
  > Not sure why the Windows version would be much bigger than the bare metal one. That's probably because there's a bug in the linker, which puts uninitialized variables in the data segment instead of bss. This means unlike the bare metal variant, the Windows executable is full of zeros. This is a well known bug (see https://github.com/msys2/MINGW-packages/issues/18612 https://github.com/msys2/MINGW-packages/issues/18612 for example) which also affects my projects: https://gitlab.com/bztsrc/skandi https://gitlab.com/bztsrc/skandi The Linux CLI version is 216K, the Windows CLI version is 5.4M and the only difference is the lack of bss.
convolvatron 1mo ago
UEFI supports device discovery, TCP/HTTP, transfers to raw disks, filesystems, memory management and a bunch of other facilities. while it lacks a general process model and multitasking, I'm not sure its really correct to call UEFI programs bare metal.
- skrellm 1mo ago
  > I'm not sure its really correct to call UEFI programs bare metal. I think you can. UEFI is a firmware which comes with the hardware, stored on the motherboard. It's there and automatically runs when you turn on your machine. It's okay to consider the firmware part of the "bare metal", IMHO.
  - ale42 1mo ago
    > It's okay to consider the firmware part of the "bare metal", IMHO. On a PC I would think so. Using UEFI is not much less bare metal as using BIOS calls, at least. OTOH on an embedded device it would already sound so much less bare metal... I find it's a tricky question.

ale42 1mo ago

Not sure why the Windows version would be much bigger than the bare metal one. If you use native code, the code size overhead from using native GDI calls to draw the window is almost zero. Didn't check if the Windows version uses some GUI toolkit that inflates the size.

skrellm 1mo ago
> Not sure why the Windows version would be much bigger than the bare metal one. That's probably because there's a bug in the linker, which puts uninitialized variables in the data segment instead of bss. This means unlike the bare metal variant, the Windows executable is full of zeros. This is a well known bug (see https://github.com/msys2/MINGW-packages/issues/18612 https://github.com/msys2/MINGW-packages/issues/18612 for example) which also affects my projects: https://gitlab.com/bztsrc/skandi https://gitlab.com/bztsrc/skandi The Linux CLI version is 216K, the Windows CLI version is 5.4M and the only difference is the lack of bss.

convolvatron 1mo ago

UEFI supports device discovery, TCP/HTTP, transfers to raw disks, filesystems, memory management and a bunch of other facilities. while it lacks a general process model and multitasking, I'm not sure its really correct to call UEFI programs bare metal.

skrellm 1mo ago
> I'm not sure its really correct to call UEFI programs bare metal. I think you can. UEFI is a firmware which comes with the hardware, stored on the motherboard. It's there and automatically runs when you turn on your machine. It's okay to consider the firmware part of the "bare metal", IMHO.
- ale42 1mo ago
  > It's okay to consider the firmware part of the "bare metal", IMHO. On a PC I would think so. Using UEFI is not much less bare metal as using BIOS calls, at least. OTOH on an embedded device it would already sound so much less bare metal... I find it's a tricky question.