wimboot & winpe - assorted questions

[jpwise]

Hi Michael, just a bit of feedback on the 0x78 suggestion. Just gave it a go on a merged Windows Recovery Environment Wim -combining x86 and x64 versions. BootIndex (0x78) after merge is 2. WimBoot it and you end up with the x64 version (Index 2). Just tried modifying 'only' 0x78 from 2 to 1, and reloaded it using WimBoot, ended up with the x64 version still. Having a read through this suggests there may be 3 or 4 values that require changing - 0x60, 0x68, 0x70 and 0x78.

0x78 as you suspected does appear to hold the BootIndex value - also matching with the 4 example headers posted in the above link example.

From my checks with a Windows RE - Win7 32bit, 64bit, and 32+64bit merged wim files I have the following values.

Code:

WinRE - Win7 - 32bit
0x60    - F0 02 09
0x68    - 35 36 8C 08
0x70    - F0 1B 2C
0x78    - 01

WinRE - Win7 - 64bit
0x60    - AC 3F 09
0x68    - 73 06 F3 09
0x70    - B0 64 2D
0x78    - 01

WinRE - Win 7 - merge of above - results:
0x60    - AC 3F 09
0x68    - C6 CA C7 10
0x70    - B0 64 2D
0x78    - 02

The merged values for 0x60 and 0x70 are identical to the 64bit values, and what's what it ends up booting.
Modifying just the boot index - 0x78 to 1 still boots the 64bit.
Modifying 0x60 and 0x70 only, or all 4 values (0x60, 68, 70 & 78) to match the 32bit values, and it starts the initial load, then errors with a winload.exe error.

Was just using 'echo %PROCESSOR_ARCHITECTURE%' from command prompt for the check on which version/index it actually booted.

I haven't found enough information on what those header values actually represent or if they could be calculated/retrieved from the file for rewriting in memory, but booting different indexes isn't a critical feature request. Would be a nice to have one later on though.