Running o n Windows Vista o r L a t e r
Windows Vista
Overview
In general, applications designed for Windows XP are highly compatible with Windows Vista or later given its file, folder and registry virtualization features. Many of Windows XP's existing features have been enhanced and new features added. While there is a high compatibility, new features and the tightening of security require developers to be aware of certain changes that affect both application development and distribution.
Important Vista or Later Features
U s er Acc oun t C on t r ol ( UAC )
By default, in Windows XP all user accounts were created as local administrators. This meant that many users ran as administrators with full access privileges leaving the security of the system open to attacks. A design goal of the UAC was to prevent applications from being executed without the user's knowledge. While user accounts and restricted tokens have been around in previous versions of Windows, Windows Vista and later contain security protection for the administrator account as well. When an administrator logs in, two different tokens are created. The first token grants all the permissions and privileges of the administrator, while the second token is a restricted token (filtered token), offering virtually the same privileges of a standard user. With UAC (User Account Control) enabled, members of the administrators group run with the same access token as standard users. Only when the user gives approval will the program be granted the full access token.
Note: Features of UAC can be enabled and disabled, so developers should not rely solely on its features for elevation.
A ppli ca t ion M a ni f e s t s
While application manifests are not new to Windows Vista or later, a new section has been added for the UAC to mark applications with a requested execution level. This information notifies the operating system of the privileges that the application requires so it can perform any necessary elevation via consent, or login credentials. All UAC compliant applications should have the requested execution level added to its application manifest. Applications without this manifest information, that are not run elevated or are not detected by Windows Vista or later's installer detection, may be run with file and registry virtualization (see next section). In future releases of Windows, the only way to run an application elevated will to have a signed manifest identifying the required privilege level.
Fil e / Re gi s t ry V i r t u a li z a t ion
In an attempt to provide compatibility for applications that are not UAC compliant (missing requested execution level attribute), Windows Vista or later OSs contain a new virtualization technology for files, folders and the registry. When a non-UAC compliant application tries to write to a protected directory
such as Program Files, or a global portion of the registry such as HKEY_LOCAL_MACHINE\Software, the application is provided with a virtualized copy that is stored under the user's profile. Developers are not to rely on this technology being present in the future.
Virtualization (file/registry) is turned OFF for any applications:
· Containing an application manifest with an appropriate requested execution level.
· Detected by Windows Vista or later as installation programs resulting in a prompt for elevation/approval.
· That are run elevated.
· 64-bit processes (AutoPlay Media Studio applications are always 32-bit).
AutoPlay Media Studio Vista/Windows 7 Runtime Features
Several features have been added to aid in running AutoPlay applications on Windows Vista or later. Additional features will be added in future service releases.
· AutoPlay application manifests containing configurable requested execution level settings. The
Requested User Privilege Level setting can be found in Project > Settings, Advanced tab.
· Support added to the System.GetOSName and System.GetOSVersionInfo actions.
· New return code for the File.Run action pertaining to elevation being required.
· Support (and additional table item) added to the System.GetUserInfo action regarding administrator detection.
· Integrated Authenticode Code Signing to allow you to code sign your AutoPlay applications with your certificate. You can find these settings on the Code Signing tab of the "Project Settings" dialog (Project > Settings).
Choosing the appropriate "Requested User Privilege Level" Setting
The Requested User Privilege Level setting specifies which requested execution level to include in the AutoPlay application's manifest for running on Windows Vista or later. When the application is run, the operating system reads this information to identify what privileges the application requires. You can find this setting by choosing Project > Settings and selecting the Advanced tab.
Important Note: The "Requested User Privilege Level" setting is only effective if the user has UAC enabled. Each user's UAC settings can also be configured differently, so you should not rely solely on this feature. When performing administrative tasks, you should always include administrator checks using the System.GetUserInfo action's "IsAdmin" and "IsVistaAdminLimitedToken" table return values. Windows Vista or later operating system detection can also be achieved using the System.GetOSName and System.GetOSVersionInfo actions.
The default setting in AutoPlay Media Studio is "As invoker" and is suitable for generic presentations or menus, where you are certain you do not need access to protected areas of the operating system (file system/registry). This includes access directly by the AutoPlay application, and the launching of external programs that require these permissions (unless they are designed to handle their own permission detection and notification). However, some AutoPlay applications may require access beyond the privileges of a standard user. For these cases, you should be aware of the following information and required changes:
U s ing " A s in v o ker "
Using the "As invoker" setting means that your application does not require any system access other than the current user's profile areas. Many of these issues exist for previous versions of Windows when running applications as a standard user.
Important information requiring attention:
Running Programs
User Account Control (UAC) On
Problem: File.Run actions will fail for both standard users and Administrator users if Windows Vista or later identifies the target file as requiring elevation. This will happen for files containing marked application manifests requiring elevation, or detected by Windows Vista's installer detection.
Solutions: If the target file contains a proper manifest, and contains its own Administrator detection and notification, or is an install/patch/update that Vista or later will detect with its installer detection feature, use the Shell.Execute action instead. This will allow Vista or later to prompt for approval or login credentials. The second solution is to mark your AutoPlay application as "Require administrator". In addition, you should always perform any required Administrator detection using the System.GetUserInfo action. This will enable you to determine if the user is an administrator running with full privileges, or if they are part of the administrators group, but running with limited privileges.