Binary blob sources

[ttlns]

Where are the binaries in https://github.com/grub4dos/ntloader/tree/main/utils/rootfs from ?
And also, are they used in the build process?

[a1ive]

These files come from the Windows Server 2025 and Windows 10 ISOs, and they are packaged into initrd.cpio.

In general, bootloaders from newer versions of Windows can boot older versions (except for Windows 7).

You can also extract the corresponding files from your own Windows installation to replace them.

[a1ive]

Do you think Windows 11 22h2 from https://go.microsoft.com/fwlink/?LinkId=2156292 is suitable here?

I would prefer using Server 2025, since it provides more features, such as the ability to boot systems located on ReFS partitions.

correct? Or should by default the x86 (32-bit) versions be used?

Looks good.

Also, is utils/bcd as well from an installation media (maybe x64\Windows Setup Media[1]\boot\bcd )?

No, the BCD is generated by utils/bcd.bat in Github Action ntbcd.

[a1ive]

The path of bootmgr.exe should be x64\WindowsPE[2]\Windows\Boot\PXE\bootmgr.exe.
(Although it can also be extracted from bootmgr using the bmtool utility provided in this project.)

[ttlns]

I would prefer using Server 2025, since it provides more features, such as the ability to boot systems located on ReFS partitions.

The Server releases unfortunately aren't available over https://go.microsoft.com/fwlink/?LinkId=2156292

I've seen that uup-dump uses another undocumented API (fe3.delivery.mp.microsoft.com) which I believe is the reverse-engineered MS-store api.
There's a standalone version which can run locally - will check that out.

The path of bootmgr.exe should be x64\WindowsPE[2]\Windows\Boot\PXE\bootmgr.exe.

Ah yep, thanks, wasn't sure about this one.

[ttlns]

I found the following files for Windows Server 2025 (26100.2314) amd64 on uupdump

1. ServerDatacenterCore_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/f07cd6e3-576a-4365-a221-d471582dadc5?P1=1757615713&P2=404&P3=2&P4=ZrncZxSwxlK%2fxTIYxQFzl054C2gfAweTmj3qnNoOVr7at7GUDo0C51EFYJssxJvHMv8DlcxV0Uj%2bDTQVb5mP4Q%3d%3d
2. ServerDatacenter_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/c8e7fcce-0aa1-4b8a-8917-16f8bd418e17?P1=1757616713&P2=404&P3=2&P4=bFXCFUKvZ6IDQVjoAgJG%2bXS0opaPsJtR4Cw5b7PxMDRgver1VHAz7BGA7%2b%2bm0dwVnzEn4gdt%2br06u6icAUYptg%3d%3d
3. ServerStandardCore_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/90dcbdbe-315e-4a3d-a029-d6a5d9357f71?P1=1757615713&P2=404&P3=2&P4=g5s%2b0QRWr1P%2fF%2fpvCsxHtoAl35F4lxxGLU46ULaThchVehtzWFkrslNBZ%2fcNIqNBR%2bsvASO9NNMEOl0sjoZPdw%3d%3d
4. ServerStandard_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/e6af25f6-b91c-4cc0-be86-e1055a1536ca?P1=1757616713&P2=404&P3=2&P4=Kltodfc0Bzx9djvW4nwEmoqXJp1e%2f7eXu0GHPbkHDBaErO%2fkCGGMxQJeTTj5jgly6yFmMehFDG%2bimw9LpfVyeA%3d%3d
5. ServerTurbineCore_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/851aaf50-4ed0-4017-afc5-22eeb0b73df3?P1=1757615713&P2=404&P3=2&P4=BgRF4xwMpAvldnK9kQ%2fMUQG9TFs1Jpo%2bVRZZN8Oddqhq3lOaYUDb9JKsdYEOjl9xIWaJw1vAWuHIemXeIOp8QQ%3d%3d
6. ServerTurbine_en-us.esd http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/6be3b434-9e03-4f35-a845-785a551009cc?P1=1757616713&P2=404&P3=2&P4=EyYee3keVMk%2fPolIdsTFc%2bBDZcJD55uATbDXJRlYjfo%2fOJCTg2Ack4SBFcLcDdY%2fnfpPNOQ5bDY%2b1LgA9NaUvA%3d%3d

what edition is preferable here?

Arm64 is available at https://uupdump.net/get.php?id=d423cda1-ea9d-4242-8c83-ec20630514ad&pack=en-us&edition=serverdatacenter%3Bserverdatacentercore%3Bserverturbine%3Bserverturbinecore%3Bserverstandard%3Bserverstandardcore (only prerelease),
There are no Server 2025 distrinutions for x86 32-bit afaik. I'm assuming win11 is the way to go in that case.

[a1ive]

The bootmgfw.efi files from these editions seem to be the same, so I think ServerStandard should be fine.
For ARM64, I think using Windows 11 is fine.

There are no Server 2025 distrinutions for x86 32-bit afaik. I'm assuming win11 is the way to go in that case.

As for x86 (32-bit), starting from Windows 11/Server 2025, IA32 is no longer supported, so I extracted bootmgfw.efi from Windows 10.

[ttlns]

How does licensing work with these files btw?
e.g. do we//should we add a notice?
Afaik, the EULA and Microsoft License terms apply here. For Windows 11 22h2 Professional, that's https://download.microsoft.com/download/C/0/3/C036B882-9F99-4BC9-A4B5-69370C4E17E9/EULA_MCTool_EN-US_6.27.16.rtf and https://www.microsoft.com/content/dam/microsoft/usetm/documents/windows/11/oem-(pre-installed)/UseTerms_OEM_Windows_11_English.pdf .

For Server 2025, that's https://www.microsoft.com/content/dam/microsoft/usetm/documents/windows-server/2025-datacenter-and-standard/oem/UseTerms_OEM_WindowsServer2025_DatacenterAndStandard_English.pdf

See also https://www.microsoft.com/en-us/legal/intellectualproperty/copyright/permissions

If your license terms do not grant redistribution rights for a particular software file and you need assistance with your software, visit Microsoft Help and Support. For software downloads, unless expressly permitted in the accompanying License Terms or End-User License Agreement (EULA), Microsoft does not allow redistribution. You may link to the download page, but not directly to the download, from your product or website.

I'd guess that, to be safe, you'd have to download the files at build time, and require the user to build ntloader themselves which is inconvenient.

EDIT: EULA only applies to the end-user.

[ttlns]

wimboot requires the user to place the files.
I'm not sure if//where quibble uses them.
wimiso doesn't provide a license at all.

What's stopping us from dynamically linking//using these files from the wim/vhd/vhdx image? I bet this would improve compability for different windows versions as well.

[a1ive]

It's violates Microsoft’s license agreement, and I’m fully aware of that.
Files from Microsoft only exist inside initrd.cpio. Strictly speaking, the best approach would be not to provide a prebuilt initrd.cpio, but instead let users generate it themselves (the instructions are already documented here: mkinitrd
).

However, in practice, most users find it inconvenient and are not concerned about whether this violates Microsoft’s license agreement.

[a1ive]

I'm not sure if//where quibble uses them.

Quibble fully implements the main functionality of the Windows Boot Manager, so it does not require any files from Windows.

wimiso doesn't provide a license at all.

Yes, I once discussed this with longpanda. We agreed that if these files were not provided directly, basically no one would be willing to use them.

What's stopping us from dynamically linking//using these files from the wim/vhd/vhdx image? I bet this would improve compability for different windows versions as well.

For WIM boot, it’s generally possible to load these files directly from the WIM at runtime (this is how wimboot works).
https://github.com/ipxe/wimboot/blob/e97d88a0cfd84817144a224745f365eb6ee529c0/src/efifile.c#L39

For VHD/VHDX boot, it’s theoretically possible as well. However, in practice it’s much harder: it would require implementing VHD/VHDX parsing, NTFS/FAT/exFAT reading, and we don’t even know the exact location of bootmgfw.efi (it might not even exist).