Jump to content











Photo
* * * * - 3 votes

WinVBlock


  • Please log in to reply
617 replies to this topic

#226 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 02 June 2010 - 04:42 PM

Well, I would use dd to copy sectors in RAM...

Where in RAM? :)

Cannot we (please read as YOU :() try talking about the issue with tinybitor Bean? :(

Yes it would be ideal if there was just a little bit more information passed between GRUB4DOS and a Windows driver...

Having said that, I just did a little .ISO testing... You can append a nice 2048-byte file to an .ISO:
C:\Documents and Settings\User\Desktop>type descriptor.bin >> WinXPProSP2.iso

C:\Documents and Settings\User\Desktop>contig -v WinXPProSP2.iso
And it still appears to boot with MEMDISK, GRUB4DOS, QEmu. It also appears to be burnable with Nero.

Obviously one can append to an .HDD image:
C:\Documents and Settings\User\Desktop>type descriptor.bin >> WinXP.hdd

C:\Documents and Settings\User\Desktop>contig -v WinXP.hdd
But it would be best to append a whole cylinder to avoid fractional geometry detection by MEMDISK/GRUB4DOS.

For either of these, it would be easiest to put information in the last 512 bytes of the descriptor file. The descriptor file only needs:
  • The LBA length of the image file before it is/was appended to
  • Some magic signature that we have strong confidence in
  • Possibly C/H/S geometry info
  • Possibly descriptor version info
Thus you append this descriptor and forget it. You can burn the .ISO if it's an .ISO. You can copy it anywhere and not have to change anything. WinVBlock can automatically strip off the descriptor (which is important for GPT disks, since they expect certain data at the end of the disk). You don't do anything special in GRUB4DOS. The only case I can think of where this might cause a complication is if you use something that's not aware of the descriptor, such as booting the image in QEmu and erasing the disk from within QEmu (that would include erasing the descriptor).

karyonix: If one has multiple GRUB4DOS INT 0x13 hooks, we could theoretically see multiple entries for drive 0x80, so I don't know about using BIOS drive numbers in Windows.

#227 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 June 2010 - 06:16 PM

Where in RAM? :)

In the remaining 1/3 or 1/2 I know nothing about. :(


Obviously one can append to an .HDD image:

C:\Documents and Settings\User\Desktop>type descriptor.bin >> WinXP.hdd

C:\Documents and Settings\User\Desktop>contig -v WinXP.hdd
But it would be best to append a whole cylinder to avoid fractional geometry detection by MEMDISK/GRUB4DOS.


...and create a .vhd image compatible with Virtual PC .... :(

Seriously :(, can you check if the info contained in the appended sector of the "new" .vhd format already contains the needed data?

erwan.l's tool Clonedisk:
http://www.boot-land...?...ic=8480&hl=
could be used for the "conversion" (if needed).

The "fractional geometry" error from grub4dos can be avoided by setting errorcheck off, doesn't it?

:(
Wonko

#228 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 02 June 2010 - 09:56 PM

... for which you need to understand the used filesystem (at least partially).

Just start DOS and take a disk monitor to have a look at a NTFS partition. Tell me, you can't read strings just fine, without any file system driver.

btw. I'm out of this discussion. :)

:(

#229 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 03 June 2010 - 05:21 PM

MedEvil: Well, thank you for your contribution to the thread anyway!

Wonko the Sane: I had thought about jumping on the .VHD band-wagon before... It was in the back of my mind for a while, since I'd like to support lots of disk formats such as .VMDK, etc. So anyway, yes I've coded .VHD fixed-disk footer support and it seems to work nicely for HDD images. I'm just working through the CD/DVD case now. The CD/DVD case on backing HDD now works. So the rules will be:
  • You have to append a hunk to the image file
  • The hunk must be the sector-size for the image file's intended disk type
  • That means commonly 512 bytes for HDD images
  • That means commonly 2048 bytes for .ISOs
  • The last 512 bytes of the hunk must be a Microsoft .VHD footer with fixed-disk type
  • Once I attach a sample to this post, there're only two fields to change for your own HDD image/.ISO
  • Those two fields both take the same 8 bytes
  • Those 8 bytes are the size of the HDD image/.ISO's total bytes, without the hunk
It's kind of neat to be able to:
  • Boot to a floppy image with MEMDISK, which then
  • Loads GRUB4DOS, who
  • Maps a Windows installation disc .ISO, untouched except for the .VHD footer, to (hd32). Then it
  • Maps a completely empty HDD image file (with a .VHD footer) to (hd0). Then it
  • Boots the Windows installation disc, where you
  • Press F6 to load WinVBlock from the earlier MEMDISK floppy image with .INF and .SYS files. Then
  • Windows setup allows you to partition and install Windows to the empty HDD image. Ha.


#230 dog

dog

    Frequent Member

  • Expert
  • 236 posts

Posted 04 June 2010 - 02:59 PM

Am happy to report success using your example menu.lst and a contig'd 1184MB xpsp3 :)

#231 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 04 June 2010 - 03:57 PM

I'm very happy to see this feature implemented and WORKING :)

Thanks a lot Shao :(

Managed to bood a full XP from a image file on a hidden partition in VBox.
I used the hidden partition as a workaround for the "defrag problem".
Is there another way to lock the file and prevent it from beeing moved?

#232 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 04 June 2010 - 09:20 PM

Well yes, it's not as though I'd expect a(n especially large) file to move of its own accord, but Microsoft's SysInternals' PageDfrg and scheduled/idle-time defragmentation could certainly move the file.

Earlier I mentioned hot-swapping from being a disk-sector-mapping to being a file-in-a-filesystem. This is actually pretty easy to do... If you know what file to swap to.

So a new discussion point: How do we know what file to swap to?

GRUB4DOS doesn't pass the file name, but even if it did, (hd0,0)/foo.hdd can mean nothing to Windows, since BIOS drives (G4D's hd0 == BIOS 0x80, for example) mean nothing to Windows. However, we do manage to figure out the backing disk, so we do know what disk hd0 is. But then trying to figure out the ,0 (partition) association to a volume is trickier. Add these points together and it doesn't seem pleasant.

If you put the simple filename of the image in the image itself, this:
  • is hard to change in an .ISO if you rename the image file
  • would mean trying to open the file in the root directory of every available filesystem (not too bad)
If you include a full path:
  • The drive letter in that path will not likely have any meaning if you copy/move the image anywhere (drive letters for new volumes could be different)
  • You are pretty well stuck to that path without making a change in the image, let alone the image's simple filename
  • Also consider the complicated case for volume mount-points being involved
One of the easiest things to do would be to let the user decide. A native or Win32 app could perform the hot-swap with input from the user. There's nothing to prevent the hot-swap 28 days after booting (as long as the image file didn't move in that time). Seems a little risky, but not too bad. Requires a user to choose, or some batch process of the user's creation to decide.

Thoughts?

#233 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 05 June 2010 - 01:52 AM

I think it is possible to boot directly from file-backed disk without sector-mapped disk in some configuration.
  • Kernel start boot drivers.
    • Virtual disk controller driver starts.
      • It somehow know that it should mount disk image file 'filename'.
      • Disk image file is inaccessible.
    • Backing disk controller driver starts.
  • Kernel enumerates and starts all devices.
    • Virtual disk controller starts.
      • Disk image file is still inaccessible.
    • Backing disk controller starts
      • Backing disk is discovered.
    • Backing disk starts.
    • Volume in backing disk starts.
    • Volume in backing disk has filesystem attached.
      • Disk image file is accessible.
    • Virtual disk controller driver tries again.
      • Disk image file is opened.
      • Virtual disk is discoverd.
    • Virtual disk starts.
    • Volume in virtual disk starts.
    • Volume in virtual disk has filesystem attached.
  • Booting continues.


#234 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 05 June 2010 - 02:11 AM

Hmm... I had tried this before and landed on the current sector-mapped strategy. Imagine the following sequence of events:
  • Start boot drivers, in order
  • HDD controller devices start, including virtual
  • Disk devices start, including virtual
  • Partitions/volumes are enumerated
    • File-disk is still unavailable
    • If we try to pend with the MBR probe routine (for partition enumeration), we never get any further in the boot process
  • All volumes opened
  • Find the boot volume
Remember that DriverReinitialization is too late for the boot volume, as discovered for Recovery Console and situations where volumes were not already populated into Enum\

I'm not saying it's not all asynchronous, but am thinking that there must be a synchronization where "all volumes are opened" at some point. I seem to recall that hanging the MBR probe never allowed for progress; that the booting routine was synchronous and waiting on this probe to complete before continuing.

EDIT: Ok, I just ran a test. I left the MBR probing IRP pending and simply looped in my thread for several seconds. Then I broke into the debugger and examined IoGetDeviceInterfaces() return buffer from GUID_DEVINTERFACE_VOLUME. There were no volumes after several seconds. The system startup thread was blocking here:
f896b1a4 804dc6a6 nt!KiSwapContext+0x2e

f896b1b0 804dc6f2 nt!KiSwapThread+0x46

f896b1d8 8050fb72 nt!KeWaitForSingleObject+0x1c2

f896b224 f8586cdf nt!HalExamineMBR+0xaa

f896b24c f859846f disk!DiskInitFdo+0x163

f896b274 f8596e94 CLASSPNP!ClassPnpStartDevice+0x1aa

f896b29c 804e3d77 CLASSPNP!ClassDispatchPnp+0x162

f896b2ac f87db0d8 nt!IopfCallDriver+0x31

f896b2e0 804e3d77 PartMgr!PmPnp+0x247

f896b2f0 805dd418 nt!IopfCallDriver+0x31

f896b31c 805b7077 nt!IopSynchronousCall+0xb7

f896b360 8050eabc nt!IopStartDevice+0x4d

f896b37c 805b6f13 nt!PipProcessStartPhase1+0x4e

f896b5d4 8050fcc4 nt!PipProcessDevNodeTree+0x1db

f896b618 80514a10 nt!PipDeviceActionWorker+0xa3

f896b630 806a8f79 nt!PipRequestDeviceAction+0x107

f896b694 8069f714 nt!IopInitializeBootDrivers+0x37a

f896b83c 806a0ab0 nt!IoInitSystem+0x712

f896bdac 8057dfed nt!Phase1Initialization+0x9b5

f896bddc 804fa477 nt!PspSystemThreadStartup+0x34
So we see that the MBR probe is synchronous for the startup thread, before we ever get as far as filesystem mounting. Now I could spoof an MBR (which is clearly the wrong thing to do for many reasons) just to allow the startup thread to continue, but that would be "admitting" what the MBR was, likely permanently, so no volumes could be found on our disk thereafter. *sigh*

So back to hot-swapping, which is easy... How should we pass the file and know which volume it's on, without too many ties between image file and backing disk/filesystem?

#235 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 05 June 2010 - 05:41 AM

The trick that I used in Firadisk is that bus device doesn't report inaccessible virtual drive in response to IRP_MN_QUERY_DEVICE_RELATIONS BusRelations.
Firadisk calls IoRegisterBootDriverReinitialization from DriverEntry.
From BootDriverReinitialization routine, files in real disk are accessible.
Firadisk opens disk image file successfully at this time. Then, it calls IoInvalidateDeviceRelations type BusRelations and reports newly accessible virtual drive in response to IRP_MN_QUERY_DEVICE_RELATIONS.
Then new virtual drive starts successfully.
This works with installed Windows. (with new developmental build of Firadisk)

#236 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 05 June 2010 - 05:52 AM

I already mentioned that BootDriverReinitialization (which I accidentally forgot "Boot" from) is too late for the boot volume. Maybe I'm wrong. What happens if you invalidate your MBR signature in your testing environment for your backing disk? Have you actually booted from such an image file yet? That's exciting for Firadisk. :)

EDIT: Sorry, I meant the MBR of your disk image, not the backing disk.

#237 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 05 June 2010 - 07:18 AM

I think BootDriverReinitialization is too late for IoReportDetectedDevice while booting cmdcons but not too late for IoInvalidateDeviceRelations BusRelations while booting installed Windows.

Have you actually booted from such an image file yet?

Yes. With "known" backing disk and unchanged MBR signatures for both backing disk and disk image, it can boot to desktop.

What happens if you invalidate your MBR signature in your testing environment for your backing disk?
EDIT: Sorry, I meant the MBR of your disk image, not the backing disk.

I changed MBR signature of disk image. It cannot boot. I don't know why.

EDIT:
Here is test result.
  • Change virtual disk's MBR signature and reboot.
    • Windows cannot boot.
    • change it back -> Windows can boot.
  • Uninstall backing disk device, IDE controller device, virtual disk device, and Firadisk bus device in device manager (and remove Firadisk's parameter in registry that prevent it from creating a new bus device) and reboot
    • Windows can still boot. These devices are discovered and installed again.
  • Uninstall backing disk partition "Generic volume" device in device manager and reboot
    • Windows can still boot. The volume is discovered and installed.
  • Uninstall virtual disk partition "Generic volume" device in device manager and reboot.
    • Windows cannot boot.
    • Restore system hive from backup -> Windows can boot.
Interpretation:
It seems new volumes are enumerated and started differently from hardware devices or virtual devices.
  • New/unknown volumes
    • in disk devices accessible before BootDriverReinitialize's execution can be used for boot.
    • in disk devices accessible after BootDriverReinitialize's execution cannot be used for boot.
  • Known/installed volumes which has its key under Enum
    • in disk devices accessible before BootDriverReinitialize's execution can be used for boot.
    • in disk devices accessible after BootDriverReinitialize's execution can be used for boot.


#238 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 June 2010 - 10:37 AM

@Sha0
Quickly tested with XPCLI.

It worked allright. :) :(

Cannot reproduce right now :(, my fault :( , I must have messed AGAIN with the Registry :(.

A maybe stupid remark but just in case:
We do have a number of ways to join the "original" RAW image with the .vhd-like footer, that more or less can be exemplified as:
@ECHO OFFSETLOCAL ENABLEEXTENSIONS::Batch stripper to remove last 512 or 2048 bytes from any file::Usage: B_strip.cmd <filename> [512|2048]::by default will use 512 if second parameter is omittedIF %1.==. GOTO :ErrorIF NOT EXIST %1 ECHO :: FILE NOT FOUND&GOTO :ErrorIF %2.==2048. (Set ToStrip=2048) ELSE (Set ToStrip=512)SET FileSIze=FOR /F "tokens=3,4" %%A in (&#39;DIR %1&#39;) DO IF %%B==%1 SET FileSize=%%AIF NOT DEFINED FileSize ECHO ::ERROR: Are you using a filename or path with spaces?&GOTO :ErrorSET FileSize=%FileSize:.=%ECHO.ECHO Current Filesize is now   %FileSize% bytesSET /A FileSize=%Filesize%-%ToStrip%ECHO Stripped Filesize will be %FileSize% bytesECHO.ECHO Next command will be:ECHO fsz %1 %FileSize%ECHO.ECHO Press Ctrl+C to abort...PAUSEfsz %1 %FileSize%GOTO :EOF:ErrorMORE %0|FIND "::"|FIND /V "FIND"


:(
Wonko

#239 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 05 June 2010 - 11:25 AM

@Wonko
You can also use raw2vhd. But I didn't test it with WinVBlock yet.

#240 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 June 2010 - 01:50 PM

@Wonko
You can also use raw2vhd. But I didn't test it with WinVBlock yet.


Yep :( , but still, unless I am mistaken, there is no "way back", what about a vhd2raw? :(

:)
Wonko

#241 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 05 June 2010 - 02:16 PM

karyonix: Great testing and good summary. Thanks for validating. Fortunately, the case where the boot volume is installed seems more likely than where it's not, so if you use BootDriverReinitialization time, only people who fiddle with MBR signatures or partition lengths will have trouble.

Wonko the Sane: Thank you for testing and for the batch file. I had also suggested very simply using type to append a .VHD fixed-disk footer to disk image files and .ISOs in order to avoid the space requirements. Your file splitter line is convenient. I think that these functions could be the responsibility of the WinVBlock user-land utility, which is sorely in need of attention anyway. The terms could be --bootprep and --unprep, for example.

What couldn't you reproduce? You booted a file and then broke it?

All: Still interested in how we pass the filename, if anyone has a bright idea.

#242 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 June 2010 - 02:50 PM

The terms could be --bootprep and --unprep, for example.

Why not using something meaningful, like --raw2vhd and --vhd2raw?
Also a provision that if the image is already "vhdized" the --raw2vhd would do nothing and if the image is already RAW --vhd2raw woulf do nothing would be nice.

What couldn't you reproduce? You booted a file and then broke it?

No, I booted a build, then started messing with it's Registry to add other thingies, and made the stoopid thing unbootable, but nothing related to winVblock some malformed Registry change by me in the course of completely unrelated experiments. :)

erwan.l has already updated clonedisk in the meantime:
http://www.boot-land...?...8480&st=112
:(

:(
Wonko

#243 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1062 posts
  •  
    Belgium

Posted 05 June 2010 - 07:36 PM

All: Still interested in how we pass the filename, if anyone has a bright idea.

Grub4dos should provide this info.
When grub4dos maps a file to a device, it should save this info in a table with the full filename and size.
title Windows XP from sector mapped disk

find --set-root /images/Windows\ XP.iso

map /images/Windows\ XP.iso &#40;hd32&#41;

map --hook

map &#40;hd32&#41;/winvblock.img &#40;fd0&#41;

map --hook

chainloader &#40;hd32&#41;

The table should/can look like this:
1. filename
2. filesize (64-bit integer) ==> when the same filename is on multiple partitions, look at the size to determine which is the correct one

Maybe the uuid for the partition should be added too, if the file is on a hard disk ==> easier to be sure that you have the correct file (on the right volume). The filesize maybe isn't needed in that case.

All entries are \0 separated (easy to read NULL-terminated strings)

An empty mapping slot is represented by one \0.

There are 8 mapping slots available per grub4dos instance.

For the example above it would look like this:

/images/Windows XP.iso\0510696879\0/winvblock.img\01474560\0\0\0\0\0\0\0

I don't know how grub4dos handles deletion of mappings and what happens when a new mapping is added after deletion of previous mappings.

This table can be written just before booting, by storing the filename and filesize values in an intermediate structure that is easier to maintain (update).
Or the table could start with 8 16-bit integers that point to the actual start
of the filename for that entry. So when for example all 8 mapping slots are filled, and number 3 is deleted, and a new mapping is added, that you can append the filename and filesize to the end (after slot 8) and update byte 3 so it points to this location.
If you use the index method (8 16-bit integers), you don't need a \0 after the 64-bit integer (filesize).

The filesize can already be retrieved from the mapping table which is in the current grub4dos, but including this info in my additional table has advantages.

cdob did want to load only a part of a fragmented file to memory and boot that:
http://www.boot-land...mp;#entry101597
When you want to do this with a fragmented file, which contains Windows + WinVBlock, you have a problem. The grub4dos mapping table and my additional table contain the wrong filesize. WinVBlock can't provide the full disk.
When we can have an addition grub4dos command that allows us to set the correct size, our problem is solved:
set-filesize &#40;hd32&#41;=/images/Windows\ XP.iso
This should only correct the filesize in my additional table, not in the grub4dos mapping table.


Back to example 1.
When you boot this entry, WinVBlock will look the the grub4dos mapping table and it will look for a corresponding filename and size (in my additional table. When filesystem drivers are available, WinVblock will periodically check all volumes for the filenames and will switch from providing a sector-mapped disk to a file-backing disk (so the file can be moved now = less chance for data corruption to occur). The periodic check for finding that filename will be removed. Additionally WinVBlock looks if there are mappings in the grub4dos mapping table that indicate, image in image behavior.

In our example the winvblock.img floppy image is located inside the ISO.
WinVBlock will first find the ISO and will switch from providing a sector-mapped disk to a file-backing disk. The periodic check for finding the ISO is removed, the periodic check for finding the floppy image is still active. Now WinVBlock can switch the sector-mapped floppy disk to a file-backing disk.
(NOTE to Sha0: In theory the floppy disk image can be switched from sector-mapped floppy disk to file-backing disk before the ISO disk has been switched to a file-backing disk. I am not sure what would be the best approach. When the underlaying sector mapped file is on a hidden volume and you have also sector mapped a floppy image from inside this sector mapped disk, you can switch to a file-backed disk for the floppy disk but not for the underlaying disk.)

A side effect of the fact that grub4dos will need to store the filename in my additional table is that it should be easy to write a small program for linux, to retrieve the filename and make it possible to find the iso file from which you booted with grub4dos and mount it, without the need of passing additional parameters to the linux kernel :)

I discussed with Sha0 about this approach and he seemed to like it :(.

#244 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 05 June 2010 - 11:58 PM

GRUB4DOS doesn't pass the file name, but even if it did, (hd0,0)/foo.hdd can mean nothing to Windows, since BIOS drives (G4D's hd0 == BIOS 0x80, for example) mean nothing to Windows. However, we do manage to figure out the backing disk, so we do know what disk hd0 is. But then trying to figure out the ,0 (partition) association to a volume is trickier. Add these points together and it doesn't seem pleasant.

Well, as you know the starting sector of the file and the HD number you can...

  • Enumerate all volumes using FindFirstVolume and FindNextVolume
  • Query IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS to get the hard disk number, the offset and length of the volume
  • Check if the hard disk number matches and if the starting sector of the image file is located within this volume
  • Use GetVolumeNameForVolumeMountPoint to get the drive letter of the volume


#245 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 June 2010 - 06:31 PM

TheK: Yes, that seems like a way to know which volume the file is on. We still need the filename, though. If we have the filename, we can simply try the file on every volume, or we could limit ourselves to just the correct volume using the method you've given. We should also check the file-size as Icecube advises.

#246 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 07 June 2010 - 03:29 PM

OK, here's an idea to transfer the filename to WinVBlock.

The idea is to store the filename in a file on a (virtual) floppy. The file must have a fixed name. Let's call it WINVBLK.BIN for example.

We can write the filename of the image file directly from grub4dos to WINVBLK.BIN

title Boot Windows XP from IMG file

find --set-root --ignore-floppies /somepath/win.img

map /somepath/win.img &#40;hd0&#41;

map --mem /somepath/winvblock.ima &#40;fd3&#41;   #floppy image containing WINVBLK.BIN

map --hook

write &#40;fd3&#41;/WINVBLK.BIN /somepath/win.img

root &#40;hd0,0&#41;

chainloader /ntldr

WINVBLK.BIN must already exist on the floppy image and must be at least 2KB in size (zero filled) for this to work.

#247 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1062 posts
  •  
    Belgium

Posted 07 June 2010 - 09:16 PM

OK, here's an idea to transfer the filename to WinVBlock.

The idea is to store the filename in a file on a (virtual) floppy. The file must have a fixed name. Let's call it WINVBLK.BIN for example.

We can write the filename of the image file directly from grub4dos to WINVBLK.BIN

title Boot Windows XP from IMG file

find --set-root --ignore-floppies /somepath/win.img

map /somepath/win.img &#40;hd0&#41;

map --mem /somepath/winvblock.ima &#40;fd3&#41;   #floppy image containing WINVBLK.BIN

map --hook

write &#40;fd3&#41;/WINVBLK.BIN /somepath/win.img

root &#40;hd0,0&#41;

chainloader /ntldr

WINVBLK.BIN must already exist on the floppy image and must be at least 2KB in size (zero filled) for this to work.

It would become a mess when you map multiple files (not necessary mapped by the same grub4dos instance) and you don't know for sure (no causal correlationship) which file matches with which sector mapped disk (doing a md5sum on the image, isn't a very good idea, if you care about performance).

#248 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 June 2010 - 12:29 AM

(Please note that this post includes colour coding. You will miss this if you lack enough colours while reading.)

Well, I'm coding for a blend of karyonix', Icecube's, and TheK's suggestions with the following GRUB4DOS parameter block logic:

map (hd0,0)/somedir/XP.HDD (0x80)
map --hook
map (hd0,0)/isodir/some.iso (0xA0)
map --rehook
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --rehook
write (0x55) #!GRUB4DOS\x00v=1\x00somedir/XP.HDD\x00\x80isodir/some.iso\x00\xA0\x00
root (hd0,0)
chainloader /ntldr

Where we see that we set up a phony RAM disk at an arbitrary number (0x55 simply picked due to karyonix' post, but we don't actually care since we check for a signature). We make it 2048 bytes. We write a signature, a version, then a list of files and their associated drive numbers. When we encounter a filename which is actually an ASCII NUL, this means the end of the list.

Since this phony RAM disk will be in the same table as the disks it describes, we know that drive 0x80 in this parameter block describes only the drive 0x80 found in the corresponding G4D disk mapping table.

Unfortunately, I think that supporting "RAM disk stubs," will have to wait. "RAM disk stubs" meaning: RAM disks with enough data to boot Windows, but then the Windows driver should swap over to a file. That's why you don't see any file sizes in the above logic, even though Icecube and I discussed it.

#249 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 08 June 2010 - 01:57 AM

How about ...
- Add backing disk MBR signature (or the whole MBR) to GRUB4DOS parameter block as well ?
- Use a normal good looking character as separator.
- First field is map drive number.
- Second field indicate MBR signature of backing disk for sector-mapped disk "$AABBCCDD"
or address of whole MBR copied into RAM "@offset_relative_to_start_of_GRUB4DOS_parameter_block".
- (optional) Third field identify backing disk volume that contain file (what information should be put here ?).
- Next field is filename beginning with / .
- Empty record indicate end of parameter block.

write (0x55)+1 GRUB4DOS|v1|0x80 @512 /somedir/hp.hdd|0xA0 @512 /isodir/some.iso||

#250 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 June 2010 - 02:49 AM

How about ...
- Add backing disk MBR signature (or the whole MBR) to GRUB4DOS parameter block as well ?

Thought about that. Parameter block could have multiple MBRs filling additional sectors past the header... But not relevant for non-MBR disks, such as .ISOs/CDs/DVDs, empty disks, APM/GPT/other-partitioned disks (though GPT's legacy MBR is there).

- Use a normal good looking character as separator.

If you could suggest a character guaranteed illegal in a filename for every filesystem, sure.

- First field is map drive number.

I started that way, but drive 0x00 is not distinguishable from ASCII NUL. What does one search for to determine end-of-record?

- Second field indicate MBR signature of backing disk for sector-mapped disk "$AABBCCDD"
or address of whole MBR copied into RAM "@offset_relative_to_start_of_GRUB4DOS_parameter_block".

See above, but a nice idea. Certainly easy to say "512" or "1024".

- (optional) Third field identify backing disk volume that contain file (what information hould be put here ?).

I might have a disk image "stub" but actually wish to hot-swap to a file on... A network filesystem. UUID or partition offset seems appropriate, otherwise, but not sure that it helps any more than "try each FS until found."

- Next field is filename beginning with / .

When would a relative filepath ever be meaningful? I think the initial '/' could be implicit.

- Empty record indicate end of parameter block.

I see. I still worry about choice of record-delimiter.

write (0x55)+1 GRUB4DOS|v1|0x80 @512 /somedir/hp.hdd|0xA0 @512 /isodir/some.iso||

Looks pleasant, but that should be vF1. :D All joking aside, I'll admit that I'm trying to "cheap-out" on lots of parsing for version 1. Otherwise, I'd simply do:
# CHOICECHOICECHOICECHOICECHOICECHOICE

title foo

  map &#40;hd0,0&#41;/foo.hdd &#40;hd0&#41;

  map --mem /menu.lst &#40;0x55&#41;

  map --hook

  write &#40;0x55&#41; #!GRUB4DOS foo |

  root &#40;hd0,0&#41;

  chainloader /ntldr

title bar

  map &#40;hd0,0&#41;/bar.hdd &#40;hd0&#41;

  map --mem /menu.lst &#40;0x55&#41;

  map --hook

  write &#40;0x55&#41; #!GRUB4DOS bar |

  root &#40;hd0,0&#41;

  chainloader /ntldr
and parse the whole config-file and be done with it. All the information is there. :D




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users