Hmm, if VHD images are indeed RAW+FOOTER, then I'd guess the bootsector/mbr actually starts on the first byte of the file? If that's the case then I would think it should just work. The only 'weirdness' would be that footer, making the disk bigger when used through DriveDroid compared to when used in a VM/whatever. That shouldn't be a problem though.
@wonko, is that footer needed? Isn't it just a .img with a footer appended?
Sure it is (please read as not really )
A tool/driver intended to use .vhd images will *need* it, a tool intended to use RAW images will *need* it not.
Basically an info that is missing in a .img (or RAW image of a disk) is the geometry besides a few more parameters useful in a VM..
Normally (and with the "old" partitioning scheme of respecitng cylinder boundary) it would be easy to get it from an existing partition table CHS values, but a number of things cannot be done (as an example "partition" a blank image).
In practice, until you are within the 8 GB CHS boundary, geometry may change, particularly for smallish images, and have n/16/63, n/64/32, etc, but as soon as you go over this limit, and exit the CHS realm to go into the LBA only one, any machine/OS will use a n/255/63 geometry, so it is not really an issue.
At the time there were three solutions devised by the good guys making VM's:
- a separate "descriptor file like VMware .pln and .vmdk
- a "footer" like the "Connectix" one (remember that the "static" .vhd format was made by Connectix and only much later MS bought the company and "Virtual PC"
- a "header" like other forms of VMware .vmdk and - later - Virtualbox .vdi
Here is some related info:
At the time the *only* available and reliable/working Virtual Disk Driver was Ken Kato's VDK which was hardcoded to use n/64/32 geometry (being originally developed for NT 4.0) and that made necessary the use of a .pln (or .vmdk) descriptor file to manage correctly most RAW images, see:
Later all available drivers would use the LBA only data or default to the 255/63 geometry. like modern Windows does.
VDK and the possibility to "tune" manually geometry still has some needs/merits, though, that is essentially the reason/way I used to put together MBRBATCH:
The "Connectix approach" is as a matter of fact the most "intelligent" one as you can have it while keeping - to most effects - the RAW image accessible with anything.
Grub4dos throws the warning just as it would do for a "real" RAW image taken from a hard disk partitioned with the "old" convention of respecting Cylinder/Head boundaries (i.e. with "excess sectors" at the end), it calculates the number of sectors actually belonging to partitioned space and issues the warning, but that's all.
Generally speaking a .vhd image is a Hard Disk like image (i.e. a partitioned image) and it's first sector will be the MBR, not a PBR/VBR.