With the introduction of support for
(U)EFI,
BootMgr helps to abstract the difference between
BIOS and (U)EFI. For example, here are two sequences:
- BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
- 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows
WinLoad expects a certain environment (including API) to be present. BootMgr takes care of this, so [almost] the same WinLoad program will work in either environment.
In fact, (U)EFI defines a method for storing and fetching boot parameters, so BootMgr's
BCD covers that same purpose, regardless of BIOS/(U)EFI.
But beyond BIOS and (U)EFI differences, BootMgr lets you make a "boot choice," whereas WinLoad boots a
particular operating system that it knows how to boot.
Depending on how much of an environment WinLoad expects to be present, it might be possible to invoke WinLoad directly.
Michael Brown's
wimboot invokes the BootMgr PE[1] directly, so it could invoke WinLoad directly, except that WinLoad probably wants more of an environment. You could try it!
[1] Not to be confused with the BootMgr which
GRUB4DOS and
Syslinux'
chain.c32 can invoke. That BootMgr includes a stub which knows how to invoke the embedded BootMgr PE.