Dr. Dobb's | Installation Software: From the Inside Out

Installation Software: From the Inside Out

What's so hard about install -- and uninstall -- software?

November 27, 2008
URL:http://www.drdobbs.com/windows/installation-software-from-the-inside-ou/212200870

With us today is Ron van der Wal of Tarma Software Research, a software development company that specializes in installation software.

DDJ: Ron, what's the hard part of building installation tools?

RVDW: Creating the development environment. That's where 80-90 percent of the effort goes. You might think that keeping up with new Windows features and versions was the tricky bit, but it's not.

The GUI part of the development environment is the hardest: it accounts for most lines of code and it makes it harder to add new features, because not only must the new functionality be added to the installer executable (which is fine), but it also trickles back to the development environment: additional UI fields or options, additional code for data exchange and validation, additional code for preflight checks, additional space in (and I/O with) the project file, and more end-user documentation.

So the hard part of building installation tools has nothing to do with installation tools, but rather is the same thing as always: the incidental complexity (the GUI development environment) that overwhelms the essential complexity (the actual installer program).

DDJ: What about the flip side -- uninstall programs?

RVDW: The hardest part here is to remove what is no longer needed, and no more. For application-private files this is easy, because you just delete them. The trouble starts with files that are used by several applications or even Windows itself.

Windows uses several forms of reference counting, from SharedDlls to side-by-side and .Net assemblies, but none of them are fully reliable. We therefore use additional rules to try and avoid damaging the system.

The final twist is removing the installer itself and the folder it resides in: that requires a second process that runs from a different location, because you cannot remove files or folders that are still in use. It's a kind of inverse bootstrapping, if you know what I mean.

DDJ: I have to ask this because you can't have a conversation without it these days -- does cloud computing change anything when it comes to installing software?

RVDW: Well, it should do away with the need for installation programs, and good riddance as far as I'm concerned. I firmly believe that software installation on Windows systems is much, much too complex and too fraught with problems, despite all the best efforts to make it easier.

DDJ: About 10 years ago, you wrote an article for Dr. Dobb's on the subject of testing tools. How did you get from testing to installation software?

RVDW: Confession: I never really was a tester per se; it was just something that arose from my interest in well-engineered tools. First there was programming in C and C++, then the need to write better software with those languages.

In that context I evaluated a variety of testing tools (and C/C++ compilers in a separate article around the same time), primarily to see how they could help to write better software: fewer bugs, better optimized, and generally more reliable.

From there I went on to write bespoke software for a variety of customers and purposes, and needed an installer that was more compact and more efficient than the ones that were available at the time.

That led to my first installation tool, which was very simple but also very small: 50 KB or so instead of the then (ca. 1999) more customary 700 KB and more. It allowed me to fit most programs on a single floppy disk instead of several -- another case where the incidental overhead (the installer) used to overwhelm the essential (the product itself).

That first tool was followed by commercial versions that grew over time, but even the current version is less than 200 KB and has the same or better functionality and flexibility as for example the MSI runtime.

As always, the emphasis is on small, efficient, and well-engineered software, and to achieve that we even use our own runtime libraries, written from the ground up for compactness and speed. They completely replace the usual Microsoft C/C++ runtime libraries and frameworks like MFC, and used "safe" coding techniques long before those appeared in recent versions of the Microsoft libraries.