Challenge of the Installer

The installer has enough challenges.


The desire to add features that are better served with administrative forms in the program or post install configuration steps is greatest at the beginning of a projects life. This is because everything is relatively simple at this point including the installer.

The installer program's function starts out simple enough. It needs to copy a few files. And even though the uninstall is a separate function everyone considers it part of the installer. So the installer will also need to uninstall the applications as well. But this is also fairly easy.

The challenges start when moving past this base install. Immediately one needs to consider installing on multiple operating systems. By this I do not mean only multiplatform, Linux, Unix, windows, mac and mobile. But within a platform like windows there are multiple OS options. To point out the worst offender, Vista versions have proliferated. There are more than 6 Vista options. Which does not take into account the Windows Server is a separate line and Windows XP is still another option. The Mac platform is not as bad but it still has multiple versions with compatibility challenges. And arguably Unix lost it's grip on IT precisely because of all of the 'flavors' of Unix. Linux was seen as unifying these flavors but that had it's own challenges.

Beyond the OS difference there are multiple platform challenges. Internet browser lead the list of problems. Internet Explorers market share continues to erode with Firefox taking up most but not all the gain. On the one hand a duopoly may not seem bad, but these are two very different browsers. Another emerging platform feature challenge is the media players involved. And in our future the cpu will matter much more than it does know. We should be worrying about 64 vs 32 bit but modern IDEs do a good job of hiding this difficulty from us. This is not the end of the story, it will pop up later. The multicore future may add some complexity as well.

So far we are still pretty good. Perhaps it is not until we need to save state that things get difficult. There are always some configuration options that need to be persisted and this probably would not be much of a challenge until considering the upgrade path. Initially, the installer just installed and uninstalled. But with an upgrade you want some items like configuration or licensing to survive the install.

Frameworks like Java and Dot Net have radically simplified the development process but the install pays a small fee for that ease. Either the installer has to install the framework, make the framework available for install or check for the existence of the framework.

A similar story holds for third party and for lack of a better term second party applications. Databases are common third party application. Second party applications are other applications that your company or strategic partners want to distribute with your application. On the surface it might seem that these should be the easiest of all since you have some influence on these applications. The reality is that whatever you gain from this closeness you lose do to these application changing more rapidly and they are almost always more buggy than long standing third party apps.

I will leave it there. There is more but this should be enough to scare you into working on the installer first and always keeping the installer up to date.