Windows Vista
In general updates and applications designed for Windows XP are highly compatible with Windows Vista and 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.
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 contains 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 on its features for elevation.
While application manifests are not new to Windows Vista, 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. All UAC compliant applications should have the requested execution level added to its application manifest. Applications that are not run elevated or are not detected by Windows Vista'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.
In an attempt to provide compatibility for applications that are not UAC compliant, Windows Vista and later contains 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 (TrueUpdate updates are always 32-bit).
Several new features have been added to aid in the updating process on Windows Vista or later. Additional features will be added in future service releases.
Client update application manifests containing configurable requested execution level settings. The Requested User Privilege Level setting can be found in on the "Advanced" tab of Project > Settings.
Support added to the System.GetOSName and System.GetOSVersionInfo actions.
Support (and additional table item) added to the System.GetUserInfo action regarding administrator detection.
New action System.GetOSProductInfo that can be used to get the product type of Windows Vista/Windows 7/Windows 8/Windows 8.1/Windows 10/Server 2008/Server 2008 R2/Server 2012/Server 2012 R2/Windows Server 2016 operating systems.
New return code for the File.Run action pertaining to elevation being required.
Addition of a "WaitForReturn" parameter and return code support for the Shell.Execute action.
Integrated Authenticode Code Signing to allow you to code sign your client update executable with your certificate. You can find these settings on the Code Signing tab of the "Build Settings" dialog (Publish > Settings).
The Requested User Privilege Level setting specifies which requested execution level to include in the client update executable's application manifest for distribution on Windows Vista or later. When the client executable is run, the operating system reads this information to identify what privileges it requires. The default setting in TrueUpdate is "Require administrator" and should generally never be changed. You should also avoid changing the manifest setting during an update expecting it to be automatically updated. Updating an As invoker manifested client to Require administrator will fail. If for some reason you do not want to require administrator privileges to run the update given its content, you should be aware of the following information and required changes:
Using the "As invoker" setting means that your update 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 the update as a standard user.
Important information requiring attention:
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 update 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.
When User Account Control (UAC) has been disabled on the system, the permission rules for running programs are the same as they are on other NT based operating systems such as Windows XP. Both the File.Run and Shell.Execute actions will succeed, however the target application will be subject to the privileges of the current user. Again, you should always perform any required Administrator detection using the System.GetUserInfo action and respond appropriately.
Certain locations are only accessible to users with administrative privileges such as: C:\Windows, C:\Windows\System32, Program Files and any files that are part of the Windows Resource Protection (WRP). Windows Vista and later also prevents files from being written to the root of the C:. When UAC is On, both standard user accounts and users that are members of the Administrators group will fail. When UAC is Off, only members of the Administrators group will succeed. This affects actions such as File.Copy, File.Install, System.RegisterActiveX etc.
By default, the update log file is created in the Windows folder. This folder generally cannot be accessed by a user (all users initially) assigned the standard user access token. Therefore this path must be changed to a per-user writable location such as the user's Documents folder, or Application Data.
Generally standard users only contain write access to locations under HKEY_CURRENT_USER. When UAC is On, both standard user accounts and users that are members of the Administrators group will fail if you try to write to another location. When UAC is Off, only members of the Administrators group will succeed.
Project wizard generated scripts generally use the File.Run action because they make use of the WaitForReturn parameter. If your project has been generated through the project wizard and you want to change the manifest to As invoker, you must change all File.Run actions to Shell.Execute actions so that Windows Vista or later can handle any elevation that may be required. Using the File.Run action to execute a file that requires elevation will fail.
TrueUpdate has the ability to update both the client executable and the client data file if newer ones are available. On the Advanced tab of Project > Settings you are able to select how you want to handle changes to these files. If you always want these files to be updated and want your update executable manifested with As invoker, you must ensure that the client files exist in a location accessible by all users such as the common application data directory (%ApplicationDataFolderCommon%). If your existing client executable is manifested with As invoker and you try to update your client executable with a Require administrator manifest using the automatic update feature, the update will fail. In this case, you must either keep your current manifest settings, or distribute a new copy of the client executable with the new manifest. Generally it is best to never change the client executable's manifest once it has been distributed the first time.
Using the "Highest available" setting means that your update is designed to be run by all users. The update runs with the same access token as the parent process. This means that if the update is run by a member of the Administrators group, their privileges will be elevated to the Administrator's full access token when given their consent. However, this also means that if a standard user ran the update, they would only have their highest privileges, those being a standard user. Therefore all issues mentioned above for "As invoker" would exist using this setting resulting in possible application failure. Again, if your update performs administrator tasks, the "Require administrator" option should be used in addition to the usual administrator detection and conditions.
Updates are now properly manifested using the Requested User Privilege Level setting. Updates created using a previous release may encounter some compatibility problems. However, Windows Vista and later contains a new "Installer Detection" feature that automatically detects unmanifested TrueUpdate updates as an "installer type." This will automatically prompt the user for elevation or logon credentials.
Note: While the Windows Vista or later "Detect application installation and prompt for elevation" setting is enabled by default, it can be turned off. If this setting was disabled, the update would be subject to file, folder and registry virtualization when writing to protected areas that may cause application failure. While this feature was designed to increase application compatibility, the possibility for error does exist. If you wish for your updates to be Windows Vista or later compliant, we strongly recommend publishing the update again using in the current version of TrueUpdate.
The goal of Authenticode signing is to ensure both the integrity and authenticity of the program. If you plan to distribute on Windows Vista or later, another point of consideration beyond user experience, is the fact that Windows Vista and later has the ability to prevent any unsigned application from launching with full privileges. This may impact both the update and application functionality. It is recommended that all application and update files be signed when distributed on Windows Vista or later.
TrueUpdate contains an integrated code signing procedure that allows you to code sign your client update executable with your certificate. You can find these settings on the Code Signing tab of the "Build Settings" dialog (Publish > Settings).
Note: For more information, see Authenticode Code Signing.