Raw Hard Disk image or VHD mounting?

[awkduck]

Anyone know if there is a drive/application that can do this? I'm looking to mount it as a device letter.

I know Qemu can run with a disk image, while you copy files over a shared FTP folder.

Also, DosBox can mount a hard disk image, and a shared folder as a virtual drive. Files could be copied that way.

WinImage allows inserting and extracting files, from a disk image.

I could also use Grub4Dos and mount the image as a secondary drive.

Is there a better "native" way?

[jaclaz]

Not what you asked for, but older versions of Diskinternals Linuxreader *should* run on 9x (at least there is a .vxd in version 2.0).

It allows mounting disk images and save files from them (read only access), but no drive letter.

jaclaz

[awkduck]

@jaclaz Thanks for the tip!

I have something working. But it isn't ideal, or a solution for large hard disk images.

I downloaded RamDisk98, from one of the many Simtel FTP clones.

If my disk image has the same partition size, as the RamDisk98 saved partition image, I can use HxD to copy the data between the two.

So the image size is limited by the amount of free ram you have. You need enough ram, left over, for HxD's copying in order to paste. So it's better to save the ram image, then operate "afterwards" without the ram disk.

For me, the ram disk does not start and stop, as described in the readme. Edit: now works

Mapping a disk image, with Grub4Dos, is still easier.

I'll install Paragon's Harddisk Manager 6, to see it I can do something similar with the included Image Mounter. They have a header, on there created disk images. As long as the image is not compressed or encrypted, it saves it raw. But this would only work for people with this software.

Update: Image mounter couldn't unmount Paragon's own images correctly; the changes were not saved. It seems like a Win98 compatibility issue. Otherwise, it seems as if it would have worked. Mounted images, that had been modified by raw disk image partition data, displayed contents of the original raw partition.

Alternatively, the "README.TXT" included with RamDisk98 say:

Quote

The RAM disk driver core in RamDisk98 is based upon the source code provided
with Walter Oney's excellent book Systems Programming for Windows 95 from
Microsoft Press. What I did was to pick up where he left off by trying to improve the
boot sector initialization of the disk (and fix a few of Walter's bugs) to properly emulate
a hard disk or a 1.44MB or 2.88MB floppy drive. I also added the registry interface
and disk image load and save, as well as the shareware splash screen and configuration
utility.

  If there is enough usable code, in there, maybe something could be (re)written for a ram or file image.

Edited February 17, 2023 by awkduck

[jaclaz]

Sure, grub4dos mapping is the easiest/most convenient, though of course it has the limitation of needing to either reboot or know before booting that you will need to mount the image.

Being essentiially a plain BIOS mapping it surely works reliably in DOS, under the Win9x GUI I would be anyway careful.

I don't think that anyone is going (today) to attempt writing a driver/program for DOS/Win9x of such complexity.

I believe that one of the reasons why there aren't as many - please read as "none" - such programs/drivers for Win95 while there are (were) quite a few for NT and 2K is due to the lack of some handy sub-systems/cpmponents.

It is more likely that some of the good people working on FreeDOS may create something (for DOS/FreeDOS), more like srdisk or XMSdisk, but for filedisk mounting as opposed to ramdisk.

At least good ol' SHSUFDRV:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/shsufdrv/

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/shsufdrv/fdrv-3.txt

is fine with DOS and WIn 3.x, but not with Win9x.

jaclaz

EDIT:

Before I forget, check also this:

http://hp.vector.co.jp/authors/VA013937/editdisk/index_e.html

(again not what you asked for but maybe useful)

Edited February 17, 2023 by jaclaz

[awkduck]

8 hours ago, jaclaz said:

Sure, grub4dos mapping is the easiest/most convenient, though of course it has the limitation of needing to either reboot or know before booting that you will need to mount the image.

Actually, this is the reason for the OP. I'm kinda spoiled, and don't want to reboot.

8 hours ago, jaclaz said:

I don't think that anyone is going (today) to attempt writing a driver/program for DOS/Win9x of such complexity.

Depending on how much was already present, in Walter Onely's book, I had thought about it. I like systems programming; just maybe not Windows 95/98 systems programming (or any modern system). Time is always an issue. In spare time, if it took half a year, I would probably not have ambition for it. A couple months, of poking around to completion, and yeah. But anything more than that, and I'd rather work on a project that solved more problems. That's for another post.

8 hours ago, jaclaz said:

may create something (for DOS/FreeDOS)

:) Yes, that has crossed my mind.

I did end up getting RamDrive98 to mount/unmount, without a reboot. The project, I am working on now, can use "Fat16"; requiring, a maximum of, half a Gigabyte. So this will work, for now. The main issue has been file permissions. Many alternatives would require  manually setting file permissions, after injecting files into the image. And there are a number of files, where the permissions are important.

I really doubt anyone will follow, using this method. But the Internet is big. If you do, pay close attention to the data, "right" after the end of the partition's first sector. Those few blocks may not match, between the two. You can probably leave them, as they are, for each image. In the raw disk image, search for "fat16"; also sector 63, depending on your editor. The size of the partitions need to match. This limits the usefulness. As I am creating the raw image " blank", this works fine for me. I can just match RamDrive98's partition size, by messing around with Qemu's "qemu-img.exe".

[jaclaz]

The differences may be due (indirectly) to the sizes of the images, with small disks (or images) it often happens that different programs or BIOSes or OSes attribute a different geometry or calculate differently the geometry, and then similarly both the partitioning and formatting processes may result in differently sized voiumes.

jaclaz

 

 

[jumper]

I've been using RamDisk98 for decades. Versions up through about 3 included source code, but I've never been able to locate any of those. If @jaclaz could find one, that would be the source to use and I'd be in for modifying it. We could reduce the memory footprint to only hold the tables, not the data clusters, then read/write the data from/to the image on disk on-demand.

 

[SweetLow]

9 hours ago, jumper said:

then read/write the data from/to the image on disk on-demand

If you will try to do this then pay attention on problem of accessing (IFSMgr) files from point where (IOS) requests serviced. There are some notes in IOS Guide about it.

P.S. And I can suggest other direction of RAM Port Driver enhancement - using above 4G memory...

Edited February 23, 2023 by SweetLow

[jaclaz]

I still believe (maybe wrongly) that the code for a "filedisk" driver will be very different from a "ramdisk" one.

In any case the "base" should be a driver for which the source code - besides being available - is also free to use/modify, besides the mentioned ones, there is the one by rudolph loew that the family kindly released after his death:

https://rloewelectronics.com/

https://rloewelectronics.com/distribute/RAMDISK/

jaclaz

 

[SweetLow]

1 hour ago, jaclaz said:

I still believe (maybe wrongly) that the code for a "filedisk" driver will be very different from a "ramdisk" one.

Not in VXD. If you have rich API then dealing with memory and files does not differ too much.

But the problem with .PDR is location of code that try to touch files.

1 hour ago, jaclaz said:

In any case the "base" should be a driver for which the source code - besides being available - is also free to use/modify, besides the mentioned ones, there is the one by rudolph loew that the family kindly released after his death

It is DOS driver unlike RamDisk98 which is Windows IOS Port Driver.  These are really different things.

[ABCDEFG]

5 hours ago, jaclaz said:

I still believe (maybe wrongly) that the code for a "filedisk" driver will be very different from a "ramdisk" one.

In any case the "base" should be a driver for which the source code - besides being available - is also free to use/modify, besides the mentioned ones, there is the one by rudolph loew that the family kindly released after his death:

https://rloewelectronics.com/

https://rloewelectronics.com/distribute/RAMDISK/

jaclaz

 

Most of the source codes there is obfuscated.

TrueCrypt 1.0 souce code can be used for a ramdisk development.

Edited February 23, 2023 by ABCDEFG

[jaclaz]

18 hours ago, ABCDEFG said:

TrueCrypt 1.0 souce code can be used for a ramdisk development.

Maybe then the previous scramdisk:

https://web.archive.org/web/20080123131324/http://www.samsimpson.com/cryptography/scramdisk/

jaclaz

[ABCDEFG]

@jaclaz

Yep Scramdisk or E4M or TrueCrypt.

[awkduck]

I'm a bit late, back to the thread. I watch an elderly woman, about every other week. When I am there, I don't do tech. Simply because, I get too drawn in. Sometimes, she only gives subtle hints of her needs.

On 2/23/2023 at 1:00 AM, jumper said:

I've been using RamDisk98 for decades. Versions up through about 3 included source code, but I've never been able to locate any of those.

Great tip!

I (too?) will look into the various sources mentioned. Old stuff is getting hard to find, but I'll try hunting for Ramdisk98 source.

I'm not entirely opposed to buying a copy of Walter Oney's book/CD (about $6). There are a couple of other books, along the same line, I am looking to snag anyway.