Problem with loading some CD images.

jr2

New Member
#1
It appears that any CD / hard disk image that loads an OS that uses it's own drivers to access the filesystem fails. You can load Linux-based images with some options if the kernel supports it through the /iso-scan flag, but that's not my aim here..

e.g., I can load up FalconFour's UBCD 4.61, but if I try to load up Mini XP, that will BSOD, despite the fact that I can successfully boot it from an actual CD.

Now, F4UBCD uses GRUB4DOS to load the Mini XP image, so it can work, it just doesn't...

I can boot the DOS utilites part by doing:

map --mem (hd0,1)/F4UBCD.iso (0xFF)
map --hook
map --mem (0xFF)/F4UBCD/Images/hbdos13.gz (fd0)
map --rehook
rootnoverify (fd0)
chainloader +1 (fd0)
boot

But if I do this with the XP CD image (that F4UBCD normally uses GRUB4DOS to load from itself), it crashes.

(Using the boot ISO feature from EasyBCD won't even load the DOS image; it can't find it).

How would I go about making an image loaded into memory indistinguishable from an actual CD? It's in the "drive", the drive is an "optical" drive, it's read-only, don't touch it, Windows, you have the drivers, just read from it and leave it be; and that memory is reserved, you can't use it, just pretend it's not there.


This approach should make it possible to load anything that can load from a CD / DVD drive, as a hard disk image, no matter what OS is on the disk. Bonus, since it's been loaded fully into the memory, you can manipulate the disk that the image is on (e.g., re-size the partition from a GParted image), and not have it locked out.

EDIT: The F4UBCD command for loading Mini XP is:

chainloader /HBCD/XPLOADER.BIN

However, when I:

map --mem (hd0,1)/F4UBCD.iso (0xFF)
map --hook
root (0xFF)
chainloader (0xFF)/HBCD/XPLOADER.BIN
boot


I get the BSOD, same as when I

map --mem (hd0,1)/F4UBCD.iso (0xFF)
map --hook
root (0xFF)
chainloader (0xFF)
boot

And then use the F4UBCD menu to boot Mini XP
 
Last edited:

mqudsi

Mostly Harmless
Staff member
#2
Unfortunately, that's not possible as a result of architectural constraints in the way modern processors work.
OSes will communicate with the hardware via the BIOS. Something sitting on top of the BIOS is outside of the loop.

The only way this can work is to design an entire BIOS emulation layer that is loaded by the BIOS and then loads the OS - basically, exactly what the CSM firmware does on UEFI machines - it's a virtual BIOS that emulates drives and legacy protocols on top of the UEFI protocol, and the OS interacts with that that instead of interacting with the UEFI directly.

The catch? It is super hardware-specific and won't work across platforms. That's why every motherboard has its own CSM and you can't just take something like TianoCore's open source CSM implementation and run it on motherboards that don't come with a CSM.

All that is to say it's unfortunately not really possible, even though it's a really really cool (and effective) idea.
 

jr2

New Member
#3
OK, I understand this, however...

It's my understanding that BIOS has devices load their interim 'drivers' from their firmware at boot, and that these are then replaced by the Operating System's drivers during the OS loading process.

The reason that DOS can use GRUB's mapped emulated drives is that it doesn't load its own drivers; it just uses BIOS calls. (Right?)

Windows and Linux apparently have a disconnect in that they don't see the emulated memory-device as a standard CD-ROM / Floppy / Hard disk and choke. But... why? What is the tripping point? Does the memory device need hardware IDs? I know Windows is perfectly capable of using generic disk drivers. If the appropriate memory is marked as in use by the device... does Windows / Linux 'replace' the memory mapped by the GRUB 'device' (thus the 'device' would disappear!) when they load their hardware drivers?

Perhaps it would be possible to patch the kernel in memory to get it to allow the device to remain and be accessible by the OS, similar to how Kon-Boot does (Kon-Boot does this to make the kernel think that any password entered, even a blank one, is the correct password; this works on Windows XP & up & Linux).