Welcome to Australian PC User Magazine Offline CD-ROM
WEB.gif (287 bytes) games.gif (257 bytes) Education General & Business Applications Online Tools - All your Net Essentials Utilities Patches & Support Files PC User Interactive - Exclusive tutorials
Software Contents

Home
Search
Help!

Using the PC User Offline CD Browser

Keeping it clean

Following from the March '98 article explaining how uninstallers work, Jan Wikstr÷m delves into how much handwork is needed once you have an uninstaller in operation, and how to do it.

As you will have noticed in the review last month, no uninstallation program is quite perfect, though some are better than others. To get the best result, you'll have to do some handwork, but keep the handwork down by getting an uninstaller that does a good job. As well as its uninstalling capability, you can look at other features, such as how well it cleans up dead Registry lines – and make sure your choice feels comfortable to work with.

Recapitulating from last month, the main problem in removing unwanted Windows 95 programs is that it's so difficult to clear program-specific libraries out of the \WINDOWS\SYSTEM folder, restore changed system libraries and clear command lines out of the Registry and startup files.

The program-specific libraries are more of a nuisance than anything else – they take up space but don't do any active harm otherwise. Mind you, that can be nuisance enough when your \SYSTEM folder contains 2500 files and weighs in at over 100Mb (my office system before the last cleanup) . . .

Changed system files are much worse, as they can interfere with the workings of other programs, and the orphan command lines in the Registry and startup files tend to slow down the system. This is because it takes longer to read the Registry and because superfluous drivers may be loaded into memory, where they take up precious room and consume processor time.

It's very difficult to clean up a system that's already cluttered with leftovers, though some uninstallation programs make a pretty good fist of it, as you will have seen in last month's review. If you really want to keep your system lean, mean and clean, though, there's only one way: start with a fresh system installation and carefully watch everything that is installed. This also gives your uninstallation program the best working conditions. There is even a shareware program that does a reliable job on a clean system. It's called InWatch95 and only costs $US15 to register.

 

Back it up!
There is only one way to deal with overwritten system files: make backup copies of \WINDOWS and \WINDOWS\SYSTEM with all contents in another place. Don't copy any of the other subfolders in \WINDOWS and don't copy win386.swp (it's the virtual memory swap file). Why don't we call the backups \CLEANWIN and \CLEANWIN\SYSTEM. Now, after each installation operation, we need to find out what has changed. For this purpose, I have resurrected and adapted a pair of batch files from our very first CD. They're called before.bat and after.bat (and how's that for originality) and you'll find them on the cover CD.

This is how you use them: copy the batch files to C:, then before you install a new program, go Start, Run and key in "C:\Before nnnnn" where nnnnn is a label of five characters or less so you can identify your data afterwards. After your installation is completed and you have done the first test of the new program, run "C:\After nnnnn".

This creates a text file C:\Checkdif\nnnnndif.txt, which contains information about what has changed in autoexec.bat, config.sys, win.ini, system.ini, C:\WINDOWS and C:\WINDOWS\SYSTEM. Due to the way the DOS command FC (File Compare) works, the folder listings can look a little strange: they include the last file before a change and the first file after, so just ignore those.

Let's work through an example; say you want to try FlimFlam 4.3 from Con's Games. First, you run "C:\Before flim", then you install FlimFlam as instructed. Your uninstallation program tracks the installation and files away its information. Shut down and restart Windows (many programs need this to be activated), then run FlimFlam long enough to customise a couple of things and try out a few of its features. Now close FlimFlam and run "C:\After flim".

Looking at C:\Checkdif\flimdif.txt, you find a new file called ff.ini in C:\WINDOWS; well, this must be FlimFlam's private INI file, so make a note of that, in case your particular uninstallation program doesn't "see" INI files. You also note that system.dat, system.da0, user.dat and user.da0 have changed. The DAT files are the Registry and the DA0 files are a copy of the last Registry version that the computer started successfully with.

You also find that there's a new file called swindle.dll in \WINDOWS\SYSTEM and you also note that the size and date of commctrl.dll have changed. This is where you need to check out some details. You right-click on each of these files in \WINDOWS\SYSTEM and select Properties, and look for a tab marked Version on the dialogue box. The first file is no problem – not only is the name obviously related to FlimFlam, but the maker is shown as Con's Games Inc, the makers of FlimFlam. Okay, just make a note of it, because many uninstallers ignore DLLs in \SYSTEM and this is one you'll certainly want to get rid of when you uninstall FlimFlam. Commctrl.dll is a different story -- its owner is shown as Microsoft and it's labelled as part of Windows. This is serious; whatever the change is, it may interfere with the workings of some of your other software and even Windows itself – most especially because you find that the "new" file is almost a year older than the current one.

When this happens, you can play it two ways: either leave the newly installed file in place and test all your software, or put the newer file back and see if FlimFlam will run. Option 2 is a lot simpler! First, copy commctrl.dll from \WINDOWS\SYSTEM to the home folder of FlimFlam, then drag commctrl.dll from \CLEANWIN\SYSTEM to \WINDOWS\SYSTEM and let go – and aren't you glad you had that backup . . . With some system files, Windows refuses to let you do this; in those cases, you need to reboot into command line mode and execute the DOS command "COPY C:\CLEANWIN\SYSTEM\COMMCTRL.DLL C:\WINDOWS\SYSTEM\COMMCTRL.DLL" and be jolly careful that you spell everything right.

If you're wondering why I told you to copy the older commctrl.dll to the FlimFlam home folder, it's because the program should look for its DLLs in that folder before going to \WINDOWS\SYSTEM. If it doesn't, and FlimFlam won't run with the newer library, the best option is to uninstall FlimFlam and forget about it; life's too short to tinker with special system files every time you want to run a given program.

Don't think this example is far-fetched, by the way; very often when you install a new program and some of your old ones misbehave, this is exactly the sort of thing that has happened. One famous example is CleanSweep 3.0, which tampered with two system files that Internet Explorer 4.0 needs. As I mentioned last month, this has been fixed as of CleanSweep 3.01, and presumably Quarterdeck has learned its lesson.

 

Who goes there?
It's not always that overwritten files in \WINDOWS\SYSTEM are clearly and easily identifiable as Windows system files. More often, they are run-time files for various programming languages, such as Visual Basic and Visual C++, or simply unidentifiable (how easy life would be if programmers labelled and commented their files properly!). In such cases, it's usually okay to leave newer files in place; in theory, any upgrades should be backward compatible.

Your Before & After result file may also show changes to config.sys and autoexec.bat. There shouldn't be any such changes, but you never know – the FlimFlam programmer may be a hopeless stick-in-the-mud. I left those tests in from the original batch files, just in case.

And what about the Registry? In theory, it's possible to export the Registry as a text file before and after and compare those files in the same way. However, the experiments I have done in that direction indicate that it would be a tricky and error-prone procedure, and the Registry is one thing you double-don't want to foul up. It's safest to leave that to your uninstallation program – except that you can go through the Registry with Regedit after uninstalling a program and search for leftover references to that program. While testing the various uninstallers, I found that they will remove most lines added at installation and most dangling references – but there can be orphaned lines they miss, and those need to be taken out by hand.

Say you have uninstalled FlimFlam; after checking that everything that should be removed according to Before & After has been removed, you start Regedit and do a search for FlimFlam, removing every key you find that contains that word – except the one that contains the Run buffer and the one that has the Recent documents buffer; Registry likes to remove those itself when they are replaced by others. If you have no other programs from Con's Games, you can also do a "search and destroy" on that phrase.

What about simply restoring the Registry from the backup? This seems a reasonable thing to do after uninstalling a program immediately after it's been installed, before something else can change in the Registry. I've tried that, copying all four files (system.dat, system.da0, user.dat and user.da0). However, while this worked three times, my system became unusable after the fourth time, and I have to advise against trying it.

 

For Windows 3.1 users:
T
he files AFTER.BAT and BEFORE.BAT are in the \utils\uninstall\win31\ directory on the CD. Use File Manager to just copy these files to your hard drive and follow the instruction laid out here .

 

For Windows 95 users:
You can install InWatch for Win95 now from this CD.

toppage.gif (1757 bytes)copyrite.gif (1355 bytes)