Page 1
Page 2
Page 3
The role of the Registry
Suppose, for a moment, that in addition to
the eVB program just uninstalled, there are other eVB programs
on the machine, naturally also with .vb file extensions. Once
the registry entries are removed, WinCE has absolutely no idea
what to do with any .vb file, so it puts up an obscure error message
and forgets that it ever happened. What's particularly annoying
about this is that all the needed runtime files are actually still
on the machine. They are sitting in ROM, but WinCE doesn't know
what they're for because the registry entries were tossed during
ActiveSync's uninstall frenzy.
It is actually even a bit messier than that.
Many eVB applications use controls such as the TreeView. These
controls reside in their own DLLs, which are also specified when
setting up the Application Install Wizard. They are loaded and
registered during installation along with the runtime files. If
you've been paying attention, it's obvious to you that on uninstall,
they are also removed and the registry entries tossed.
But wait! If another eVB program on the machine
now needs this control, it can't have it. Not only are the registry
entries gone, but since these DLLs aren't in ROM, they don't exist
anywhere on the machine at all. This process generates an even
more obscure error message, including a hex GUID for the user's
amusement, and the eVB program is terminated with extreme prejudice.
Undocumented feature
You might be thinking at this point that no
company with over a decade's experience in such matters would
ever design such a system. It is too obviously broken. In fact
you'd be right in such a conjecture. WinCE and ActiveSync are
designed, at least partially, to avoid all this by allowing a
usage count on the DLLs and only deleting them when the usage
count goes to zero. There are two flies in this ointment, however.
Fly number one is that there is a bug, not a fly, in the Application
Install Wizard that creates incorrect installation files, so the
DLL usage counting doesn't get set up. Fly number two, probably
a bug, is that the usage count doesn't apply to the registry entries.
If the DLL counting were used, they still wouldn't be available
because the registry entries are removed during uninstall irrespective
of any stinking DLL usage counts. The DLL files would still be
there taking up memory, but WinCE wouldn't know what they were
for, or what the applications crying for their controls were talking
about. It would emit the usual obscure error message, swat the
eVB application, and wash its hands of the matter.
VBRegFix
This is where VBRegFix comes in. The way ActiveSync
does its uninstall magic (or whatever you wish to call it), is
by creating UNLOAD files during installations. These files have
information about what files were loaded and what registry entries
were created. Every installed application has such an UNLOAD file
and it is read during uninstall to enable all this havoc to be
wrought.
VBRegFix first finds all the eVB DLLs and
makes sure they are registered. Then it reads and parses all the
UNLOAD files and creates copies of them with a different file
type that only it knows about. Next it emasculates the UNLOAD
files by surgically removing all references to the eVB shared
DLLs and their registrations and writes the now falsetto files
back.
Now when ActiveSync does an uninstall, it
knows nothing about these DLLs having been loaded, so it doesn't
remove or un-register them, but it does remove all the other files,
such as the application itself and the UNLOAD file. The important
thing though is that nothing that would affect any other eVB application
is zapped. No doo doo.
The next time VBRegFix runs, it inventories
all the UNLOAD files and all of its secret copies. If it finds
that it has a copy file, but there is no longer a corresponding
UNLOAD file, it knows that the application was removed, so it
isn't using its DLLs any longer and the copy file can be deleted.
By counting the number of applications using each DLL in all the
copy files, VBRegFix can decide when a given DLL is no longer
needed. It then builds a list of such orphaned DLLs that can be
un-registered and deleted to save space if the user so wishes.
The challenge
The biggest challenge in writing VBRegFix,
beyond figuring out the above tangle, was to get it to run automatically
so it could protect the DLLs without making a nuisance of itself.
Requiring users to manually run it whenever they installed and
uninstalled programs seemed pretty icky. The final compromise
was to set it up to automatically run whenever the PocketPC is
connected to the desktop. This isn't really air tight because
if the machine is connected, and an application is installed then
uninstalled before the next connect, it will clobber everything
it can lay its hands on since VBRegFix never had a chance to fix
the UNLOAD files. Users should be sure VBRegFix has run before
doing any uninstalls to let it protect their DLLs. I couldn't
figure out any way to do this automatically.
Previous Page
Next Page