


|

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:
The 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. You will need to
use My Computer or Win95 Explorer, and browse to the utils\uninstal\win95 folder
and run the setup.exe file |
|