• Please review our updated Terms and Rules here

On drive overlays and cloned images

Old Thrashbarg

Veteran Member
Joined
Jul 7, 2009
Messages
661
Location
Central FL
My actual question is pretty simple, but first I should probably give a bit of background to fully explain the rather unusual situation I'm facing. I recently got an HP Internet Advisor... one of those network analyzer laptops. It contains all sorts of specialized hardware related to the network functions, but at the core it's basically a regular 486 system, running Windows 95.

One of my first acts after getting the machine was to take an image of the hard drive. It didn't come with any of the install disks or anything, nor do I know where to get them, so the only copy I have of the specialized software is the existing installation on the drive... a quite old drive which is making noises a drive shouldn't normally make. :-o

The BIOS has a 528MB limit, as one would expect on a 486. The existing hard drive is apparently a later replacement... it's an 800MB drive, but only 528MB of it is being used, in a single partition.

What I would like to do is replace the hard drive with a flash drive, I'm thinking either a DOM or an industrial CF. I could use a 512MB card to stay under the BIOS limit, but the problem is that free space is already a bit tight... there's only about 30MB free on the existing partition, and though the imaging software will allow me to resize it down to fit on a 512MB drive, that would leave hardly any free space. So I pretty much need to put a larger drive in there. A 1 or 2GB drive would be plenty. Obviously there's not any simple way of adding an XT-IDE universal BIOS or anything of that sort, so my only other option for using a larger drive is an overlay software. But this is the part where I get stumped:

I've used drive overlays before, but it was quite a few years ago, and I've only ever set it up on blank drives, and then created partitions and installed an OS. That's the standard procedure, and the only one that's mentioned in any of the documentation I've been able to find for such software. But in this case I'm not going to be installing an OS... I need to restore an existing partition from a disk image. Is there any way to make that work? Or is there perhaps a simpler solution that I'm overlooking?
 
Will it be adequate to restore just the files from the partition, or does it have to be the whole partition, warts and all?

The way a DDO works is to occupy the first track of hard drive and then load (usually taking a bit of memory off the top) a resident that takes the existing drive geometry and translate it into something with fewer than 1024 cylinders and then plant its own version of INT 13H in memory. Works pretty well for DOS and Windows 3.x, but not so well for OS/2 or NT.

So, simply recovering the files may be adequate. If not, you can image the partition, but only after booting up the DDO on the drive.

I hope this isn't clear as mud.
 
While disk imaging certainly has certain advantages in other situations you just might do better with a disk clone in this case. If you install a DDO on the new drive and then clone the old drive to it you just might get lucky. :) Of course, you'd need to boot from the drive with the DDO (or an appropriate floppy) in order to be able to clone to it.
 
Will it be adequate to restore just the files from the partition, or does it have to be the whole partition, warts and all?

Y'know, I've gotten so accustomed to dealing with XP/Vista/7 that I'd completely forgotten Win95 was more tolerant of just moving the files around... and now that I think about it, I remember transferring whole installs to new drives with xcopy.

So I guess there is a simpler solution I was overlooking.

Now a new question... which overlay software to use? I've long since forgotten the specifics about the various different ones. I do remember they were all kinda irritating to deal with for various reasons, but does one suck less than the others?
 
Last edited:
Y'know, I've gotten so accustomed to dealing with XP/Vista/7 that I'd completely forgotten Win95 was more tolerant of just moving the files around... and now that I think about it, I remember transferring whole installs to new drives with xcopy.

Only so tolerant of course...you've got the registry and all to deal with. Back in the day (Windows 95 days), the place I worked for built PC's and came up with a way to "image" them without software...here's what we did:

Get the target drive set up as a secondary drive. Boot, fdisk, format w/system.

Boot Windows 95, set to show all files, system files, etc. Open the C: drive, select all, then de-select the Windows folder, then copy all to the target drive. If you get an error copying any other files, de-select the problem one as well and try again...but I don't think there were any that had to be skipped in the root. You'll also probably want to close everything you possibly can before starting, especially if there are lots of auto-starting utilities, etc...probably a good idea to Ctrl+Alt+Del and end task on most everything but explorer and system and whatever the other couple required processes were for Win95...it's been too long for me to remember for sure!

Create a Windows folder on the target drive. Open the Windows folder on the C: drive, then select all, then de-select the swapfile, which Google seems to remind me is win386.swp and that sounds about right. Then copy to the target drive's new Windows folder.

Once finished, go to a command prompt and tell it "sys d:", assuming D: is the target drive...otherwise the system boot files may be goofed up from overwriting.

If the partition of the new drive isn't set active, which it won't be if you fdisk'ed it as a secondary drive, you will need to make it primary...boot from a floppy, then use fdisk to set it active.

Of course in your case, you'll need to set up to overlay when you are fdisk'ing, etc...but that should work to get you where you want to be. Assuming you can find a way to have both drives active using a laptop...

Wesley
 
Some people simply opted for controllers with their own BIOSes, rather than relying on the host system.

I just put away a 486 system with a SCSI controller driving a 4GB Seagate Hawk--the system has Win98SE, Warp 4, NetBSD 4.0 and NT 4.0 all set up as multiboot. There were IDE controllers with large-disk BIOSes as well. I have a 386 running Win95B on a 9.1GB SCSI drive as well.
 
Some people simply opted for controllers with their own BIOSes, rather than relying on the host system.

I just put away a 486 system with a SCSI controller driving a 4GB Seagate Hawk--the system has Win98SE, Warp 4, NetBSD 4.0 and NT 4.0 all set up as multiboot. There were IDE controllers with large-disk BIOSes as well. I have a 386 running Win95B on a 9.1GB SCSI drive as well.
Yes, but i don't see that helping the OP with his proprietary laptop.
 
Yes, but i don't see that helping the OP with his proprietary laptop.

Oh, I understand that. My response was more to Caluser2000.

It might be worthwhile investigating if the drive interface will support two CF drives--there should certainly be room in the old hard drive space for that.

There is the option of Drivespace also, although the memory footprint may be too large.

Finally, there's the option of including a loadable device driver that creates a partition on the unused part of the drive past 528 MB. I used one such driver for some time back in the day.

Do we know what the 486 system at the heart of this thing really is? I'm still wondering if a BIOS upgrade might not be possible.
 
I'm well aware of the other options. I've got both scsi and an IDE controller with it's own Bios. SCSI drives are not readily available down here but larger IDE drives seem plentiful. DDO seems to just work fine on my 386 for my humble needs.

An advantage is the ability to swap the hdd to other lower spec machines if needed. a 286 for example-what the hdd was set up for, or a 486 without resorting to having to find another suitable controller or nic with xtide bios for that matter. Plug n play.

Regarding xcopy. On OS/2s version I understand is better at saving file attributes with the correct switches. If the drive is Fa16 you might be able to use OS/2 boot disks for the cloning.
 
Last edited:
Do we know what the 486 system at the heart of this thing really is? I'm still wondering if a BIOS upgrade might not be possible.

Though the basic architecture it uses is nothing particularly unusual (486SX/25, LSI/Headland chipset, Cirrus GD6420 video, PC87311A I/O controller), the actual setup of the thing is completely proprietary. Here's the main board:

MVC-003F.JPG

It uses a socketed BIOS chip (which may even be an EEPROM), but it looks like it already has been upgraded... the sticker on it has a 9645 date code. I figure, if they hadn't added large drive support by November '96, it's doubtful that they ever did.

The I/O controller itself should support two drives, but I don't believe the BIOS does. Unfortunately I can't double-check that right now... the way it's laid out, I'd pretty much have to put the entire thing back together to power it up, and it took me close to 2 hours to get it apart in the first place, so I really don't want to do that again. It is, by far, the single most difficult machine I've ever worked on. I think I will end up making some modifications to it, so I can at least get to the hard drive more easily in the future, should the need arise.
 
Can't he just pull the drive out, hook it to a more modern pc that supports the drive, with another of the same, and just clone it that why while the drive still lives? or do that and go to CF at the same time?

And Chuck
Seagate does this with their Disc Wizard software, it's hot i got my 3tb drive working to full capacity on my non-uefi. you partition the 2.2tb normally, the disc wizard loads a driver so windows sees the last 800gb as it's own partition and it's own drive letter, with the ability to turn it off and on

Oh, I understand that. My response was more to Caluser2000.

Finally, there's the option of including a loadable device driver that creates a partition on the unused part of the drive past 528 MB. I used one such driver for some time back in the day.

Do we know what the 486 system at the heart of this thing really is? I'm still wondering if a BIOS upgrade might not be possible.
 
Heh, I rolled my own driver for DOS back in the 80s when I began buying MFM drives with 1224 cylinders. (Most BIOSes only supported 1024, so the other 200 had to be gotten at some other way). I still have the code kicking around somehwere...
 
Uh, yeah, but SpeedStor's not an installable device driver.

The device driver or network redirector model is far more flexible. You keep the existing BIOS geometry of the drive visible and there's no proprietary "mystery" software involved.

If you use the network redirector model, you can put terabytes of drive storage accessible to DOS applications. Of course, a file can't be more than 2GB in length, but that's hardly an onerous restriction.
 
Last edited:
Uh, yeah, but SpeedStor's not an installable device driver.

The device driver or network redirector model is far more flexible. You keep the existing BIOS geometry of the drive visible and there's no proprietary "mystery" software involved.

If you use the network redirector model, you can put terabytes of drive storage accessible to DOS applications. Of course, a file can't be more than 2GB in length, but that's hardly an onerous restriction.

Chuck(G),

When you say network redirector are you saying using a shared volume or are you referring to a program that sets up a drive letter on the system and redirects all read/writes to a network volume?
 
No, I really mean using the network redirector "hook" and API to access any kind of storage. Think about a CD-ROM drive, for example. On DOS/Win 3.x/9x, MSCDEX (or its 9x equivalent) creates what appears to be a local network volume, but no network software is involved (e.g. MSLANMAN).

In fact, MSCDEX is its own filesystem that simply hooks its API into DOS's. This can come in handy when you have to materialize non-DOS file systems--and particularly file systems that don't have standard-sized sectors or filesystems that don't resemble DOS's.

You know, with large (at least in 1980-90s terms) drives being so inexpensive, it might be an interesting experiment to simplify the file allocation system to a simple contiguous-area type for older DOS machines. No FATs or worrying about allocation issues--just segment the disk space off into small (under 100 MB), medium (under 500 MB) and large (under 2GB) file areas and fixed-allocate each file the same amount of storage. No file fragmentation issues and easy-to-recover accidentally erased files.
 
Last edited:
Chuck(G),

After I posted I did some googlefu and found a couple of interesting links (explanation and SW dl). So while I see the over all concept I am not sure how this would still work? Wouldn't you need most components of a network to make it work (NIC drivers, a transport protocol at the least)? So what is the advantage over just sharing a directory off of the server?
 
No, the DOS network redirector is invoked by "hooking" that all-purpose multiplex interrupt in DOS--INT 2FH and intercepting calls with AX=11xxH to your own code. The format of the data passed along by DOS is a bit higher level than at the DOS device-driver level. That is, the file interface is somewhat more abstracted, so it can support a wide variety of devices, be they CD-ROMs or network-connected drives.

A couple (?) of years ago, I posted some code showing how this works, but I don't recall the name of the file now. Perhaps a search will turn it up, if you're interested.
 
Back
Top