I tried to find out more about wimboot, but sadly need more info. A couple of threads about it on this site did not help...
Its source code is written in
C and its author, Michael Brown, has licensed the software as "open source." It lives with
iPXE at the iPXE web-site.
Of course, I don't really know much about WIMs or SDIs, so it would be good if you can point me to some relatively beginner level stuff on those. Like WIM vs SDI vs. raw image vs. a plain archive vs.. ?
It seems there are many parallels between various operating systems' booting mechanisms:
- Boot from floppy disk, hard disk, optical disc
- Boot from RAM disk (example: historical Linux initrd)
- Boot from compressed RAM disk (example: historical Linux compressed initrd)
- Boot from RAM-based filesystem (example: modern Linux initramfs)
- Boot from compressed RAM-based filesystem (example: modern Linux compressed initramfs, example: .WIM files)
My understanding is that in
Microsoft Windows NT descendants, there are two sorts of modes for using a RAM-disk:
- The disk image for the virtual disk contains a regular filesystem
- The disk image is a "dummy" and a special filesystem driver uses an archive to pretend that filesystem is on that virtual disk
With the former, the disk image is just an image of a regular disk. It can have any regular disk filesystem on it. With the latter, the disk image is just a dummy to pretend "there is a disk" and the files are provided by a special filesystem driver, such as the one that knows how to mount .WIM files.
If you had $0.05 for every boot-from-virtual-disk scenario that Microsoft used with Windows >= Windows
XP, I think you'd have at least $0.15.
Also, I thought the Vista RTM (pre SP1) bootmgr was uncompressed, and read that it's 16 bit header could be used to call bootmgr.exe directly... So why such a complex piece of software like wimboot?
Wimboot doesn't require any disk. The
BIOS version of
BootMgr expects some kind of disk.
It's actually doing a similar strategy to .WIMs themselves, only back one step in the boot-process. You hand it a set of files and it emulates an
INT 0x13 disk with a
FAT filesystem on it containing those files. The magic is that it doesn't use any disk image; sector-read requests have dynamically-generated content without having built an entire disk image in memory.
Wow nice info... So the real mode stub is not actually in real mode... How? Bochs showed it alternating between 16 bit real mode and 16 bit protected mode hundreds of times.. I really didn't know what to make of it. But yes your explanation makes sense of why the code seemed to refer a location to which bootmgr.exe never wrote to.
The stub for BIOS BootMgr and the
(U)EFI BootMgFw.Efi play a similar role: Both establish some amount of firmware abstraction for the "proper" BootMgr itself. Why do I think this? Because both of them pass parameters to the proper BootMgr which include callbacks.
For the BIOS BootMgr, it calls back into the stub for disk-reads. For each read, the stub will bounce from protected mode into real mode, perform the INT 0x13, then bounce back into protected mode, then return the data and control to BootMgr. This is the same for many boot-loaders, including
MEMDISK and
GRUB4DOS.
Oh please do keep telling me when there are existing solutions... In this case for a few months I have been following this whole EFI and GPT field. Booting in general I'm mostly learning by getting my hands dirty since just recently
Thinking about it some more, you could probably use wimboot without doing any hacking, just as some of your other options do...
- Using a GPT partition as an MBR disk image or floppy disk image (GRUB4DOS could map this)
- Using an MBR disk image or floppy disk image from some filesystem on some GPT partition (GRUB4DOS or MEMDISK could map this)
Using wimboot, you wouldn't have an disk image, but you could get the same result: You could boot BootMgr with an arbitrary BCD, then that BCD could refer to the actual GPT disk. I could probably make an example and attach it to a future post, if that seems like an interesting solution. A nice feature is that the BCD is easily accessible without having to be "put inside" and "taken out of" a disk image any time you change it.
well those BIOSes and UEFIes can go screw themselves The grand assumptions of the BIOS engineers of yesterday.... "There will never be any other way to partition hard disks than tired old MBR".
Indeed.