Windows boot process doesn't make sense!

Question

Here is my question: How can the Windows 7, 8, etc. boot process work?

The first piece of code loaded from the volume boot sector of the OS is bootmgr.exe. But here's why this doesn't make sense:

An "exe" is a portable executable file, which is composed of metadata that the OS (Windows) parses. There's no way the boot manager can be a PE file when mostly the entire OS needs to be loaded to parse PEs, namely the loader, memory management services, system threads for VM, device drivers, etc.

So how can the first program be a PE? My assumption is that it can't, or else it wouldn't make sense (the CPU does not "parse" PEs unless Windows' loader software tells it to).

So basically, on the lowest-level, the Windows boot process is false/misdealing info?

Answer 1

(I'll assume you're talking about the boot process using legacy BIOS as UEFI situation is different)

The boot manager is not a PE, or, rather, not just a PE. It starts with 16-bit realmode part. You can check it yourself by looking at the file.

0000000000: E9 D5 01 EB 04 90 00 00 │ 00 52 8B C3 0E 07 66 33
0000000010: DB BA 01 00 E8 34 00 E9 │ 51 01 2E 88 16 06 00 50

As you can see, it does not start with the MZ signature but directly with machine code. So the boot sector just needs to load the file into memory and jump to it - the rest bootmgr will do itself. The 16-bit part loads and uncompresses the PE part, switches to protected mode, and passes execution to it.

The compressed PE data can be found after the signature BMCI or BMXH. It seems someone made a tool to find and decompress it automatically:

https://github.com/coderforlife/bmzip

The uncompressed PE does not need the full OS because it's not using any OS services. It implements all necessary functionality itself - it is, in fact, a mini-OS on its own. It does not need that much - e.g. it doesn't need multi-threading, paged memory, or context switching. It needs only enough functionality to find and load the next stage (winload.exe).