DBLSPACE or DRVSPACE in MSDOS/WIN9X DOS
STACKER
U can turn of compression and use them

That's just for compressed volume files, which are not (quite) the same thing.

OP is looking for flat image support.

They might *try* Turboimage.

Babasha wrote on 2026-06-19, 07:34:

DBLSPACE or DRVSPACE in MSDOS/WIN9X DOS
STACKER
U can turn of compression and use them

I had actually considered something like this if no better option was available…

wierd_w wrote on 2026-06-19, 08:26:

That's just for compressed volume files, which are not (quite) the same thing.

OP is looking for flat image support.

They might *try* Turboimage.

Having never used TurboImage, quick Google suggests the image is mounted into RAM as it’s designed for floppy disk images?? Or is Google wrong again?

That's correct. It's about the closest I know of to doing what you want.

DOS was never really an environment where "Huge amounts of mass storage" was ever really a thing, that you could just have gigabytes worth of single files to use like disk drives.
(2gb limit for FAT16 for DOS6.22, etc. 4GB limit for single files, on FAT32. Et al)

Even with using a CFV from drvspace/stacker, there is a 1gb limitation, with further limitation that it must reside on a FAT16 (or FAT12, if floppy) volume.

wierd_w wrote on 2026-06-19, 12:32:

That's correct. It's about the closest I know of to doing what you want. […]
Show full quote

That's correct. It's about the closest I know of to doing what you want.

DOS was never really an environment where "Huge amounts of mass storage" was ever really a thing, that you could just have gigabytes worth of single files to use like disk drives.
(2gb limit for FAT16 for DOS6.22, etc. 4GB limit for single files, on FAT32. Et al)

Even with using a CFV from drvspace/stacker, there is a 1gb limitation, with further limitation that it must reside on a FAT16 (or FAT12, if floppy) volume.

Yep, totally understand. Aim was for these disk images to range from say 200MB to a max of about 2GB anyway.

Cheers!

Hi, I think that might be a good use case for the DOSBox image mounting feature!
Maybe the code can be somehow adapted for real DOS?
Perhaps by making it a TSR or a DOS device driver that uses network interface like MSCDEX uses?
I'm just thinking out loud, since DOSBox is really good at virtual filesystems, I think.
It's likely easier said than done, of course.

DOSBox works by putting invalid opcodes in the vector for INT 13, which the cpu core captures and translates into host operations. There's no way to do that on a real machine.

Hi,

While the invalid opcodes method wouldn't work on a real machine, it would be possible to replace the int 13h handler with a custom one that redirects writes and reads to a file, of course the TSR would need to save the original interrupt vector and if the interrupt is called with one of the real physical drives it would need to call the original interrupt handler, it can be done by pushing the far address of the original interrupt handler to the stack and doing a far return.

This would have the following shortcomings though:

• It will not work for programs that do direct HW access through I/O ports, and might actually result in corrupted data if a program attempts to do this to a disk that doesn't really exists.
• Might have problems with programs using DOS extenders, like DOS4/GW
• Most likely wouldn't play nice with SMARTDRV.SYS and similar disk caching programs.
• It will slow down each I/O operation going through the interrupt because of the logic to check whether a disk is a real one before doing the custom file code or calling the real interrupt.

But if it is only needed for known programs that run in real mode and only use the interrupt handler and not direct I/O access to the disk and also performance is not an issue, it most likely would work, so it would be useful for that subset of cases.

It woud help to know exactly what/why you are trying to accomplish.

I can't see a reason to store and image on a DOS drive/filesystem and make it appear as a differet drive.

To access certain files as a differnt drive, I'd put them in a DIR and use SUBST.

If you want to access such files remotely, I'd use net mount or Brutmans tools.

It would be very hard to access in "image" under DOS while accessig it as it's own filesystem... If you have a reason you want it to be an image, prob best to do it at BIOS level - DEFRAG then create the image (so it's contigous) then hook BIOS interrupt to fake a drive accessing that region of the original hard drive.

You might also be able to create something that works llike INTERLNK also.

Don't know if this is what you're looking for or not but likely better than dealing with TSRs.
https://www.plop.at/en/pbm6/full.html
https://forum.plop.at/index.php/topic,448.0.html

IDE: Hard disks, CD/DVD drives. SATA: Hard disks, CD/DVD drives. USB Controller: USB 1.1 UHCI/OHCI, USB 2.0 EHCI, USB 3.0 xHCI s […]
Show full quote

IDE: Hard disks, CD/DVD drives.
SATA: Hard disks, CD/DVD drives.
USB Controller: USB 1.1 UHCI/OHCI, USB 2.0 EHCI, USB 3.0 xHCI support.
USB Device support for keyboard, HUB, thumb drives, hard disks, CD/DVD drives.
USB read/write support.
USB Hot-Plug.
Boot drive partition.
Start drive MBR.
Boot CD/DVD in no-emulation mode.
Eject CD/DVD.
Show drive details.
Change screen resolution, also wide screen.
Start PMB6 from Floppy, CD/DVD drive, network, Linux Boot Managers, Windows Boot Menu (Vista/7/8/10).
Morse codes with PC Speaker.
VHD/VHDX mount and boot.
Viewer: Hex and text view. View sectors and files.
File Commander: Read only for FAT12/16/32, exFAT, NTFS and ext2/3 file systems.
Config file support.
Configuration through kernel command line.