


|

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.
|
|