Bit Rot

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:

  1. Take an ISO of the CD.

  2. 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.
  3. 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.
  4. 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.


  1. Mike Bruce
    Posted October 20, 2005 at 2:41 pm | Permalink

    mount -o loop foo.iso /mnt/foo

    I used to use something called (for mysterious reasons) Daemon Tools to mount isos in windows. I had no idea that there was an official tool for that.

  2. Mike Hoye
    Posted October 20, 2005 at 4:37 pm | Permalink

    Yes, yes, we all know the loopmount bit.

    The important thing here is not “can I see the files.” I would not have gone on for pages about this if all you needed to do was open a command prompt and fire up xcopy.

    Fact is, if this were Linux it would only be differently hard, and possibly differently-impossible.

  3. Mike Bruce
    Posted October 20, 2005 at 4:56 pm | Permalink

    It almost certainly wouldn’t happen on Linux. Unix apps, at least every one I’ve seen, use paths. Even if they’re hardcoded, they’re still just paths. Since you need certain access to fiddle with the actual /dev/hdx for the drive, and that historically hasn’t been available, it would be mindbendingly insane for a unix app to require direct access to it just to run.

    Even in that weird case, the /dev/loopN device might be an acceptable substitute.

  4. John
    Posted October 20, 2005 at 6:44 pm | Permalink

    Actually, that was useful – the fake CD-rom program, at least.

    I apparently have no life.

  5. Mike Hoye
    Posted October 20, 2005 at 7:36 pm | Permalink

    Bear in mind that these are proprietary applications we’re talking about, not recompilable things. We wouldn’t be looking at path problems, we’d be looking at binary-compatibility problems. The fact that this is not a huge concern outside of the occasional bout of DLL-hell on the Windows platform has been an ongoing miracle for about ten years now.

  6. Mike Bruce
    Posted October 20, 2005 at 9:10 pm | Permalink

    Sure, sure. But that’s a different problem altogether.

    Your big deals with binary compatibility on linux would be the binary format and the support libs (tip to proprietary software vendors: compile in your external dependancies). The binary format would only be a thing if we’re talking about seriously ancient stuff, but it isn’t insurmountable (I’m pretty sure you can still load up a.out support). The support libs would be a little bit of an adventure, but wouldn’t be impossible unless there was some kind of kernel API madness. Which seems unlikely.

  7. Jamie
    Posted October 21, 2005 at 10:54 am | Permalink

    Mike, I read right-wingnut columnists for FUN (re: self-abuse). Really, I’ve already developed an immunity to anything you could possibly throw at me. :) As it was, this was an interesting read.

  8. Melanie
    Posted October 21, 2005 at 11:51 am | Permalink

    With an intro like that, how could we not read? Oddly, most of that actually made sense to me. Not that I have any practical use for it in my daily life….

  9. Guillaume
    Posted October 21, 2005 at 12:51 pm | Permalink

    Quite a good read if you ask me. I’ve been using Daemon Tools for a while now since the Microsoft tool doesn’t let you bypass SecuROM and other such nonsense. This is one of those reasons that I wish I still had a good mac. OSX has classic mode, and even then, you could mount an ISO (dmg (or even smi)) directly through the OS.

  10. Mike Hoye
    Posted October 22, 2005 at 4:18 pm | Permalink

    I’m frankly amazed at the lot of you.