If you’re not an information technology type, stop reading this right now. If you’re actually in I.T., this entry is liable to bore you to tears. If you’re not, reading this may cause one of your internal organs to fail spontaneously, just for the adrenaline jolt the rest of your system will need to keep everything from failing at once from systemic, catastrophic boredom. You heard me right: one of your organs will throw itself nobly into the abyss, in the hopes of saving the others. If you press on, and if you make it out alive, call me from the hospital and let me know what part of your internal mechanism was the noblest and most courageous of them all. Feel free to call collect, I’m here to listen.
I’ve warned you, though, so from here on in you have only yourself to blame.
I work at a library, and I spend a pile of time making really, really old software work on modern machines. A remarkable amount of this software binds the data very tightly to the application, often though obscure or one-off data formats, but more often the programs just rely on things that should never have worked in the first place.
It’s a minor miracle that a lot of these things can be made to work at all, but it’s often doable, once you’ve convinced it that not every drive out there is C, that it shouldn’t install its own version of Adobe 2.0, or whatever other cat-swinging needs doing. I’ve become pretty good at this onerous process, so I’m going to share it with you, in the hopes that this not-so-much-hard-won-but-tediously-plodded-towards knowledge might benefit the two of you who stumble through here via misspelled Google searches three years from now.
To list them off, the various sins of ancient Windows-ware are as follows:
- Believing that it can write to or read from anywhere on the hard drive, whenever it wants, and the corollary,
- Believing that there is only one user, or one kind of user.
- Believing that all hard drives are C:\ or that all CD drives are D:\ or some combination of two.
- Insisting that the CD be installed when the program is run, always.
- Worse, insisting that the CD always be in the same drive it was in when you installed it, and, finally,
- Installing its own, archaic versions of helper apps.
All of these problems are soluble, to some degree. The power tools for dealing with most of these problems are Alex Feinman’s very-excellent ISORecorder power tool and a small piece of barely-documented, completely unsupported and wildly useful piece of software from Microsoft called the WinXP Virtual CD Control Panel. The former lets you take an image of the CD in your drive, and the second one lets you treat that image file as an actual CD-Rom drive with what appears to be some clever low-level fakery.
So, the order of operations that works best for me so far has been:
- Take an ISO of the CD.
- Mount that ISO on a low drive letter, and install from that piece of media. Run as admin, see what happens. If things don’t work at this point, you’re probably looking at one of two things, the “Must Be D:” problem or the “Not My Version Of Windows” problem. The MBD problem is a little finicky, but you can use the administrator’s tools to move your actual hardware CD-ROM to a different drive letter and remount the ISO in the vacated drive letter. The windows version problem can frequently be fixed by choosing a different compatibility mode for the program before running it. I don’t know if it actually changes the way things like memory allocation are handled or just lies to it about the version of windows that’s running, but sometimes (and in some very wierd places) that trick works.
- Once you get it running as admin, use “Run As” to try running it as the unprivileged user. The problems you get here are pretty much exclusively fileperms-related, so once you’ve figured out where it wants to write its .tmp or .ini files to, you can modify the security permissions to give users read/write permissions to the right places. Doing a find-all-files modified on today’s date is an OK way of tracking that stuff down.
- If that works, your final testing is to log out, log in as the user and try it again. Should work, you’d think. The upside of all this is that old software virtually never pokes at the registry, so you don’t need to go swimming in that sewer. Avoid giving the user “modify” rights to things – just use read/execute on the .exe files, read/write on the configuration files, and read on everything else.
As for helper apps, typically Acrobat but occasionally others, the only thing I’ve found that works (lets the application call Acrobat 7 instead of 3) is to copy the entire freaking directory from under “C:\Program Files” to wherever the application thinks that it should be, deleting the old version outright and replacing it by renaming the folder and executable name of the helper program to whatever the old one was called. Check your ownership and fileperms of these things, too.
After that, you’re pretty much reduced to mucking around in .ini files and other randomly-named configuration files by hand (even, occasionally, .bat files, gak) to figure out where it says “d:\whatever” and replacing that with whatever you think it should really be. One trick that rarely-but-sometimes works is using Environment variables instead of hardcoding letters, but I promise nothing.
The only practical upshot of any of this is that you can also use those two tools to mount 20 or so modern CDs at a time, once you’ve taken their ISOs and saved them. Takes up the drivespace, it does, but it’s almost impossible to scratch an ISO file when you’re on the road.
If you found any of this useful, well, I hope that it made your life a little easier. If you didn’t, well, I told you so.