Vista considerations


Revision as of 06:43, 23 November 2011 by Uecasm (Talk | contribs)
Jump to: navigation, search

Windows Vista now includes a far stricter LUA system (LUA = Least-Privilege User Account; not to be confused with the programming language Lua).

This pretty much stops all applications making system wide changes without asking the user. (Note that the rules are still the same as they've always been -- but Vista enforces them more strongly.)

The recommended minimum version of Inno to use for Vista-capable installs is 5.2.0. For standard-user-only installs, you must use Inno v5.3.7 or later.


Types of Installer

Windows standards recommend two different "classes" of installer:

  • Administrative
    • Runs with admin permissions
    • Is expected to make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
    • Should not make changes to per-user areas such as HKCU and the current user's profile
    • Fully supported by Inno Setup (all versions, although 5.2.0 and above is best under Vista)
  • Standard user
    • Runs with standard user permissions
    • Is expected to make changes to per-user areas such as HKCU and the current user's profile
    • Must not make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
    • Supported by Inno Setup from v5.3.7; limited support on older versions.

Note that this means that administrative installs should not install Quick Launch icons, as they are per-user. (And of course they have also been deprecated by Microsoft.)

Inno's Installation Scenarios

User Type
Administrator Standard User
PrivilegesRequired=admin Admin Install (Elevation) Admin Install (Elevation)
PrivilegesRequired=none Admin Install (Elevation) User Install (No Elevation)
PrivilegesRequired=lowest User Install (No Elevation) User Install (No Elevation)

Admin Installs

User Type
Administrator Standard User Standard User using "Run as administrator"
Windows XP or below Runs Normally Error Message, Exit (prompt for credentials)
Windows Vista or above, UAC disabled Runs Normally Error Message, Exit (prompt for credentials)
Windows Vista or above, UAC enabled UAC prompt for confirmation UAC prompt for credentials (UAC prompt for credentials)

Note that using "Run as administrator" is not recommended (and should be unnecessary on Vista with UAC anyway), as that will mean that the admin user is both the "current" and "original" user, which may produce surprising results for the user depending on what your script does. (For example, it will mean that if you have an option to run your app at the end of the installation, it will run as the elevated admin user.)

Also note that Inno handles the UAC elevation internally; as such its manifest says "asInvoker" and it will not display the "admin shield". This is not a bug.

  • You must install per-machine (Administrative install).
  • You must not do any per-user setup within the install proper (since the user that the setup is running as may not be the user who is planning to use the software); see below for more discussion.

User Installs

  • Inno will not present a UAC prompt and will continue running without elevation.
  • You must install per-user (Standard user install)
  • You cannot install any per-machine data (which also means that you cannot use restartreplace or regserver)

Per-User Actions

With the advent of Inno 5.2.0, the "runasoriginaluser" flag and "ExecAsOriginalUser" support function can be used to carry out tasks in the context of the original user running the installer (provided that the user did not use "run as administrator"). This permits carrying out a limited amount of per-user setup on initial install, and also allows you to offer to run the application at the end of the install without having it end up running as the wrong user.

Despite this, it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed. This is because only one user is running the installer, but more than one may be running the application. If your only upgrade code is in the installer, other users will be left out in the cold.

Choosing an Installation Type

By far the majority of applications should perform an Administrative (PrivilegesRequired=admin) installation. This requires the least amount of work from both setup writer and end user -- the app is installed once to a shared location (without touching per-user data at all), and then subsequently any number of users can run the application and create their own sets of per-user data. The application itself of course should be set to not require admin permissions.

In some cases you may want to create a Standard (PrivilegesRequired=lowest) installation. These are potentially wasteful, as they require each individual user who wants to use the program to run the installer, leading to duplication of files on systems with many users. Additionally, these limit the types of components that can be used (since some require per-machine installation), and as yet there is no officially sanctioned location where per-user applications should be installed. But they do permit individual users to each have their own (potentially different versioned) copies of an application; depending on who you ask, this may be a good thing or a bad thing.

If using an older version of Inno that lacks PrivilegesRequired=lowest, the other alternative is to use PrivilegesRequired=none. This is more work, since you'll have to add [Code] and Check functions to detect whether the install is being run by an administrator or not -- since Inno still requires a per-machine install if an administrator runs your PrivilegesRequired=none installation. In the end you're going to write a lot more code (and consequently be more fragile) for limited benefit, as this mode is only useful if the software is never installed by any administrators. (If even one admin installs it on a machine, then you might as well have done an Administrative install in the first place.)

Best Practices

These are too long to discuss in any great detail here; the best idea is to look at the info available in MSDN. However one point that bears mentioning (because it seems to be a common mistake) is where data should be stored.

Almost all applications (whether under Vista or an earlier version) should have per-user data, especially for configuration options and the like. Any time an app is shared by multiple users (which is becoming more and more common), each user will have their own preferences and won't want changes made by any other user to mess them up. These preferences should normally be stored in {userappdata}\Your Company\Your Application or in HKCU\Software\Your Company\Your Application, which is user-specific.

Note however that the installer should not be responsible for creating these (as discussed above) -- the application should do it itself from sensible defaults. This is because the install process will only be run for one user, and if any other users run the application the data will not be present anyway. (If the initial data is too complicated to reproduce automatically, then you can store a template copy in {commonappdata} or {app} and copy it to the user profile when your app starts up, if not already present.)

Common Mistakes

  • Trying to install per-user data in an admin installer (see above).
  • Not marking your application with a Vista compatibility manifest.
  • Specifying anything other than "asInvoker" in your manifest -- the vast majority of applications should not require admin permissions at all, and of the few exceptions, most should only require admin permissions for small parts of their functionality and should elevate on demand (see MSDN).
  • Choosing different installation paths for "Vista" vs. "Before Vista". The rules haven't changed, you've always been supposed to install in {pf} and keep user settings separate. It's just more obvious in Vista since more users are running programs as non-admins.

See also

External links

Personal tools