Howdy – I’m a software design engineer at Microsoft, in the Windows core technologies group. My work involves isolating applications, components, and the operating system from each other. I don’t have much original or interesting to say, but by gum – I’ll say it here. Like many of my generation, I grew up using computers. I won’t enumerate them all, but the list starts with an Atari 800 XL and hasn’ ended yet.
The unfortunate state of the world today is that once an installer exits (either for an operating system or a software package), the resulting state of the world is completely unknown and undefined. Sure, judicious use of regmon and filemon will let you guess at what those installers did, and maybe you’ll be able to uninstall. Compound this with the large set of installations required to get a running system, differing versions of shared components, and even more fun around points of extensibility, and you end up with a morass of crap – the only hope is to flatten and reinstall the system.
So what happens when we uninstall? Well, generally, the uninstaller has a list of objects that it installed, and some sort of reference tracking to know when stuff should go away. The installer decrements those references, and whacks the stuff that should be deleted. Too bad the installer for FoobleSoft’s Bongoblam III’s installer forgot to increment the reference on the shared component ponkfoo.dll – it hit zero, so the installer does away with it. Practical upshot? Next time you run Bongoblam III, it crashes during binding static imports. Well crap.
How do you help this? You could move to a single installer (MSI), so that only that installer knows how to do the right thing. You could move to a world where the system deeply understands the requirements between DLLs and EXEs (or images in general) and refuses to allow deletion of images if any references on them are alive. Both of thse, when done correctly, fix the problem of shared components accidentally disappearing out from under you. That’s a good step forward…
But, it’s not sufficient. That package you uninstalled – call it Barbaszot – and Bongoblam both wanted to be the .XYZ shell extension handler. The installer’s simple logic noticed that Barbaszot had written to HKCU\.xyz, so it deletes everything that was updated. Now when the shell wants to activate, it could find Bongoblam III, but it can’t! The .xyz handler metadata is gone, and the shell pops up a “what do you want to do with this file” dialog.
Smarter installers – like MSI – can help with this as well, by noticing the state of the world before values are written or updated in the registry. Maybe when you uninstall Barbaszot, it knows to just rewrite the old values, and suddenly Bongoblam III is now the handler again. That’s groovy. But wait – what if Bongoblam was installed after Barbaszot, but Barbaszot stole back the extension handler (this horrible practice started about five minutes after the first alternate handler for .whatever files was created…)? The installer in all its logic says “well there was no value before” and helpfully deletes the keys. Now Bongoblam III is out in the cold again.
What can we do about all this? My work involves doing completely self-described simple and nondestructive operations to a running system. In my world, when the shell was looking for an .xyz handler but after Barbaszot had been removed, it would look through a data-driven list of applications that had declared themselves to be .xyz handlers. Maybe it would have prompted the user, maybe it would have picked the last-used, maybe it would have picked the first random one. In any case, removal of Barbaszot would not have destroyed the list of possible choices
It would appear I’m rambling again. I’ll have more later – less ranting on how bad software is now, and more things I’ve discovered while working here.