Binary blob sources

[kaliiiiiiiiii]

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.

[kaliiiiiiiiii]

I’m not sure if this can be done using UUP Dump?

For verification if microsoft takes down the api, yes.

For initially getting the files, microsoft themselves might be the more trusted source though.

[kaliiiiiiiiii]

If not, would pinning them to a specific version (or maybe providing the source ISO's) be an option? e.g. to make them somewhat verifiable.
I can also create a pr if needed.

That would be greatly appreciated if you could.

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

So I'm assuming I can use latest then. Do you think Windows 11 22h2 from

</File>
    <File id="">
    <FileName>19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_x64FRE_en-us.esd</FileName>
    <LanguageCode>en-us</LanguageCode>
    <Language>English (United States)</Language>
    <Edition>Professional</Edition>
    <Architecture>x64</Architecture>
    <Size>4164077935</Size>
    <Sha1>e35f49be74010d22e1bf9d2f200e48f3f7fd0a66</Sha1>
    <FilePath>http://dl.delivery.mp.microsoft.com/filestreamingservice/files/f7d48c2e-eb2c-4f13-97e1-45a08c90bcfe/19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_x64FRE_en-us.esd</FilePath>
    <Key />
    <Architecture_Loc>%ARCH_64%</Architecture_Loc>
    <Edition_Loc>%CLIENT%</Edition_Loc>
    <IsRetailOnly>False</IsRetailOnly>
</File>
</File>
    <File id="">
    <FileName>19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_x86FRE_en-us.esd</FileName>
    <LanguageCode>en-us</LanguageCode>
    <Language>English (United States)</Language>
    <Edition>Professional</Edition>
    <Architecture>x86</Architecture>
    <Size>2961879946</Size>
    <Sha1>b271403ab23826708f626f671b2115e6f96c166d</Sha1>
    <FilePath>http://dl.delivery.mp.microsoft.com/filestreamingservice/files/91c7756c-5b20-4342-8651-e5186d978951/19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_x86FRE_en-us.esd</FilePath>
    <Key />
    <Architecture_Loc>%ARCH_32%</Architecture_Loc>
    <Edition_Loc>%CLIENT%</Edition_Loc>
    <IsRetailOnly>False</IsRetailOnly>
</File>
</File>
    <File id="">
    <FileName>19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.esd</FileName>
    <LanguageCode>en-us</LanguageCode>
    <Language>English (United States)</Language>
    <Edition>Professional</Edition>
    <Architecture>ARM64</Architecture>
    <Size>3661354203</Size>
    <Sha1>21d0723b6c8e8be77e332aa44c77c9463ab66d6a</Sha1>
    <FilePath>http://dl.delivery.mp.microsoft.com/filestreamingservice/files/0796d7b4-b59c-4aac-9b29-64666728c3e3/19045.3803.231204-0204.22h2_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.esd</FilePath>
    <Key />
    <Architecture_Loc>%ARCH_64%</Architecture_Loc>
    <Edition_Loc>%CLIENT%</Edition_Loc>
    <IsRetailOnly>True</IsRetailOnly>
</File>

(from kaliiiiiiiiii/esdtracker/blob/main/products/Win10/7_9_c_79cbc22a-0eea-4a0d-89c0-054a1b3aa8e0_products/products.xml from https://go.microsoft.com/fwlink/?LinkId=2156292 redirecting to https://download.microsoft.com/download/7/9/c/79cbc22a-0eea-4a0d-89c0-054a1b3aa8e0/products.cab ) is suitable here?
Older versions could as well be used (see kaliiiiiiiiii/esdtracker/blob/main/locations.json)

Afaik, windows doesn't officially distribut arch64 & 32-bit images anywhere.
This essentially is the reverse-engineered way on how Media Creation Tool downloads the installation image.

That would them be ([n] refers to image index here):

File Name	Path
boot.sdi	x64\Windows Setup Media[1]\boot\boot.sdi
bootaa64.efi	arm64\Windows Setup Media[1]\efi\boot\bootaa64.efi
bootia32.efi	x86\Windows Setup Media[1]\efi\boot\bootia32.efi
bootmgr.exe	x64\WindowsPE[2]\Windows\Boot\PXE\bootmgr.exe
bootuwf.dll	x64\WindowsPE[2]\Windows\Boot\PCAT\bootuwf.dll
bootvhd.dll	x64\WindowsPE[2]\Windows\Boot\PCAT\bootvhd.dll
bootx64.efi	x64\Windows Setup Media[1]\efi\boot\bootx64.efi
wgl4_boot.ttf	x64\Windows Setup Media[1]\boot\fonts\wgl4_boot.ttf

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

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

[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.)

[kaliiiiiiiiii]

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.

[kaliiiiiiiiii]

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.

[kaliiiiiiiiii]

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).