This time, though, my gripe isn’t with InstallShield, but rather with whoever put together an installer I used recently.
As part of my recent hard drive purge, I had to use a partition manager program to reset a drive to NTFS (from extfs) so I could overwrite it with the tools I had at hand. I downloaded and used the demo of 7Tools Partition Manager, which did the trick. (Strangely, “7Tools” seems to be a brand/front for Paragon Software Group.) However, when I uninstalled the program, it left behind a little surprise which was not to be revealed until a few days later.
I recently started a project to rip my entire audio CD collection (and, at the same time, to disassemble their jewel cases and switch to storing the CDs in binders). I’ll have more to write about this project later, but for the purposes of this article, the germane bit is that the CD ripping program interfaces with the CD drive through the ASPI layer (wnaspi32.dll).
On Friday, I went to rip the next batch of my audio CDs, and Exact Audio Copy (EAC) began behaving oddly. It would correctly read the track information for CDs (and get the track information from FreeDB), but when I went to actually rip it, it would suddenly claim that there was no CD in the drive. No amount of coaxing or tomfoolery would convince it otherwise. Attempts to use the feature autodetect, read mode autodetect, and C2 check would fail. After going through this cycle a couple of times, and with different CDs, I was convinced that there wasn’t anything wrong with the hardware itself, nor EAC.
A random Google search for the symptoms I was seeing produced some hits. These were forum posts, usually for people with dodgy or missing copies of the ASPI driver, so I checked my copy of wnaspi32.dll, discovering, to my surprise, that it was left over from 7Tools Partition Manager. (The “last modified” date, as well as the presence of a digital signature from Paragon Software Group, were what tipped me off. The digital signatures tab can be viewed in the Properties dialog for the file.) I had to reboot in safe mode to delete it, although I’m not sure that was strictly necessary — I may have inadvertently left a program open that was using it.
Naturally, after deleting it, everything was fine. My speculation is that, behind the scenes, one of the two following scenarios took place:
- The demo version of 7Tools Partition Manager had a “nag timer” that would pop up after using the program for a certain period of time, asking you to buy it. The expectation of the programmer was that this screen was to be launched from Partition Manager itself, not from some other program via the ASPI driver, and some sort of problem occurred inside the driver as a result of this false assumption.
- Alternately, the demo would simply stop working after a few days, and included code in the drivers to prevent any attempt to circumvent the time restriction. These restrictions were not visible from other programs using the ASPI layer, except as mysterious errors.
I haven’t kept up with InstallShield lately, but I think it would be really helpful if there was some kind of testing feature that allowed a developer to check what’s left behind after installing a program, running it, and then uninstalling it. (This would also be useful for verifying that user preferences and data which is meant to persist across installations is stored in the correct location.) Making these scenarios easier to test would make it easier for developers to do the right thing, and be conscientious about their “residue.” The closer installers get to the ideal (a cross between the Hippocratic Oath’s “do no harm” and the outdoors philosophy of “leave no trace”), the better the user experience will be.