As it was said above, XDF format floppies work with an ISA floppy disk, only (driven
by ibm1flpy.add driver). XDF floppies work via a xdfloppy.flt filter driver, which works
on top of ibm1flpy.add. vfdisk.sys is a virtual floppy ramdisk driver. It is a pre-ADD-model
block device driver, so filters like xdfloppy.flt won't work with it. They work only with
ADD block drivers. So, xdfloppy.flt won't work with vfdisk.sys. Also, vfdisk.sys doesn't
support XDF itself.
vfdisk.sys has the vfctrl.exe command line utility to configure the emulated floppy disk
sizes. Also, there is a vfctrlpm.exe, which is a PM-based version of vfctrl.exe. The default
disk size can also be specified on a driver command line. The drive letter specified in the
driver command line, doesn't matter. The driver just uses the first available drive letter
after RESERVEDRIVELETTER.
To emulate XDF floppies, you can use the Super Virtual Disk (svdisk.sys). Though, it is
shareware, and makes a delay during the boot if it is unregistered. This is annoying. The
PM program used to configure it, also fails to start if it is unregistered, but the command
line program works fine. The nice feature of SVDISK is also the ability to use the HPFS-
formatted ramdisks. It has own disk formatting utility, which, unfortunately, works only
with SVDISK ramdisks. Also, I managed to format a virtual floppy disk as HPFS, then
did savedskf on it, and created a 1.44 MB HPFS floppy disk image. This disk image can
be then copied to a physical floppy disk with loaddskf.exe. So, this way it's possible to
create the HPFS-formatted floppies. The cool hack, BTW
There is also a diunpack.exe utility, which can extract the IBM *.dsk format disk images
(including the compressed ones). It works just like an archiver. So, it extracts a floppy image
to a subdirectory. But I doubt that diunpack.exe can handle XDF floppy images.
Mtools are used to access the FAT disk images, including floppies and hard disks. There
is also an USB flash-aware version written by Froloff, which is able to copy files from FAT/FAT32
flash sticks.
In mtools, you just specify a path to all images in its config file, and assigns drive letters to them.
The drive letters are internal (separate from OS/2 drive letters). In case of Froloff's USB-aware
version, you specify a USB MSD device Vendor ID and Product ID, instead of an image path.
Unfortunately, Froloff no more uses OS/2 and his site is down. But I could upload his mtools
to my ftp, if someone interested.
To use mtools, you need to put mtools.exe in the same directory together with mtools.conf,
on PATH. And create wrapper .cmd files like this:
/* */
Parse Arg argstr
'@set MTOOLSRC=./mtools.conf'
'@set COUNTRY=007,866'
'@msup mdir' argstr
-- this is for a "mdir" mtools subcommand. There is the "msup.exe" helper which
calls mtools with required parameters. As people said here above, a newer kLIBC-
based version uses kLIBC symlinks instead, but I did not tried it. Also, the disadvantage
of kLIBC symlinks is that they don't work in non-kLIBC-based programs, like CMD.EXE,
4OS/2 or FC/2. You still need wrapper .cmd files.
Though, as far as I can see, mtools won't help you to access the XDF floppy image contents.
PS: For accessing the disk images, including floppy images, CD iso images and VM images
of VBox/VirtualPC/QEMU/etc, you can use fat32.ifs with it's loop.add driver. But note that
it is in development, yet, and not everything is working at the moment. But accessing the
FAT/FAT32/exFAT/CDFS images works fine. But it does not support XDF floppy images as
well.
