Ok, I think we have a winning (simple) idea.
The libvmdk approach suggested by erwan.l seems like working nicely
, at least in "reduced scale" tests.
I have no way right now to create and test such a large .iso file, not on this machine and not in my grand pa' windows
in order to test a batch file I am working on, but as soon as I have it theoretically working, I will post it.
In the meantime a few NOTES.
Maximum FAT32 filesize: 4294901760 bytes according to the Pismo screenshot posted earlier, 4294967295 theoretical, will need to be tested.
To workaround limitations in batch math, one can use Olof's nice rawcopy that though not really-really documented, allows for using suffixes K, M and G in size.
So, 4G would be too much and 4095M sounds like "just right" as 4095*1024*1024=4293918720
devio --dll=proxy.dll;dllopen shm:test_proxy [PATH] filename
accepts °any° file extension for the "descriptor file".
The elements actually needed in the descriptor file are far less than the "standard" .vmdk ones, example:
# Disk DescriptorFile
# Extent description
RDONLY 2880 FLAT "thesplit.iso1" 0
RDONLY 2880 FLAT "thesplit.iso2" 0
RDONLY 2880 FLAT "thesplit.iso3" 0
RDONLY 2880 FLAT "thesplit.iso4" 0
RDONLY 2880 FLAT "thesplit.iso5" 0
RDONLY 1784 FLAT "thesplit.iso6" 0
# The Disk Data Base
The above seemingly works fine
, no need for:
#DDBddb.virtualHWVersion = "3"
#ddb.geometry.cylinders = "16383"
#ddb.geometry.heads = "16"
#ddb.geometry.sectors = "63"
#ddb.adapterType = "ide"
The libvmdk is "sensible" to the size (in 512 bytes/sector) of the split parts, i.e. the values need
to reflect the actual file sizes.
The imdisk connecting command needs an added -o cd
to force the mount as CD/DVD:
imdisk -a -t proxy -o shm -o ro -o cd -f test_proxy -m Z: