Vista considerations

From ISXKB

(Difference between revisions)
Jump to: navigation, search
m (Best Practices: Added {commonappdata})
(External links: Link added.)
Line 57: Line 57:
== External links ==
== External links ==
 +
*[http://www.microsoft.com/technet/technetmag/issues/2007/06/ACL/default.aspx New ACLs Improve Security in Windows Vista] on Microsoft TechNet
*[http://www.microsoft.com/technet/technetmag/issues/2007/06/ACL/default.aspx New ACLs Improve Security in Windows Vista] on Microsoft TechNet
*[http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/ Teach Your Apps to Play Nicely With Windows Vista User Account Control] from Microsoft MSDN Magazine
*[http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/ Teach Your Apps to Play Nicely With Windows Vista User Account Control] from Microsoft MSDN Magazine
*[http://technet.microsoft.com/en-us/library/bb456992.aspx Applying the Principle of Least Privilege User Acccounts on Windows XP]
*[http://technet.microsoft.com/en-us/library/bb456992.aspx Applying the Principle of Least Privilege User Acccounts on Windows XP]
*[http://www.microsoft.com/technet/technetmag/issues/2006/08/LUABugs Problems of Privilege: Find and Fix LUA Bugs] on Microsoft Technet
*[http://www.microsoft.com/technet/technetmag/issues/2006/08/LUABugs Problems of Privilege: Find and Fix LUA Bugs] on Microsoft Technet
 +
*[http://msdn.microsoft.com/en-us/library/bb530410.aspx Windows Vista Application Development Requirements] for User Account Control Compatibility
[[Category:Windows Vista]]
[[Category:Windows Vista]]

Revision as of 13:32, 2 March 2009

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.

Contents

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
    • Not currently supported by Inno Setup.

Note that this means that administrative installs should not install Quick Launch icons, as they are per-user.

Inno's Installation Scenarios

  • User is an administrator
    • PrivilegesRequired has no effect
      • Inno will always present a UAC prompt
      • You should install per-machine (Administrative install)
      • You can do some per-user setup without screwing things up, but it's still not recommended
  • User is a standard user
    • PrivilegesRequired=admin
      • Inno will present a UAC prompt to elevate to an administrative account
      • 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 is not the user who is planning to use the software); see below for more discussion
    • PrivilegesRequired=none
      • Inno will not present a UAC prompt and will continue to run as the original user
      • 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)
      • You can offer to run the app at the end of the install.

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. 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=none) installation. 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.)

See also

External links

Personal tools
Ads: