What is going on during program installation?
Have you ever wondered what’s actually going on when you run a program installer? Installers try to accomplish some or all of the following:
Force you to accept a license and possibly throw in some advertisements too.
Check to see if the parts this program needs to use are present on your system.
See what system you are running, and select appropriate system-specific codes.
Test things out.
Distribute bits of the program on your system: some to be shared, some to run, and some to store preferences and the like.
Tell the operating system “I’m here and can open these kinds of files”.
Each of these deserve a little more explanation.
Programs are written by humans for humans, and human factors matter. That not-so-little End-User License Agreement (EULA) most people skip past is really quite significant. Most of them basically say “absolutely nothing that this program does or fails to do is in any way our fault.” Some of them also add in “and you have absolutely no rights whatever to any part of this software or anything it creates.” I’ve also seen clauses prohibiting use of the software as inspiration in other activities; banning commenting on the performance of or my satisfaction with the software; requiring works created using the software be sold only through one particular vendor; and allowing the software vendor to run arbitrary code and use your system resources without respect to propriety, security, or privacy. One famous case involved giving the vendor your immortal soul, but as it was intended as a joke I don’t give it much attention.
The issue of EULAs, with the associated ideas of the free-software movement, patent wars, and copyright law are too big to give proper attention here. Let it suffice for now to say I encourage you to read the licenses.
Your computer has a whole lot of things it already knows how to do. Draw windows, handle keyboard and mouse events, access networks, sort list of numbers, factor very large integers into their constituent primes, solve first-order homogeneous differential equations, compute the eigenvalues of large sparse matrices, play videos, check spelling, play an A♭…
Each program needs to use at least some of these already-there capabilities. So one of the it does during installation is check to see if the things it needs are present and how to access them on your computer.
Some, though not all, programs have specific solutions to problems that are tailored to particular hardware, operating systems, or other resources. This might take the form of an installer shipping with several possible programs and picking one that matches your system, or it might involve actually changing the program to reflect your system before it is installed.
Some installers run a sanity-check test before they install. This is easier than trying to test each resource individually: if the program works, the necessary resources must have been present. On the downside, if things don’t work the installer doesn’t really know why, so it isn’t that helpful…
At some point the program is actually placed inside your system where it can be used. This may involve several activities.
Many programs include elements that can be used by other programs. These are placed somewhere where other programs can find them.
Most software is shipped as a program, meaning there is a file you actually run and possibly a set of supporting files that one needs. These are copied to wherever your system stores executables.
Sometimes there is some kind of system-wide configuration file for a program. Typically this includes things like how to access the Internet and other behind-the-scenes kind of information. These are initialized by the installer or by the program itself the first time it is run.
Most programs include user-specific configuration files, even those that have no obviously-visible configuration settings. These store things like a list of files you’ve recently opened, or your chosen window layout and home page, or if you personally have agreed to the EULA yet, or your registration code, etc. These are usually initialized by the program itself the first time it is run, but where to place them is sometimes determined by the installer.
Once all the pieces are in place, installers often tell the operating system and windowing environment what they’ve done. They’ll register as programs that can open particular files, add themselves to menus and deskops, put themselves in lists of installed files with links to uninstallers, etc.
All of the above is rather messy. Uninstalling a program such that you can’t tell it was ever there means removing not just the program itself, but also shared components that no one else is using, system-wide and per-user configurations, and clearing out the registry of elements that exist. It’s common to find installers that miss some pieces and leave detrius behind.
The alternative is to make a stand-alone program, one that assumes without checking that a minimal set of resources are available and doesn’t add any configuration or registration anywhere. Many apple programs lean toward this model, giving a standalone .app that can simply be copied wherever it needs to be. Even apple’s .apps, though, create per-user configuation files and it is not uncommon to find scores of old, unused configurations lying around on a machine. Additionally, stand-alone programs don’t share, leading to various other problems with memory and maintainability. More on these issues will appear as this series continues.
Looking for comments…