All the stuff I’ve looked at starts at too abstract a level for me to get any traction, so I’m looking for a very practical explanation of how I could use a Linux install with an x86 virtual machine to allow me access a hard drive running DOS 6/Win 3.1.
In my imagination, I would install the hard drive in the Linux box, install the virtual x86 software, configure the software to emulate the processor the hard drive was previously running on, and then boot the hard drive inside the x86 software.
How far off am I?
BTW, I stipulate in advance the value and correctness of any and all advice on how I should abandon anything I’m still running on a 16-year-old platform. Thing is, I can’t abandon the platform until I can access the data and it and promote it forward to later platforms.
Basically a specialized OS for mounting virtual machines. Once you have an installed hypervisor you can theoretically be running 4-5 VM’s all of different OS’s side by side on the same hardware.
Also since its an old windows partition, a windows VM should have little trouble mounting it on an any existing windows machine.
Here’s how I’d do it:
1- Install Linux on a new computer
2- Install the Virtual Machine program of choice
3- Start a Virtual Machine. Install Windows 3.1 on that VM.
4- Install the apps you were using on your Windows 3.1 machine.
5- Copy the data you were using on your Windows 3.1 machine into the new Windows 3.1 VM.
6- Resume operations.
Now, you certainly COULD convert that real hard drive in your old machine into a virtual disk image on your new machine. You could also, if you choose the right software, mount that drive in the new system, assuming you want to buy the right adapters or choose the right motherboard.
However, I’ve found that you’re best off installing the OS you want to run on your VM from INSIDE OF the new VM. Migrating an existing real install of your OS over into a VM can sometimes bring problems from the old OS install into the VM. Why bring luggage?
There’s the additional issue that the old install will sometimes freak out because the VM that it sees when it first boots up is too different from its old real-life machine, and it might wind up not being able to properly drive all of the ‘hardware’ it expects to be able to drive.
Disclaimer:
My VM experience is slightly out of date. Most of my experience is confined to VirtualBox, MS Virtual Machine, and VMWare Pro. I have never virtualized Windows 3.1.
There are P2V (physical-to-virtual) utilities out there, where a running (physical) computer can package itself for execution in a virtual machine environment. But I’ve never seen such a utility for DOS / Windows 3.1.
I agree with Mr. Slant: if it’s possible to install from scratch, it’s the safest way to proceed. Note that installing MS-DOS in a virtual machine is not necessarily simple, because diskettes are so 1990s. If you’re using VMWare, it may be simpler to start with a prepackaged appliance .
So very glad I asked. Thanks, all, for the comments. Sounds like the simplest thing for me to do at this time is just keep my old Dell OptiPlex GXa happy and healthy.
Assuming we are talking about a business app where you are not worried about the latest graphics drivers and such many XP class machines would happily install dos6/win3.1
The nice thing about mounting it as a VM is, its on present day newer hardware that can be fixed and backed up using present day backup solutions.
No, wait until you have a free minute and move the program to a virtualized environment. Make sure it works. Then move the data over. Make sure THAT works.
That way, when the motherboard on the GXa finally goes, you can pop the new system up, install your backup data set, and your business is back up and running inside of 2 hours.
If you wait, and the old system fails when you don’t want it to, it’ll happen at the worst possible time. You’ll be calling a guy like me over to do it, and there will be downtime to the end of your business dependent on the app. Then you’ll have to pay me, and you’ll feel like a schmuck for not developing an exit plan from the old system.
Here’s the other awesome thing about moving to a virtual machine:
Once you get through making a VMWare image or the like, you have a VERY portable little pair of files to migrate that system.
You can shut that Win 3.1 VM down at the end of one day, copy the VM over to a brand new machine you just bought, and within minutes you’re on a new box. And you can keep doing that from now until the end of the application that the VM runs inside of… and those will probably be around longer than you.
Don’t stipulate it. I’m still running 30 year old software on both 30 year old machines, and emulators on modern machines. Keep using it as long as it does the job, and nothing new does it better.
ETA: Can’t help you on Linux, I only do virtual x86 things on Winblows, because I haven’t learned how to do it in Linux (yet).
If it were me, I would boot the dos box using a Linux CD of some flavour (something pretty light for preference). Throw a usb drive on, and image the dos hard drive using dd. Move this file to your Linux box. Use the virtualbox command VBoxManage convertfromraw to convert this to a VDI image file, and hook it up to a virtual machine. Test.
Given that this is DOS 6/Windows 3.1, there will probably be few issues with virtualisation. You may need to disable dos level sound drivers in CONFIG.SYS/AUTOEXEC.BAT, and probably only use MS memory managers (so HIMEM.SYS only). Win 3.1 was pretty good at falling back to VESA SVGA drivers if the hardware changed. Give it a crack. More info here, but this is geared towards later Windows versions, so you will actually have less to do.
P2V tools are generally needed because NT class Windows systems have a propensity to be picky about the current config, and dislike being moved to new hardware. Mostly, it is assumptions about disk types, Hardware Abstraction and some specific processor functions that trip the process up (probably in the interests of boot speed). Linux tends to be more forgiving about such things, although you may need to build a new initrd or edit kernel boot options in the bootloader. Most setups have a rescue boot option that boots on just about any hardware.