Installers & Uninstallers

Week of June 19, 2002

You know the drill. You've just downloaded some honky-tonk, the installer is running, you pause briefly at the END USER LICENSE AGREEMENT and then decide to not call in your legal team to interpret it, click the 'I Agree' button, and then suddenly it's the Fourth of July, with file names speeding by. You catch a glimpse of a 'WINDOWS' or a 'WINNT' or a 'SYSTEM' or a 'system32' in there, but what can you do?

Your desktop lights up. You get one two three four or more new icons on its already cluttered surface. Your Start menu is a total mess with new entries like 'Read END USER LICENSE AGREEMENT' and with one called 'UNINSTALL HONKY TONK'. Several days (or hours minutes nanoseconds) later you're tired of this weary app, you proceed to uninstall it, it's gone - or at least most of it is - you maybe spend some time ferreting out junk that's still left behind - and then maybe just maybe your system is running ok again.

Or maybe it is not. What has happened and why is all this nonsense necessary? Look at the Radsoft stuff, or at Robin Keir's software. Are there any install programs there? Robin's software packages come in ZIP form with a simple 'readme' text file and the program file, and that's it. Radsoft's come with a fancy 'unzipper', but there's no install in the modern sense of the word. How do Radsoft and Robin get away with it, how come the others don't?

There are ways to protect one's computer today. Neil Rubenking's Install Control is capable of tracking and, with Radsoft's InCtrl Importer, neutralising install damage. But why is all this necessary? Why do some programs need all this junk in the Registry while others do not?

The concept of doing work like this was one of the last contributions of the Multics project. Multics was shortly replaced by Unix, which went about things in a totally different fashion. Multics liked class IDs (CLSID) and stuff like that; Unix liked small efficient relatively bug-free tools that worked well together, in a pipeline or other such construct. And all was well until the emergence of Microsoft. Microsoft turned the clock back, revived the superseded Multics way of thinking, and brought us to where we are today. And the sheep followed after and soon everybody's software was built like this.

CLSIDs and Interfaces are references to modules installed on your system. The idea is that they should broadcast their presence and what they are capable of helping with. A program will query the 'database' when starting up, see if there are any cool modules out there that it can use, and then connect with them. It sounds like an innocent idea - so what went wrong?

All too many developers call themselves developers only because they get software out the door. They're incapable of producing anything of substance. They can only work with OPC - other people's code. And there seems to be no shame. Some developers will package and install an 80KB module just because they want to place centred text somewhere in your window, when all you really have to do is create a static control in your code and give it the SS_CENTER attribute. These so-called developers suffer from not having a clue what possibilities are built into the so-called API, and they thrive on knowing what bulkware is out there that will do the job sloppily and wastefully instead.

And unfortunately there is but one 'childishly simple' way of hooking all these modules together - one that centres text, another that outputs red text, another that makes a grid, and so on. And that way is with the class IDs and interfaces. It's not very efficient, it's software constructed by the 'almost clueless', it's going to be very bulky and very slow and very very leaky - and when the nightmare is over and you want to junk it and go home, it's not going to do such a good job of cleaning up.

The amount of junk that accumulates in a typical end-user system is staggering. End-users know even less than the programmers whose software they so often use. End-users don't know what the Registry is, even though they have heard of it. They're not familiar with bloat and its causes. They have no clue why Delphi and Visual Basic are so horrendous. They see a cool interface and they know they want the program. And invariably they think that the larger the download, the more they are getting - when it's almost always the other way around.

Delphi and Visual Basic programmers are closer to being end-users than they are to being programmers. Programmers have a known difficulty understanding how end-users think; end-users know exactly how end-users think. Programmers assume people understand things, because they seem so obvious. End-users know end-users rarely understand anything at all, because nothing is obvious. Delphi and Visual Basic programs can often look better to the uninitiated because the user interfaces are better thought out and more appealing. They catch the eye of end-users, the end-users download the stuff, and then half a year after that they do things like taking their computer back to the shop where they bought it and paying fifty bucks to have the drive reformatted. It's something like a colonic - you're supposed to feel so much better afterwards. Where a proper diet would have kept you from ever needing that swami.

The argument in favour of the Multics approach says that it saves development time by implementing reuse. But the Unix approach is the ultimate in reuse and always has been. The Unix approach says you never or almost never need new tools, because what you already have can be combined in almost any way to do almost anything at all.

The Multics approach has produced sluggish end-user machines. The Unix approach is slim, fast, and relatively bug-free. You choose.