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 (hd32)
map (hd32)/winvblock.img (fd0)
The table should/can look like this:
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:
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 (hd32)=/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