There are many complaints about the difficulty of uninstalling software of various types. This page addresses only one aspect which is particularly painful - shared files - because it affects CD-R operations. The end point is worth raising first so that those who already understand are spared the lecture. It is that some software components cannot be uninstalled because their necessary predecessors cannot be recovered. Therefore, the only practical way to get rid of them is by restoring a backup.
A program installed into Windows will typically have three groups of files: executables stored in its own folder(s); overlays, libraries, data and related files also located in dedicated folders; and common elements, often DLLs (Dynamic Link Libraries), which are located in such folders as Windows and Windows\System. The common elements are available to all applications. (There is a fourth group, elements common to programs of a family or a vendor. They share properties with the local ones and the common ones as should be apparent from what follows.)
One of the (in)famous collections of common files is the ASPI layer which translates between Windows and SCSI or SCSI-emulating devices. The separate modules form a set of which some are needed for any such communication and others only for selected jobs. The particular modules depend on your OS: NT/2K and 9x/Me use different components. Microsoft ships an outdated but functional ASPI layer with the OS - one which is sufficient for basic operations but cannot properly support CD-R.
When you install a version of ECDC prior to 4.02, an updated layer is installed with it if possible. "Possible" means that it will not overwrite a "newer" module with one which appears to be older. So if another program installed part of the ASPI layer with a later date, the update from ECDC will not replace it. The result is an inconsistent layer which can be corrected by removing the inconsistent files by hand. [Sidebar: There is another problem which arises when a program puts a version of a common file into its own folder. If that program runs before something else loads the common file, the local version will be brought into memory and will keep the system from loading the common one. In that way, your system may test fine for a consistent layer but at times have an inconsistent one - a clashing component was loaded by a 'rogue' program. Note that this is only one of the ways that ignoring programming rules can introduce problems. A more common one is a publisher modifying one of the common elements incorrectly and overwriting a valid version with its own.]
After installing a program which modifies the ASPI layer, what can be done with the files in the layer if you uninstall? They cannot be deleted because the other ASPI functions would be lost. The old ones can't be put back in because they're no longer there to restore. So the updated layer is left behind. 'Way back in the third paragraph, I mentioned that the ASPI layer interfaces for SCSI devices and for those which emulate SCSI. That emulation is used for IDE (which is why your IDE controller shows up as a SCSI device) and for many others. If you install a scanner, it may choose to update modules of the ASPI layer. Since the scanner manufacturer usually neither knows nor cares about CD-R, that "update" may kill a perfectly acceptable set of common elements. Uninstalling the scanner does not solve the problem because you can't recover the lost (valid) components with uninstall. The problems with rogue installs ulitmately reached the stage where Adaptec gave up on maintaining sanity. ECDC from 4.02 does not use the ASPI layer. The necessary communication is built into the local software and bypasses whatever is in the common files. That allows the CD-R software to run in the face of uncontrolled modifications being introduced by others. It's an unfortunate resolution since it leaves the chaos to be solved by everyone else and it wastes space on your hard drive, but it's understandable. The bottom line is that if you want to do a real uninstall, you had best restore from a backup.
You *do* make a complete image backup before any such installation, don't you? I was sure you did.
P.S. - I'm not ignoring the partial backups of GoBack and other programs. They *may* work depending on the code and the situation. Restoring from backup *does* work - reliably and repeatedly.
E-mail me at cdrecording@mrichter.com
Return to Mike's home page