Why Installers Don’t Do Per-User Setup

From an end users’s point of view, an installer is all about getting an application from a source (a DVD, or maybe a downloaded file) to the point where it’s ready to run on their machine. Why, then, do so many applications have more to do the first time a user runs them? Why doesn’t the installer just get all of that stuff out of the way up front?

To understand why, you first need to know a bit about how file ownership and permissions are organized on those machines. Along the ownership/permission access, you can generally divide files into three categories:

  1. Owned by the administrator and read-only to users. This category contains the applications themselves.
  2. Owned by a user and writable only by that user. These are all of your files.
  3. Writable by all users. These are “shared” files; this category isn’t much used in practice.

Items in the first category are written by the installer; after that, they’re not touched except for updates. Things like user preferences are all stored in the second category.

The second category contains one set of files for each user. For example, each user has his own set of preferences, accessible only for that user account.

Now, let’s imagine that an installer wants to both install the application (of course) and set up the initial user preferences. Clearly the application is written to files in the first category. The preferences file has to go in the second category. But for which user should those initial preferences be written? Writing them for the user running the installer might make sense and might work. But writing for the other user accounts doesn’t work. There are a variety of reasons for this, but on particularly interesting one occurs when using roaming profiles on Windows. In this case, additional user accounts may not even be accessible from the machine while the installer is running, even though later they will be!

Even if the preferences were written for one user, then, they can’t be written for other users who might use the same application on the same machine. Preferences for that user will have to be set up when that user first runs the application. Fortunately this is simple to implement; when the user runs the application, their files are definitely available.

Once you’ve got the logic written to take care of per-user setup at first launch, there’s no longer any need to special-case that first user at install time. And that’s why installers don’t do per-user setup: the application has to do it anyway.