Microsoft Corporation

July 2006
Revised October 2006

The Windows Vista Developer Story includes content for developers, and other technology experts and managers, interested in an in-depth exploration of some of the new and extended features in Windows Vista. It is released to the Windows Vista Developer Center in the form of Articles, published approximately one every two weeks. Those Articles are only a summary of the Windows Help file, which can be downloaded here.

Note   This topic is pre-release documentation and is subject to change in future releases.

Note   To provide feedback about the articles, please send email to Vistadev@microsoft.com.

Contents

Introduction
Thirty-Minute Compatibility Check
Operating System Versioning
User Account Control
User Account Control - Application Update Guidelines
Windows Resource Protection (WRP)
Internet Explorer Protected Mode
Windows Vista 64-bit
Microsoft Graphical Identification and Authentication (GINA)
Session 0 Isolation
Networking: TCP/IP Stack and the Windows Filtering Platform
Networking: Kernel Mode IP Helper APIs
Networking: IPv6
Networking: Turning Off the Windows Firewall
Compatibility Risks
Help and Support Center
Assistance Platform Client
Default Programs
Program Compatibility Assistant (PCA) in Windows Vista - Customer Ready Documentation
Graphical Device Interface (GDI)
Painting (WM_PAINT) Behavior Differences
Rendering Performance
UIPI (GUI Portion of User Account Control)
High DPI Scaling
PNG Icons
Named Pipe Hardening
SPAP Deprecation (Pstore)
WMI Providers: Default Security Hosting Model
Volume Shadow Copy Service
Standard User Analyzer
Help Engine Support
Junction Points and Backup Applications
Notes for Backup and Recovery
Search the Internet
See Also

Introduction

Microsoft Windows Vista introduces the next generation operating system technology and software development platform that will be used by application developers and enterprises worldwide. As part of enhancing the security and user experience of Windows Vista, many new features have been introduced and existing features have been improved.

While Windows Vista is highly compatible with most of the applications written for Microsoft Windows XP, Microsoft Windows Server 2003, and their service packs, some amount of compatibility breaks are inevitable due to new innovations, security tightening, and increased reliability. Overall, Windows Vista compatibility is high, and Microsoft is continuously striving to achieve the best possible compatibility solutions for existing applications for Windows Vista.

This document is the first step for application developers to become familiar with how to verify the compatibility of their applications. This document also provides an overview of the few known application incompatibility issues in Windows Vista and provides links to detailed white papers and other developer guidance.

There are several new features that will enable developers to troubleshoot and workaround applications that do not function properly under Windows Vista, such as the following:

• Compatibility tab.

  Users can right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode to allow the application to work as it did on Windows XP. Additionally, the user can choose Run this program as administrator if the application needs administrator privileges and the user possesses those rights. For more information, see the "User Account Control" section in this document.

Thirty-Minute Compatibility Check

This section provides guidance on how to test and evaluate the compatibility of an application on Windows Vista. There are two primary scenarios to test for compatibility on Windows Vista, as follows.

Working with a Clean Installation of Windows Vista

1. Install Windows Vista on a test machine.
2. Install the application on Windows Vista. If a prompt is displayed requesting permission to install the application, click Permit and continue. If installation succeeds, go to step 6.
3. If the application installation failed and no installation permission prompt was displayed, then right-click the installer EXE and choose Run this program as administrator and re-install the application. If the install succeeds, go to step 6.

   Note   This step is not necessary if an MSI is used to install.

4. If you receive any errors, such as OS version, CLSID registration, or file copy, then right-click the installer EXE file, choose the Compatibility tab, and choose the Windows XP SP2 compatibility mode.
5. Go back to step 2. If you cannot install the application, go to step 9.
6. The application should now be installed.
7. Launch the application. If the application did not launch properly or if errors are displayed, apply the Windows XP SP2 compatibility mode to the application EXE and try again.
8. If the application launches successfully, run through the full suite of tests that would typically be used to test the application on Windows XP. Verify your application functionality and confirm that the application performs properly. If all major functionality tests pass, go to step 10.
9. If the application does not install, launch successfully, crashes, encounters an error, or fails major functionality tests, it may be one of the small set of applications that are impacted by Windows Vista changes. Use the topics in this document to check your application.
10. You have completed the scenario.

Working with an Upgrade from Windows XP Service Pack 2

1. Install Windows XP SP2 on a test machine and then install the application. Verify all the functionality of the application before proceeding.
2. Upgrade the test machine to Windows Vista. Follow the Windows Vista setup and upgrade instructions. Once the upgrade is complete, log on as you would on Windows XP.
3. Launch the application. If the application did not launch properly or if errors are displayed, apply the Windows XP SP2 compatibility mode to the application EXE and try again.
4. If the application launches successfully, run through the full suite of tests that would typically be used to test the application on Windows XP. Verify your application functionality and confirm that the application performs properly. If all major functionality tests pass, go to step 6.
5. If the application does not install, launch successfully, crashes, encounters an error, or fails major functionality tests, it may be one of the small set of applications that are impacted by Windows Vista changes. Use the topics in this document to check your application.
6. You have completed the scenario.

If both scenarios have been completed and the application has performed properly, then the application functions correctly under Windows Vista. For information about obtaining certification for your application, see the Windows Vista Home Page.

Links

• Windows Internet Explorer 7: Beta 2 Preview IT Pro Checklist
• Windows Vista Home Page

Operating System Versioning

Feature Impact

High

Brief Description

The internal version number for Windows Vista is 6. The GetVersion function will now return this version number to applications when queried.

Note   This is the next major version number from Windows XP (version 5.x).

Manifestation

The manifestation of this version change is very application-specific, as follows:

• Any application that specifically checks for the OS version will get a higher version number.
• Application installers may prevent themselves from installing the application and applications may prevent themselves from starting.
• Applications may warn users and continue to function properly.
• Some applications may become unstable or crash.

Mitigation

Most applications will function properly on Windows Vista because the application compatibility in Windows Vista is very high. However, for applications and installers that check for OS version, a Compatibility mode is provided in Windows Vista.

Users can right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab. In most cases, this should enable the application to work as it did on Windows XP without a need for any changes to the application.

Remedies

• Generally, applications should not perform OS version checks or, at minimum, always accept version 6 or later for the OS. This behavior should be followed unless there is a very specific legal, business, or system-component need to do this version check.
• Application installers should not use 16-bit installers to ensure 64-bit system compatibility.
• Ensure that any drivers an application uses are user mode drivers as much as possible to maintain multiplatform (32-bit and 64-bit) compatibility.

User Account Control

Feature Impact

High

Brief Description

A fundamental step toward increasing the security of Windows is enabling interactive users to run with a standard user account, which gives them access to only a limited set of permissions and privileges. By default, Windows Vista will run every application as a standard user even if you log on as a member of the administrator's group. Conversely, when users attempt to launch an application that has been marked as requiring administrator permissions, the system will explicitly ask them to confirm their intention to do so. Only applications running with administrator privileges can modify system and global settings and behavior. This feature of Windows Vista is the User Account Control (UAC).

Manifestation

• Custom installers, uninstallers, and updaters may not be detected and elevated to run as administrator.
• Standard user applications that require administrative privileges to perform their tasks may fail or not make this task available to standard users.
• Applications that attempt to perform tasks for which the current user does not have the necessary permissions, may fail. How the failure manifests itself is dependent upon how the application was written.
• Control panel applications that perform administrative tasks and make global changes may not function properly and may fail.
• DLL applications that run using RunDLL32.EXE may not function properly if they perform global operations.
• Standard user applications writing to global locations will be redirected to per-user locations through virtualization.

Remedies

Quick solution for custom installers:

• A user can launch the installer or updater by right-clicking and selecting Run this program as administrator.
• Apply an application compatibility fix to indicate that specific installers require elevation. To do so, right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab.

Quick solution for applications that require administrative privileges to perform system modifications or write to privileged areas:

• Corporate users will be able to apply an application compatibility fix to indicate that the legacy application requires administrator permissions or privileges to run correctly.
• Reducing the restrictions of access control lists (ACLs) on certain restricted files may help applications that attempt to write these files.
• Check the virtualized folders or registry keys to see if applications are accessing something that requires administrator privileges. This information can be used to remove the requirements of accessing administrator-protected locations from future versions of the application. For more information about virtualized files, folders, and locations, see the "Links" section.
• Wrap a "Run DLL as an app" DLL call in a separate EXE and include a manifest for this EXE to require elevated privileges.

Compatibility test:

• Any install, uninstall, or update scenario should prompt the user for consent or credentials. Upon receiving user approval, the action should succeed.
• Attempt to reproduce the failing scenario as the built-in-administrator. If this scenario passes, the failure is probably due to a lack of privileges.
• Use the User Account Control predictor tool of the Application Compatibility Toolkit's Compatibility Administrator to identify those areas of an application that are performing administrator operations.

Leverage Windows Vista capability solution:

• Windows Vista based applications need to:
  • Follow the prescribed guidelines found in the Windows Vista LOGO program and user experience (UX) guidelines documentation (see the "Links" section).
  • Use embedded manifests to indicate their specific requestedExecutionLevel (formerly known as RunLevel).
  • Separate all administrative and non-administrative functions into separate EXEs. All functions that need higher privileges should be in a separate executable EXE with manifested execution level or a COM object running with administrative privileges. Launch the administrative tasks only when required. This holds true for all applications.
• For applications that are not specifically administrative in nature, modify code to eliminate need for administrator permissions or privileges.
• For applications that are only used by administrators, mark the application so it will run with administrator permissions or privileges.
• When updating an application, use a separate updater EXE to update the target application.
• Control panel applications must move away from .cpl files to .exe files, and include a manifest for their EXE-based control panel applications that specifies the execution level required.
• DLLs running under RunDLL32.EXE that need elevation should be modified into an executable EXE with its elevation level indicated in its manifest.
• Always open files and registry keys with read-only access when possible. Use read-write access only when needed and revert the permissions back to read-only once the operation is complete.

Links

• Windows Vista security
• Windows Vista UAC main page
• Getting Started with User Account Control
• Developer Best Practices and Guidelines for Applications in a Least Privileged Environment
• Windows Vista User Experience
• File and registry virtualization details
• Slides from the Microsoft Professional Developers Conference (PDC) 2005; search for FUN406
• UACBlog
• UAC-related question on Microsoft Forums
• Aaron Margosis' WebLog; search for "Not running as administrator"

User Account Control - Application Update Guidelines

Feature Impact

Medium

Brief Description

Many existing applications have a tendency to incorporate update functionality in their application. The goal of embedding update functionality is to ensure that the client is running the most up to date binary that the ISV can offer.

It has been found that a number of applications, when they perform their updating functions, require more privileges than that of a Standard user. Often, the per-machine files that were laid down during installation need to be serviced. As per the UAC model for running and installation applications, only the elevated administrator in Admin Approval Mode Admin has sufficient privileges to perform these actions.

The Windows Vista Installer Detection heuristics detect many applications' updaters correctly and elevate the updater process appropriately so that the update completes successfully on elevation. However, a few areas remain where application updates cannot complete successfully. For example:

• Out of Process Updaters not Install Detected—Updaters that do not get detected through install detection heuristics.
• Multi-purposed executables/ In-process updates—Overloaded executables that perform more than one operation. For example, the binary is both the main application and the updating application OR the multi-purposed executable runs as a thread within the application

Manifestation

Application update functionality fails

Remedies

Out of Process updaters not Install Detected

• This is an issue that could occur within any enterprise and could result in that enterprise requiring an application to be run with Administrator privileges. If an application updates itself by using a separate process that is not installer detected then this separate process should be marked as requiring Administrator privileges using App Fix.
• Updaters that do not work as a user will prohibit an enterprise from running with least privilege.
• The updater should be written as a separate process with a desired run level of requires Administrator.
  • This process should only execute when necessary for updating purposes. Checking for whether the program needs updates should be done as the user.

Multi Purpose Executables/In-Process Updates

On Vista, there is no good way to create a multi-purpose executable that performs updates because you can't toggle the state under which an executable is run. Consequently, the executable will always have to run as Administrator. Instead, applications should follow one of the following methods to perform updates.

1. Utilizing Patching technology in MSI (Latest versions of Windows Installer, InsallShield, Wise etc. support this).
   • MSI is a key installer technology because it provides the ability to manage updates for you.
   • Use MSI to create your initial installer and embed a certificate in the MsiPatchCertificate table.
   • Create an update for your application and sign it with the previously specified certificate.
   • MSI will perform the elevation for the application when applying the patch.

   Note   The main advantage of this method over others is that it works with Standard User, and keeps the game secure. It provides a better user experience because the Standard User account doesn't have to ask an Administrator to install the patch or request permanent Administrator privileges to play the game.

2. Using other custom installer mechanisms.
   • This is discouraged for the enterprise environment because this will prohibit user from running as non-Administrators
   • The updater should be written as a separate process with a desired run level of requiresAdministrator.

     Note   This process should only execute when necessary for updating purposes. Checking for whether the program needs updates should be done as the user.

3. Updating while running as a "Standard User" applications.
   • Updating can occur as a Standard User when using ClickOnce technology. Again, this is an install platform that allows the user to deploy applications within it and handles the updating for the app writer.

Links

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/patching_and_upgrades.asp

http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/

Windows Resource Protection (WRP)

Feature Impact

High (may block the application from installing or running)

Brief Description

As an initiative to increase system stability, predictability and reliability, Windows Resource Protection (WRP) protects Windows read-only resources: specifically OS files, folders, and registry keys that are non-configurable by design. See Protected Resource List.

WRP enforces this protection using Windows Security by specifying special security descriptors on the resource. Any process, including those running as administrator or system, do not have rights to make changes to WRP resources; they can read and execute. Full access to WRP resources is restricted to Windows Modules Installer service.

As a result, read-only system state is protected from the inadvertent impact of application installs and administrator modifications, which improves system stability.

Manifestation

Applications (typically this happens during application install and uninstall) will not succeed in replacing or modifying protected OS resources, with the following results:

• Attempts to replace, modify, or delete OS files and/or registry keys that are protected by WRP may fail with an error message indicating that the resource could not be updated. This is because access to these resources is denied.
• Attempts to write new registry keys or values to protected registry keys may fail with an error message that indicates that the change failed because access was denied.
• Attempts to write to protected resources may fail if they rely on the application succeeding in writing to protected registry keys or values.

Because applications are prevented from making changes to WRP resources, and related errors are suppressed, runtime errors may result.

Mitigations

Important   The following mitigation will not be applied if the application has a manifest that specifies a requestedExecutionLevel as required by UAC.

For well-known installers, Access Denied errors resulting from attempts to create, modify, or delete WRP resources will be suppressed, and no changes are applied to the WRP resource.

Remedies

• Do not install or update system state (files and registry) on Windows Vista except when using Microsoft-provided redistributable packages designed for Windows Vista.
• Do not decompose a Microsoft-provided redistributable designed for Windows Vista and install individual files or registry keys. The redistributable must be installed as provided by Microsoft.
• Use SfcIsFileProtected API to detect WRP-protected files. If a file is WRP, then the application installer should not install or modify the file.
• Use SfcIsKeyProtected API to detect WRP-protected keys. If a key is WRP, then the application installer should not install or modify the key.

WRP Protected Keys

It is expected that if an application attempts to create/modify/delete a WRP key then that application will get an "Access Denied" error. When you encounter an "Access Denied" error, verify that the access denied error is a result of a WRP Security Descriptor on the key (or a parent key) and not because the user does not having enough permissions to write to the key.

The decision on how to handle an "Access Denied" error because of WRP will depend on the impact of this failure for the application:

1. If the application is trying to write a key or value that already exists, then the application can ignore the error message.
2. If the key or value does not exist then as the developer you must decide the impact on your application. Is this key required for your application to run successfully on Windows Vista? If not, then you can ignore the error. If this key is required then you will need to redesign your application to write to an alternate key or use some alternate design.

How to recognize if a resource is WRP:

For Registry:

1. Through code, use SfcIsKeyProtected API.
2. Or use Regedit to check permissions on the key.

• Click Start, and then click Run.
• Type Regedit, and then click OK.
• Search for the key. Right-click the registry key. Click Permissions.
  • Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators, and Users will only have Read permissions.

For files:

1. Through code, use SfcIsFileProtected API.
2. Or use Explorer to check permissions on the file.
   • Open the folder that contains the file whose properties you want to see.
   • Right-click the file whose properties you want to see, and then click Properties.
   • Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators, and Users will have Read permissions only.

Internet Explorer Protected Mode

Feature Impact

High

Brief Description

In Windows Vista, Microsoft Internet Explorer 7 runs in Protected Mode, which can help protect users from attack by running the Internet Explorer process with greatly restricted privileges. Protected Mode significantly reduces the ability of an attack to write, alter, or destroy data on the user's machine or to install malicious code. It can help protect a user from malicious code installing itself without authorization. This is the default mode for Internet Explorer when Windows Vista is installed.

Manifestation

• Applications that use Internet Explorer 7 will not be able to write directly to disk while in the Internet or Intranet zone.
• Applications may not know how to handle new prompts.

Protected Mode builds on the new integrity mechanism to restrict write access to securable objects like processes, files, and registry keys with higher integrity levels. When run in Protected Mode, Internet Explorer is a low-integrity process; it cannot gain write access to files and registry keys in a user's profile or system locations.

Low-integrity processes can only write to folders, files, and registry keys that have been assigned a low-integrity mandatory label. As a result, Internet Explorer and its extensions run in Protected Mode, which can only write to low-integrity locations, such as the new low-integrity Temporary Internet Files folder, the History folder, the Cookies folder, the Favorites folder, and the Windows Temporary Files folders.

Furthermore, the Protected Mode process will run with a low desktop integrity level when Windows Vista ships, which will prevent it from sending specific window messages to higher integrity processes.

By preventing unauthorized access to sensitive areas of a user's system, Protected Mode limits the amount of damage that can be caused by a compromised Internet Explorer process or malware. An attacker cannot, for example, silently install a keystroke logger to the user's Startup folder. Likewise, a compromised process cannot manipulate applications on the desktop through window messages.

Of course, these defenses also limit legitimate changes to higher integrity locations (IL). As a result, Protected Mode provides a compatibility architecture that reduces the impact on existing extensions, as shown in the following figure.

Figure 1.

A compatibility layer handles the needs of many existing extensions. It intercepts attempts to write to medium integrity resources, such as the My Documents folder in the user profile and the HKEY_CURRENT_USER registry hive. The compatibility layer uses a generic Windows compatibility fix to automatically redirect these operations to the following low-integrity locations:

• %userprofile%\LocalSettings\Temporary Internet Files\Virtualized
• HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry

Two higher privilege broker processes allow Internet Explorer and extensions to perform elevated operations given user consent. For example, the user privilege broker (IEUser.exe) process provides a set of functions that let the user save files to areas outside of low-integrity areas. In addition, an administrator privilege broker (IEInstal.exe) process allows Internet Explorer to install ActiveX controls.

Remedies

Quick solution:

• Add the site in question to the trusted sites list.
• Turn off Protected Mode (not recommended).

Compatibility test:

• Apply the quick solution and ensure that the application can perform the dependent functions as in Windows XP SP2.

Leverage Windows Vista capability solution:

• Change the application to handle Protected Mode, including any related prompts that may be displayed.

Links

• Security and Compatibility in Internet Explorer 7
• Understanding and Working in Protected Mode Internet Explorer
• Internet Explorer Developer Center
• Information Index for Internet Explorer 7 Beta 2 Preview

Windows Vista 64-bit

Feature Impact

High

Brief Description

Windows Vista fully supports the 64-bit architecture processors from AMD and Intel. The 64-bit version of Windows Vista can run all 32-bit applications with the help of the WOW64 emulator. However, 16-bit applications, 16-bit installers, and 32-bit kernel mode drivers are not supported by the kernel.

All 64-bit drivers have to be digitally signed for Windows Vista 64-bit editions. Unsigned drivers are not supported and cannot be installed on 64-bit Windows Vista. The digital signature check is done both during installation and driver load time.

Manifestation

• Applications or components that use 16-bit executables, 16-bit installers or 32-bit kernel drivers will either fail to start or will function improperly on a 64-bit edition of Windows Vista. In this case, the following error message is displayed:

  The program or feature "[exepath]\[app16bit].exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.

• When a 16-bit installer or application is launched, the following error message is displayed:

  The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

• Installation of 32-bit kernel drivers will fail on the 64-bit system. If an installer manually adds a driver by editing the registry, the system will not load this driver and this action could cause the system to fail.
• Installation of 64-bit unsigned drivers will fail on the 64-bit system. If an installer manually adds a driver by editing the registry, the system will not load the driver during load time if it is not signed.

Remedies

Leverage Windows Vista capability solution:

• All 16-bit components should be removed from applications and replaced with 32-bit or 64-bit equivalents.
• All 16-bit installers should be converted to 32-bit or 64-bit installers.
• If the application uses kernel mode drivers, then a 64-bit version of the driver needs to be authored. The application should detect the platform of the OS (32-bit or 64-bit) and then install the proper architecture of the driver based on the OS platform.
• Ensure that all 64-bit drivers are digitally signed.

Compatibility test:

• Install and launch the application on a 32-bit and a 64-bit Windows Vista machine. The application should function properly on both architectures.

Links

• Running 32-bit Applications
• Video
• Digital Signatures for Kernel Modules on x64-based Systems Running Windows Vista

Microsoft Graphical Identification and Authentication (GINA)

Feature Impact

High (frequency: low)

Brief Description

Prior to Windows Vista, to log on to a third-party server or with a third-party device, ISVs had to replace the Graphical Identification and Authentication (GINA) dynamic-link library in Windows XP. Such applications also had to replace the existing UI and implement smart card and remote desktop features on Windows XP.

Note   If an application did not function this way in Windows XP, then this information does not apply.

Windows Vista introduces a new authentication model where LogonUI and WinLogon communicate directly with each other. This model provides simplicity, scalability, and flexibility that did not exist with GINA. Unlike the GINA module, ISVs no longer need to replace the UI for the logon screen, thus relieving the ISV of the burden of re-authoring the user interface for the user. An ISV can author a credential provider, which is a module that plugs into the LogonUI, to describe the UI and to gather the credential and pass it on to WinLogon. Credential providers are completely transparent to WinLogon.

Credential providers are also additive, meaning that users can install multiple credential providers and pick the one they want to use. Credential providers can be user selected and/or event driven. Multiple credential providers can coexist on Windows Vista and are not only for third parties. In fact, Windows will ship two credential providers in the box: a user name and password credential provider and a smart card credential provider.

Additionally, credential providers can be reused within CredUI. That is, the same object that describes and collects credential information on LogonUI can be used to gather the very same credentials in CredUI scenarios.

The GINA functionality from Windows XP and Windows Server 2003 has been deprecated and removed from Windows Vista. The GINA modules of applications will not function and will have to be re-authored using the new authentication model for Windows Vista.

Manifestation

• User will not be able to successfully install custom logon applications.
• User will not be able to log on using custom logon applications (using the Windows XP technology) in Windows Vista. These may include:
  • Biometric devices.
  • Custom UI for logon.
  • Virtual private network (VPN) solutions for remote users with custom logon UI.

Remedies

Leverage Windows Vista capability solution:

• The applications or components that use the GINA technology will need to be re-authored to use the new logon authentication model for Windows Vista.

Links

• For all credential provider information and questions, send e-mail to the Shell Credential Provider alias: credprov@microsoft.com

Session 0 Isolation

Feature Impact

High (frequency: low)

Brief Description

In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level.

The Microsoft Windows Vista operating system mitigates this security risk by isolating services in Session 0 and making Session 0 non-interactive. In Windows Vista, only system processes and services run in Session 0. The first user logs on to Session 1, and subsequent users log on to subsequent sessions. This means that services never run in the same session as users' applications and are therefore protected from attacks that originate in application code.

Specific examples of affected driver classes include:

• Printer drivers, which are loaded by the spooler service.
• All drivers authored with the User Mode Driver Framework (UMDF), because these drivers are hosted by a process in Session 0.

Application classes affected by this feature:

• Services that create UI.
• A service that tries to use window message functions such as SendMessage and PostMessage to communicate with an application.
• Applications creating globally named objects.

Manifestation

If a service belonging to an application throws a UI, the application is waiting on the service, and the UI is not displayed in the user session.

Remedies

Quick solution:

• If the application's service uses a UI, a built-in mitigation in Windows Vista allows the user to interact with the Session 0 UI in a special desktop. This will make available the UI specific to the application, instead of the entire Session 0 desktop.
• If the application creates globally named objects, then use the Windows XP compatibility mode to ensure that the application will continue to work with the Session 0 services.

Compatibility test:

• Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS) mode. If the application works properly on Windows XP in these scenarios, then it is very likely to work under Windows Vista.
• Verify that the application functions properly after applying the Windows XP compatibility mode, which contains mitigation for some of the Session 0 issues.
• Test the driver in Windows Vista to ensure that it runs properly. If that is not possible, test the driver in Windows XP with FUS enabled and multiple users logged on. If the driver works correctly for second and subsequent logged-on users, it is not likely to be affected by the Session 0 changes in Windows Vista. The only issues that this test does not detect are those related to the absence of the video driver in Session 0 in Windows Vista.

Leverage Windows Vista capability solution:

• Use client or server mechanisms such as remote procedure call (RPC) or named pipes to communicate between services and applications.
• Use the WTSSendMessage function to create a simple message box on the user's desktop. This allows the service to give the user a notification and request a simple response.
• For more complex UI, use the CreateProcessAsUser function to create a process in the user's session.
• Explicitly choose either the Local\ or Global\ namespace for any named objects, such as events or mapped memory, that the service makes available.

Links

• Impact of Session 0 Isolation on Services and Drivers in Windows Vista
• Services
• Synchronization
• Making a Remote Procedure Call
• Client/Server Applications
• CreateProcessAsUser
• Test Your Application with Fast User Switching

Networking: TCP/IP Stack and the Windows Filtering Platform

Feature Impact

High

Brief Description

The Windows Vista networking stack has been completely rewritten. Instead of the dual stack model that exists in Windows XP or Windows Server 2003 (to support IPv4 and IPv6), Windows Vista implements a new architecture whereby there is a single transport and framing layer that support multiple IP layers. There are several new features and protocols enhancements. The new stack is very modular, flexible, and extensible. While all attempts have been made to maintain application compatibility with the existing applications that interface with the stack at various layers, nevertheless, there are changes (that are mostly side-effects of the improvements) that may have potential application compatibility issues and that application developers must carefully evaluate to understand the impact of these changes on their applications.

The Microsoft Windows Filtering Platform (WFP) API allows developers to create code that interacts with the filtering that takes place at several layers in the Windows Vista and Microsoft Windows Server Code Name "Longhorn" operating system networking stack and throughout the operating system. WFP also integrates with and provides support for firewall features, such as authenticated communication and dynamic firewall configuration, based on an application's use of the sockets API.

Note   WFP is not a firewall itself. It is a set of system services and APIs that enable firewalls to be implemented.

The following elements of the TCP/IP stack will not be supported on Windows Vista:

• The firewall-hook driver functions and the filter-hook driver functions have been deprecated.
• The R-series tools, including rexec, rsh, finger, and so on. These tools are available from the Services For Unix components, if needed.
• The Internetwork Packet Exchange (IPX) protocol. IPX has been deprecated and is not used much, if at all. There should be no or minimal application compatibility impact because of this change.

Manifestation

• If an application built for Windows XP was using only public functions for networking, it should not see any break in functionality. It should be tested on Windows Vista to verify its functionality.
• Applications using any of the firewall-hook driver or filter-hook driver functions will not work.
• Applications relying on internal structures and functions calls that were never published by Microsoft will fail.
• Transport Driver Interface (TDI) filter drivers written in Kernel mode may not work properly after an OS upgrade.

  Note   The TDI interface is on a path to deprecation in a future release. However, these drivers will still work on Windows Vista.

Remedies

Leverage Windows Vista capability solution:

• The WFP exposes a rich set of functions and services for the network security developers and provides guidance and documentation on the available feature sets.

  Note   Applications and scripts that rely on Services for Unix and R-series must now install these tools first.

Links

• WFP architecture, details, and SDK (prerelease)
• Interoperability and Migration Center

Networking: Kernel Mode IP Helper APIs

Feature Impact

High

Brief Description

In prior releases of Windows, Winsock clients did not have an API set to access the kernel. This will change in Windows Vista. Also, Windows Vista now supports IPv6 by default. Instead of providing separate APIs for IPv4 and IPv6, a new Helper API set was designed to provide a common functionality across all the new technologies, as follows:

• Kernel mode functions for Windows Sockets in Kernel (WSK) clients.
• IPv6 support.
• Single set of functions for IPv4 and IPv6 addressing.
• Provides a consistent, extensible object model.
• Provides a well-defined security model based on the network service interface.
• Exposes new stack functionality, such as compartments and subinterfaces.

Manifestation

Applications using the older Helper APIs or undocumented kernel function calls will fail to function and may become unstable.

Remedies

• Applications need to support and implement the new kernel mode IP helper APIs.

Links

• None at this time.

Networking: IPv6

Feature Impact

High (frequency: medium)

Brief Description

The TCP/IP stack in Windows Vista has IPv6 enabled by default. IPv6 connectivity is preferred, if available. This has the following implications for applications that hook into the TCP/IP stack:

• IPv6 traffic will be sent by the Windows Vista stack regardless of whether the network supports IPv6 or not. Therefore, for example, router solicitation and neighbor discovery messages will be generated by default.
• IPv6 addresses will be present and on by default. There may be multiple IPv6 addresses associated with link-local, global, temporary, or transition technologies like 6to4, 6over4, ISATAP, or Teredo.

  Note   Teredo will be enabled by default.

• Windows Vista will allow a system to be configured in an IPv6-only mode. In this case, no IPv4 support will be available.

The TCP/IP stack in Windows Vista supports a strong host routing model. This means that packets are routed from a multi-homed machine not only based on the destination address but also based on the source address of a packet. This change is needed because in IPv6, each machine gets multiple IP addresses and, with transition technologies, essentially appears as a multi-homed machine as far as routing is concerned. To ensure proper connectivity happens in these scenarios, the networking stack has to implement a strong host routing model.

Manifestation

Applications using the Windows XP TCP/IP stack and/or unaware of the IPv6 protocol will not function properly and may crash or create an unstable system.

The implication of the strong host routing model for the applications is as follows:

• Connection from a non-loopback address to a loopback address and vice-versa will fail.
• Packets with a source address of 127.0.0.0/8 will not be allowed to be sent by a Windows Vista machine on a network.

Remedies

Applications will need to be re-authored as follows:

• Any application that hooks into the stack must be capable of handling IPv6 traffic. Minimally, it should not crash on receiving IPv6 traffic.
• Any application that relies on there being a single IPv4 address will need to be modified to handle multiple IPv6 addresses. Further, any application that picked the first address may have to more carefully identify the IPv6 address to use. This is because an IPv6 link-local address is not routable and hence, the application may not work. Instead, the application should use functions that allow connection by name and choose the most appropriate address automatically.
• Applications must handle and support IPv6-only scenarios.
• Applications must support and implement the strong host routing model.

Links

• IPv6 Guide for Windows Sockets Applications

Networking: Turning off the Windows Firewall

Feature Impact

High

Brief Description

In order to avoid the situation where a user–installed firewall (which is compatible with Windows XP but is incompatible with Windows Vista) attempts to turn off the Windows Firewall in Windows Vista, Microsoft has deprecated the Windows Firewall XP SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) function in Windows Vista. When called on Windows Vista, this function will return and error code of E_NOTIMPL, show a message to the user and will log an appropriate event in the Windows event log.

Manifestation

Applications using the Windows XP SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) function to turn-off the Windows Firewall on Windows Vista will receive an error code.

Remedies

Applications (typically firewalls) replacing the Windows Firewall with their own firewall solution, must carefully consider the following security-related points:

• Windows Vista supports IPv6 and IPv4 out-of-the-box and will automatically have link local IPv6 address; therefore, it is essential that your firewall solution filters BOTH IPv4 & IPv6.
• Windows Vista also supports additional IP protocols (e.g., GRE, L2TP, PGM & ICMPv6); therefore, it is essential that your firewall solution filters arbitrary protocol filtering (IANA Protocol 0-255) & ICMP type and code filtering.
• In Windows Vista there are listening processes in both user mode and kernel mode (i.e., system process, http.sys, smb.sys); therefore, it is essential to filter BOTH User mode and Kernel mode network traffic.

Microsoft further recommends that these applications:

• Do not replace the Windows Firewall unless all of the security-related points specified above are addressed.
• Check the firewall status before your application turns-off or disables Windows Firewall with Advanced Security.
• Do not turn off the firewall service (mpssvc) since this is the service that enforces Windows Service Hardening restrictions.
• Allow their firewall solution to overlap with Windows Firewall with Advanced Security in order to minimize your customers' exposure to security threats.

Applications can disable Windows Firewall with Advanced Security by using the following code example. To protect users, they you should only disable Windows Firewall with Advanced Security after: (1) you have successfully turned on your firewall solution with the recommended settings; and (2) you have notified the user that Windows Firewall with Advanced Security is going to be disabled.

C++

#include <objbase.h>
#include <windows.h>
#include <stdio.h>
#include <comutil.h>
#include <strsafe.h>
#include <netfw.h>

#import "netfw.tlb"

HRESULT 
CoCreateInstanceAsAdmin(
    HWND hwnd, 
    REFCLSID rclsid, 
    REFIID riid, 
    __out void ** ppv
    )
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, 
sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), 
L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);
}

int __cdecl main()
{
    HRESULT hr;
    BOOL fComInitialized = FALSE;

    try
    {
        //
        // Initialize the COM library on the current thread
        //
        hr = CoInitialize(NULL); 
        if (FAILED(hr))
        {
            _com_issue_error(hr);
        }
        fComInitialized = TRUE;
        NetFwPublicTypeLib::INetFwPolicy2Ptr sipFwPolicy2;

        hr = CoCreateInstanceAsAdmin(GetDesktopWindow(), 
__uuidof(NetFwPolicy2), IID_PPV_ARGS(&sipFwPolicy2));
        if (FAILED(hr))
        {
            _com_issue_error(hr);
        }
        sipFwPolicy2->FirewallEnabled[NetFwPublicTypeLib::NET_FW_PROFILE2_DOMAIN] = FALSE;
        sipFwPolicy2->FirewallEnabled[NetFwPublicTypeLib::NET_FW_PROFILE2_PRIVATE] = FALSE;
        sipFwPolicy2->FirewallEnabled[NetFwPublicTypeLib::NET_FW_PROFILE2_PUBLIC] = FALSE;
    }
    catch (_com_error& e)
    {
        printf ("Error. HRESULT message is: %s (0x%08lx)\n", e.ErrorMessage(), e.Error());
        if (e.ErrorInfo())
        {
            printf ("Description: %s\n", (char *)e.Description());
        }
    }
    if (fComInitialized)
    {
        CoUninitialize();
    }
    return 0;
}

Visual Basic Script

option explicit
' Profile Type
Const NET_FW_PROFILE2_DOMAIN = 1
Const NET_FW_PROFILE2_PRIVATE = 2
Const NET_FW_PROFILE2_PUBLIC = 4

Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
fwPolicy2.FirewallEnabled(NET_FW_PROFILE2_DOMAIN) = FALSE
fwPolicy2.FirewallEnabled(NET_FW_PROFILE2_PRIVATE) = FALSE
fwPolicy2.FirewallEnabled(NET_FW_PROFILE2_PUBLIC) = FALSE

Links

Windows Firewall with Advanced Security Reference

Compatibility Risks

Deprecated Components

The following components from earlier Windows releases will not be present in Windows Vista:

• Kernel mode Printer driver support: All printer drivers will now have to follow the User mode driver framework. All kernel mode printer drivers will be blocked from loading on Windows Vista. For more information, see the User-Mode Driver Framework (UMDF) site.
• Windows Help (WinHelp.exe and WinHlp32.exe) is being deprecated for Windows Vista. Windows Help is not supported in Beta 2 and some of the Windows Help code has been removed for the release. To view Help files with the .HLP file name extension in Windows Vista, you will need to download and install Windows Help from the Microsoft Download Center. This download will not be available for Beta 2 or RC1. For more information, see Help Engine Support.

  Note   HTML Help and .CHM files will continue to be supported for Windows Vista.

• Microsoft FrontPage server extensions. Windows SharePoint Services now provides an enhanced feature set to the developer community.
• Services for Macintosh.
• D3DRM. DirectX will be the only supported graphics package for Windows Vista.
• Web Publishing Wizard.
• NetDDE—For security reasons, Windows Vista does not support NetDDE. (NetDDE is disabled by default on Windows XP SP 2 and Windows Server 2003.) Regular DDE is still supported. NetDDE is a technology that allows applications that use the DDE transport to transparently exchange data over a network. The result is the application fails to exchange data over the network. To workaround, use a different networking technology, such as DCOM or Windows Communication Foundation. For more information about NetDDE, see http://support.microsoft.com/default.aspx?scid=kb;en-us;125703.

Help and Support Center

The Help and Support Center (HelpCtr.exe) was a Help application designed for Windows XP and Windows Server 2003. The Help and Support Center displayed compiled Help files with the .CHM file name extension.

The Help and Support Center is not included in Windows Vista and its features are not supported. Compiled Help files with the .CHM file name extension will only be displayed in the HTML Help application as described above.

Assistance Platform Client

The Assistance Platform client (HelpPane.exe) is a new Help engine designed for Windows Vista. It is not compatible with any previous versions of Windows. The Assistance Platform client is required to display Help files with the .H1S file name extension.

In Windows Vista, the Assistance Platform client can be customized by OEMs, system builders, and enterprise customers under license agreement, but cannot be used by third-party programs. For more information on customizing the Assistance Platform client, see the Windows SDK.

Windows Vista Display Driver Model (VDDM)

Windows Vista Display Driver Model (VDDM) is a completely new display driver model that improves display driver stability in Windows. There are a number of key features in VDDM, including:

• Efficient management of video memory for DX applications and the new Desktop Window Manager (DWM). Multiple 3-D applications will be using the graphics processor unit (GPU) in Windows Vista.
• Driver upgrades without reboot.
• Dynamic detection of GPU hangs and recovery without reboot.
• Hot Plug detection support of monitors.
• Using the hardware features mandated by DX9L.
• Glitch-free video playback.
• An opportunity for a very secure design.

While most of the applications from earlier versions of Windows should not be impacted by VDDM, some risks include:

• DX Games compatibility, resulting in DX run-time or IHV driver or core graphics stack issues.
• Mobile functionality like hotkey, cloneview, brightness and zoom due to stricter ACPI requirements.
• Accessibility, specifically that screen magnification applications designed by Windows XP will not work on Windows Vista.

Links

• E-mail the Graphics Feedback alias: lhgfxfb@microsoft.com

Safe Exception Handling

In earlier Windows versions, the IsBadReadPtr and IsBadWritePtr functions were used to validate parameters. These functions are now banned on Windows Vista. Also, applications that rely on Windows components using these functions to validate parameters will find that Windows no longer uses them. Applications should not rely on Windows to do any parameter validation (a check for null is done and the application fails if it is a bad pointer).

Safe exception handling (SEH) also goes hand-in-hand with the no-execute flag. Exception handlers are checked that they are marked page_execute before the exception is dispatched, and also that the handler is valid code and that it is in the SEH table.

DLLmain Operations

The load order of DLLs during process creation is not guaranteed and should never be depended upon to perform operations. Complex processing in DllMain may cause applications to hang or crash because of new OS component dependencies. For details, see the following pages on MSDN:

• Dllmain
• "Calls to an OLE Object Should Not Be Done from DllMain"
• "PRB: Cannot Create an MFC Thread During DLL Startup"
• "Your application may fail with an 'Access Violation' error message when you use ODBC or DAO in the InitInstance or DllMain functions of a DLL"
• "COM application hangs when you call CoCreateInstance from DllMain"

Outlook Express Renamed

Outlook Express has been changed and moved, and is now called Windows Mail. MAPI applications need to be aware of this change. Most applications that dynamically use the default program for MAPI should not see any compatibility problems.

Shell: Themes and My Documents Location

The Windows Explorer Shell has introduced new visual themes for Windows Vista. An application capable of handling themes in earlier versions of Windows should have no compatibility impact with the new themes.

Also, the My Documents location and structure has changed in Windows Vista to provide a better user experience. The user data is now stored in \users\%username%\ folder structure. Pictures, Music, Documents, Desktop, and Favorites are all new folders directly under this structure. If an application uses the ShGetFolderPath function and uses the folder path dynamically, it will be redirected automatically to the new path and file locations. In general, applications will not see a compatibility impact due to these changes.

Fast User Switching (FUS)

Fast User Switching (FUS) is now available on Windows Vista for all versions, including domain joined computers. Applications and installers need to be aware of FUS and be able to handle multiple logged in user sessions and terminal server scenarios. For more information, see Microsoft Windows XP Fast User Switching: Design Guide for Building Business Applications.

CriticalSection Code Changes

CriticalSection code was changed to increase security and robustness. Applications using critical section locks:

• Should always initialize critical sections.
• Should not read into undocumented objects. Applications that read into the undocumented structures to assess the status of a critical section will most likely break if they are looking for uninitialized and freed critical sections.
• Should prevent starvation. Applications that call Sleep while holding the critical section lock now can cause starvation for other threads that need the lock. Sleep calls should be placed after the LeaveCriticalSection call.

For more information, see the critical section objects topic in MSDN.

User Interface Privilege Isolation (UIPI)

In Windows Vista, User Interface Privilege Isolation (UIPI) is enabled by default. As a result of this security feature, a process in a lower integrity level cannot communicate with a higher integrity level process using Windows Messaging (SendMessage). This means that applications running under standard user level cannot communicate with other applications running with an elevated administrative level. This also means that applications installing keyboard or mouse hooks will now need to change to use manifests and request elevation. For related information, see the "Internet Explorer Protected Mode" section in this document.

Default Programs

Feature Impact

Medium

Brief Description

Default Programs is a new infrastructure to manage per user file and protocol associations designed with contentious applications in mind. Applications need to register in order to use Default Programs functionality. Be aware that Default Programs will get a lot of visibility in Windows Vista and beyond and make certain tasks much easier for applications to code and maintain.

It is difficult in today's software ecosystem to manage your default behaviors in Windows because there are so many competing applications for common tasks. Many people have multiple software programs that do the same things: browse the web, view photos, play music, watch movies, and manage e-mail to name a few. Many people have great difficulty because even if they decide to try an application, it has forever taken over their system and default behaviors like double click.

The problem gets worse as we start adding multiple users onto the same computer. As multiple users start using different applications they will start stomping on each others defaults. The root of this problem is that both protocols and file association are typically only taken or managed on a per machine basis by writing keys in the registry to HKLM (HKEY_Local_Machine). To make the matter more difficult there are multiple places in the registry where applications write to take the defaults.

This often results in some applications writing to one place in the registry and other applications writing to another place. The problem gets worse as these applications want to reclaim being the default for certain behaviors but they can't because they aren't writing to all the places other applications have. The core problem is that there needs to be an easy way to manage applications on the system that have competing interests.

Remedies

Windows first attempt to solve this problem was SPAD (Set Program Access and Defaults). This gave users the ability to allow an application to try to reclaim it's once default behavior. SPAD simply allowed applications to run some registered code to get back to some state. SPAD was a big switch and set defaults for the entire computer. SPAD will still be available in Windows Vista to allow an administrator to configure the machine defaults and hide access, but will not be the primary defaults experience for users.

In Windows Vista, we have provided a new set of functionality for applications to take advantage of. This new set of functionality is called "Default Programs". Default Programs was designed to help users make choices about their default behaviors. A large part of this is that defaults in Windows Vista and beyond will be primarily controlled at the Per User level instead of the Per Machine level. This allows much more flexibility for the multi-user computer environment that we believe is going to become the standard. Part of this is adding new centralized UI for the user, but the other part is giving ISVs the tools they need to help a user express choice. Default Programs gives an application:

• A simplified process for taking defaults.
• Per user file and protocol associations.
• Programmatic way to check for defaults.
• Common Windows UI to reuse.
• Advertising area within Windows.

This functionality was primarily designed for contentious applications. These are applications that want to be the default for file types like mp3 and jpeg, or protocols like http and mailto. Applications that primarily deal in their own protocols and file associations won't typically need to use this new functionality since they don't have to worry about other applications stomping over them. Applications that aren't contentious will behave and install like in XP. However, any application can take advantage of the new "Default Programs" work.

"Default Programs" functionality is built into the operating system as a series of control panels and open APIs. For an application to use the control panels or APIs it needs to register at install time to be part of Default Programs by writing a specific schema. This will allow the application to show up in the Default Programs control panels so a user can restore the application's default file associations and protocols at any given time.

Once an application has registered with Default Programs the application can take advantage of new functionality provided through APIs. Default programs provides APIs to:

• Restore all registered defaults.
• Restore single registered default.
• Query for the owner of a specific default file association/protocol/start menu canonical.
• Launch Defaults UI for a specific app.
• Clear all per-user associations.

The Default Programs work is intended to make it very easy to express user choice post-install and provide applications a simple framework to contend for defaults and claim them.

Why Use Default Programs

High-level points:

• Default Programs helps applications get discovered.
• The underlying architecture that allowed all administrators to write to HKLM is changing for Windows Vista.
• Default Programs allows applications to maintain XP parity process flows while changing very little code.
• Claiming only machine level defaults won't always give the desired results.

There is an obvious consumer gain for contentious applications using the Default Programs framework, but there is also a significant gain for the application to use Default Programs.

Default Programs provides a rich UI experience for registered applications so it can really advertise to the user all the amazing things it can do. In addition, applications that are digitally signed with a URL will be able to display that URL and allow users to easily navigate back to its home website and see what other apps and enhancements the company offers.

Using the new API set also significantly reduces the development cost for new applications. Almost all contentious applications monitor or check to see if they are not the default. Using the new API set this can be done in a single API call instead of crawling the registry like in previous versions of the OS.

Using the new API set also helps applications correctly function in the new world with User Account Control (UAC). UAC is implemented by taking an administrator and making her look like a standard user to the system. This means that an administrator cannot normally write to HKLM in Windows Vista and beyond. This is done so processes cannot act on the administrator's behalf without her knowledge. Installation will typically always be elevated because there is an experience for that, but for applications that want to be able to claim defaults post-install, they need to claim the defaults on the per-user level instead of the per-machine level. Switching to the new API set does this automatically. Applications that try to claim per-machine defaults post-install will fail.

The other strong reason for an application to rev to using Default Programs is to consistently achieve the desired results. File and protocol associations are derived from a hierarchical structure in the registry. Part of this structure dictates that per-user defaults will always be chosen over per-machine defaults. This means that if an application decided to build elevation points in their code to claim defaults by writing to HKLM like in XP, it would not always achieve the desired result. As soon as another similar application is installed and used default programs APIs that take per-user file and protocol associations, the previous application would no longer be the default because per-user defaults have a higher precedence.

Default Programs UI

Default Programs has several pieces of UI. These pictures are not final pictures of what this experience will look like by the time Windows Vista ships, but they are a general walk through in functionality and understanding.

Default Program UI flow:

Figure 2. (Click on the image for a larger picture)

Startmenu:

Figure 3. (Click the image for a larger picture)

Default Programs Control Panel Hub Page:

Figure 4. (Click the image for a larger picture)

Set a Default Program page:

Figure 5. (Click the image for a larger picture)

Only applications that have registered will show up in the list of applications. When an application registers a description value it will show up in the listbox on the right side. A description is required when registering.

Figure 6. (Click the image for a larger picture)

Restore defaults will reclaim all registered defaults for an application. Advanced will allow a user to choose specific defaults for an application.

Note   In order to show a URL in the UI an application must embed a URL in its digitally signed authenticode certificate. Applications that are not signed will not be able to show a URL.

Advanced

Figure 7. (Click the image for a larger picture)

This view shows everything that the application has registered for and what application currently owns the default. There is a Windows public API that allows apps to call this window so applications no longer need to maintain file association UI. We recommend using this UI instead of creating custom UI.

Default Programs Guidelines and Best Practices:

Install

Applications that install onto the operating system should keep installing the way they do in XP. In addition, an application will need to create their schema for default programs. Registering the new schema allows an application to take advantage of all the new functionality. Applications that just install like they did in XP will still function, but applications will need to register in order to take defaults post install. An application should do the following at install:

1. Install necessary binaries (Like XP).
2. Write program IDs to HKLM (Like XP).

   Note   Applications need to create application specific ProgIDs for their associations.

3. Claim machine level file associations (Like XP).
4. Write to new Default programs schema (New for Windows Vista).

Post Install

First Run Experiences:

Applications can choose to have a per-user first run experience. This is recommended. This is where an application should ask questions that refer to per-user choice. Applications should not have a per-machine first run. First run experiences should offer the user 2 main choices:

1. Accept default application settings (this should be the default behavior).
2. Customize settings.

Accept defaults should call the Program Defaults API that claims all registered defaults for an application. This changes the default file association from a per-machine setting to a per-user setting.

Customize settings should bring the user to the file association UI. Applications can programmatically call Windows file association UI for a specific application. This is the recommended approach.

Defaults UI:

Applications that choose to show Defaults UI should use the new Default Programs APIs to open an app centric version of file associations.

Example for Litware Media player:

Figure 8.

In this view, a user will see all the defaults a specific application has registered. A user will be able to see what an application owns, the current defaults, and change the default to the new application. On save, all updates will be committed and the window will be closed. On cancel, the window will be closed. This UI is provided so applications do not need to spend development resources for maintaining File association UI or worry about setting associations correctly.

Checking if an Application Is the Default:

Many applications like web browsers or e-mail clients have file and protocol associations that aren't commonly known to the user. Examples of these are things like HTTP:\ and Mailto:\. These applications typically do a check to see if they are the default when the application is invoked. Applications should check and see if they are the default through the new Default Programs API set. If the application is not the default, the application should present the user with UI that asks the user to:

1. Keep everything the way it is.
2. Make this application the default.

Applications should also include a checkbox that is defaulted to checked that says the equivalent of "Tell me when <application> is not the default anymore". Applications should NOT automatically claim defaults without asking the user. Applications should implement #1 by calling the Default Programs APIs to reclaim all of the application's registered defaults.

An example using Internet Explorer is:

Figure 9. (Click the image for a larger picture)

Registering with Default Programs

Default Programs functions by having each application explicitly register for what file associations and protocols they want to be considered for the default. This is done by registering the following schema in HKLM. Note that ApplicationDescription can be a string literal or a string resource reference. The latter allows MUI'ization.

HKLM\%APPLICATIONCAPABILITYPATH%
   ApplicationDescription = REG_EXPAND_SZ "@path\to\dll.dll,-resourceId"
   ApplicationName = REG_EXPAND "@path\to\dll.dll,-resourceId"
   \FileAssociations
   .file-extension = REG_SZ "file-extension-progid"
   \UrlAssociations
   url-scheme = REG_SZ "url-scheme-progid"
   \MIMEAssociations
      MIME = REG_SZ "mime-progrid"
   \Startmenu  REG_SZ            
   StartmenuInternet ="%app Name%"
          Mail ="%App Name%" 

Note   These are pointers to apps that have registered for canonicals in HKLM\software\clients. The value should be the name of the key under HKLM\software\clients\StartmenuInternet or HKLM\software\clients\Mail.

HKLM\Software\RegisteredApplications
   unique-app-name = REG_SZ "%APPLICATIONCAPABILITYPATH%"

Note   ApplicationDescription is required. However, ApplicationName is an optional entry that allows different type applications to point to the same .exe and show up as different names.

Note   In order to show a URL in the UI, an application must embed a URL in its digitally signed certificate. Applications that are not signed will not be able to show a URL.

An example using Contoso Web Browser:

Note   This should be a DLL to allow for localization.

HKLM\software\Contoso\WebBrowser\Capabilities
   Description =" The award-winning Web browser is better than ever. 
   Search the internet in second and find anything you want. Use 
   integrated tabs and new phishing detectors to enhance your internet experience."
\FileAssociations
  .htm = ContosoHTML
  .html = ContosoHTML
  .shtml = ContosoHTML
  .xht = ContosoHTML
  .xhtml = ContosoHTML
\UrlAssociations
  http = Contoso.Url.Http
  https = Contoso.Url.Https
  ftp = Contoso.Url.ftp
\Startmenu
  StartmenuInternet = "Contoso.exe"

HKLM\software\RegisteredApplications
  Contoso.WebBrowser.1.06 = software\Contoso\WebBrowser\Capabilities

ProgIds

Applications need to provide Applications specific ProgIds. This should have all the information that is typically written into the default key. Applications can do a one-to-one mapping of progid to protocol/extension or do one-to-many. It is completely arbitrary and both methods work equally. In the example above, ContosoHTML points to a single progid that has the shellexecute information for htm, html, shtml, xht, and xhtml. For the protocols, a specific progid is defined per protocol. This allows the execution string to be different per protocol.

When defining a ProgID for a MIME, the prog-id must contain the CLSID subkey with the class id for the corresponding application. This is used to do a lookup against the class id in the MIME database stored in HKLM.

Definitions of values

Capabilities—The registry subkey that all Default Programs information lives under for a specific application. The capabilities subkey is always under the applications registry keys.

Description—Default Programs is designed to allow users to make informed choices. We allow every application to register a description string so each application has a way to advertise its capabilities to the user. This value is a property under \capabilities.

Note   This is a required field. An application must provide an entry here to show up in the UI. Be sure to localize your strings.

ApplicationName—Specifies the name that will show up in the Default Programs UI. If this field is not filled out then default programs will use the name of the .exe associated to the first registered progid for the application. Application name should always match the RegisteredApplications name.

FileAssocations—The file associations subkey is where all the specific file associations the application wants to claim are put. Each file association is stored as a property of the FileAssocations Subkey. Each extension should point to an application specific progid and not a generic progid.

UrlAssocaitions—The URL associations subkey is where all the specific URL associations the application wants to claim are put. Each URL association is stored as a property of the UrlAssocations Subkey. Each protocol should point to an application specific progid and not a generic progid.

MIMEAssocaitions—The MIME associations subkey is where all the specific MIME associations the application wants to claim are put. Each mime association is stored as a property of the MIMEAssocations Subkey. The name should be the exact name of the MIME name stored in the MIME database and the value should be an application specific progid that has the corresponding CLSID in it.

Startmenu—The startmenu subkey is for internet and e-mail slots that are on the start menu. Applications that also register to be a contender for those spots can link that functionality into their Default programs entry. Providing a link to the start menu registration allows an application to show that it also wants the corresponding e-mail or internet link when displayed in default programs. If this information is provided and the user restores the default to this program then it will also take over the startmenu spot. The registration should just be the name of the registered key under HKLM\software\clients\StartMenuInternet or HKLM\software\clients\Mail. In the case of a mail client this also sets the default MAPI client.

Note   There is a separate start menu registration. For more information, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

HKLM\software\RegisteredApplications—RegisteredApplications is required so the OS can know where all of the information about each application is stored. This should be the name of the application.

Using Default Programs APIs

Once an application is registered, there are a number of APIs an application can take advantage of to allow for a better user experience. This interface should be in the June CTP. There is a slightly different interface in the Beta2 release that was changed due to customer feedback.

typedef [v1_enum] enum tagASSOCIATIONLEVEL
{
   AL_MACHINE,
   AL_EFFECTIVE,
   AL_USER
} ASSOCIATIONLEVEL;

typedef [v1_enum] enum tagASSOCIATIONTYPE
{
   AT_FILEEXTENSION,
   AT_URLPROTOCOL,
   AT_STARTMENUCLIENT,
   AT_MIMETYPE
} ASSOCIATIONTYPE;

[
   object,
   uuid(4e530b0a-e611-4c77-a3ac-9031d022281b),
   pointer_default(unique),
   helpstring("Application File Extension and URL Protocol Registration")
]

interface IApplicationAssociationRegistration : IUnknown
{
   HRESULT QueryCurrentDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [out, string] LPWSTR* ppszAssociation);

   HRESULT QueryAppIsDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT QueryAppIsDefaultAll(
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT SetAppAsDefault(
      [in, string] LPCWSTR pszAppRegistryName,
      [in, string] LPCWSTR pszSet,
      [in] ASSOCIATIONTYPE atSetType);

   HRESULT SetAppAsDefaultAll(
      [in, string] LPCWSTR pszAppRegistryName);

   HRESULT ClearUserAssociations();
}
   
interface IApplicationAssociationRegistrationUI : IUnknown
{
   HRESULT LaunchAdvancedAssociationUI([in, string] LPCWSTR pszAppRegName);
}

AssociationLevel

AL_MACHINE—returns the machine default for an extension.

AL_EFFECTIVE—returns the effective default for the current user.

Note   This is what most applications should use.

AL_USER—returns the per user default. If no per user default, it returns failure code 0x80070483.

AssociationType

AT_FILEEXTENSION—use to query for a file extension like .htm or .mp3

AT_URLPROTOCOL—use to query for a protocol like http:// or mailto:

AT_STARTMENUCLIENT—use to query for the owner of the startmenu client for the mail or internet link.

AT_MIMETYPE—use to query for the MIME type like audio/mp3.

QueryCurrentDefault

Pass in the string of the extension (.mp3, HTTP, etc), type of extension it is, association level and it will return the ProgID for the current default. Typically, applications should use the AL_EFFECTIVE association level since that will determine the effective default for the user. The caller must CoTaskMemFree the returned progid string.

QueryAppIsDefault

Pass in the string of the extension (.mp3, HTTP, etc), type of extension it is, association level, and the registered application name and it will return a BOOL based on whether the application owns the default. Typically, applications should use the AL_EFFECTIVE association level since that will determine the effective default for the user.

QueryAppIsDefaultAll

Pass in the association level, and the registered application name, and it will return a BOOL based on whether the application owns all its registered defaults. Typically, applications should use the AL_EFFECTIVE association level since that will determine the effective default for the user.

SetAppAsDefault

Pass in the name of the registered app, the extension (.mp3, HTTP, etc), and the type of extension it is. The default will be set to the registered app.

SetAppAsDefaultAll

Pass in the name of the registered app and it will set all the defaults registered to the application.

ClearUserAssociations

Deletes all per-user associations for the current user, returning that user to whatever per-machine defaults exist. There does not currently exist a defined partner or 3rd party scenario where we would expect anyone to call this. But if they wanted to, they should be able to.

LaunchAdvancedAssociationUI

The specified app registration name must match one of the values registered under HKLM\Software\RegisteredApplications. This launches the Set Program Associations page for the specified app. This is intended for use by applications who want to provide a UX direct link to their advanced associations' configuration.

Note   This API set is only available for Windows Vista and beyond. Applications supporting downlevel OSs (Windows XP, Windows 2000, and Windows 98) should use their pre-existing defaults code on those OSs by using a SKU check to differentiate between pre-Windows Vista and post-Windows Vista OSs.

Code Examples

Using the registration for the Contoso Web browser, following is how it would implement using the API set.

Querying if Contoso Web Browser owns all of its defaults:

HRESULT CheckContosoHasAllDefaults(__out BOOL* pfHasAllDefaults)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                 (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefaultAll(AL_EFFECTIVE,
                                        L"Contoso.WebBrowser.1.06",
                                        pfHasAllDefaults);

        pAAR->Release();
    }

    return hr;
}

Querying if Contoso Web Browser owns the default for .htm:

HRESULT CheckContosoHasDotHTM(__out BOOL* pfHasDotHTM)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefault(L".htm",
                                     AT_FILEEXTENSION,
                                     AL_EFFECTIVE,
                                     L"Contoso.WebBrowser.1.06",
                                     pfHasDotHTM);
        pAAR->Release();
    }
    return hr;
}

Setting Contoso Web Browser as the default for .HTM:

HRESULT SetContosoAsDefaultForDotHTM()
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->SetAppAsDefault(L"Contoso.WebBrowser.1.06",
                                   L".htm",
                                   AT_FILEEXTENSION);

        pAAR->Release();
    }

    return hr;
}

File Association Documentation

For more information about Creating a File Association, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fileassoc.asp

For more information about Registering Programs with Client Types, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

For more information about Verbs and File Associations, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp

For more information about File Types, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_file_types.asp

Program Compatibility Assistant (PCA) in Windows Vista

Introduction to PCA

The Program Compatibility Wizard in Help and Support and the Compatibility tab in file properties are useful tools for users to fix program compatibility issues in Windows XP. The major limitation with these tools is the discoverability and the fact that the user needs to know when to use these tools. The Program Compatibility Assistant (PCA) is a new feature in Windows Vista that can make older programs that have compatibility problems work better, in an automated manner. PCA monitors programs for known issues. If an issue is detected, it notifies the user of the problem and offers to apply solutions that will be effective before the user runs the program the next time.

Note   PCA is a client-only feature and is not available on the Server.

The following sections describe the scenarios in which the user is expected to encounter PCA, details on the user experience, the solutions applied in each of those scenarios and how to manage the settings made by PCA at a later time. The last section talks about how to exclude programs from PCA.

PCA Scenarios

Detecting Failures in Setup Programs

One of the main scenarios for PCA is to detect setup programs failing to install on Windows Vista and to provide the solution of applying the Windows XP compatibility mode.

The most common setup failure is due to installers hard coding the check for the Windows OS version that they can run on. These installers will typical fail with an error message saying that the current version of Windows is not supported and terminate.

Below is an example of such error message, illustrated by a test program.

Figure 10.

To give more details on this, programs commonly use GetVersion or the GetVersionEx APIs to get information on the Windows OS version that they are running on. In Windows Vista these APIs will return 6 as the major version. If the program is hard coded to look for the XP version, which is major version 5, then it will fail in Windows Vista. The XPVersionLie fix included in the Windows XP compatibility mode will provide the XP version of the OS to the program, when it calls GetVersion or GetVersionEx APIs.

PCA targets to detect this scenario and will display a user interface similar to the one below after the installer is terminated. This scenario also covers uninstallers and a similar dialog will show be shown.

Figure 11.

When the user selects the option to Reinstall using recommended settings, the WINXPS2 compatibility mode will be applied to the installer program and the installer will be automatically restarted.

More details on what happens under the covers are explained through the Question / Answer below:

1. What is the detection logic and how does PCA know that the setup failed due to version problems?

   PCA does not specifically look for the setup's failing due to version problems. The logic used by PCA is to detect if a setup did not complete successfully. It monitors a program detected as setup by Windows Vista and checks if the program registers an entry in Add or Remove Programs (ARP). If no entries are created in ARP then PCA concludes that the installer did not complete successfully. It will then wait for the install program to terminate before displaying the UI. If it is an uninstaller then the detection looks for whether an entry is deleted from ARP.

2. How does PCA get information about the setup programs?

   PCA relies on the User Access Control (UAC) feature in Windows Vista to know if a program is setup. UAC includes detection for setup programs and will make sure the detected setup programs will be run as administrator. This includes getting administrative credentials or confirmation from the user before launching the program.

3. What does each option in the PCA dialog for setups do?
   1. Reinstall using recommended settings

      This will apply the Windows XP compatibility mode and restart the program. Refer to the section below on managing PCA settings to get more details on how the compatibility mode is applied.

   2. The program installed correctly

      It is possible that in some cases, PCA might come up for a setup program that completed correctly but did not create an entry in ARP. In those cases, users can use this option to suppress the PCA dialog the next time.

   3. Cancel

      PCA will do nothing.

All these options will result in the PCA dialog to disappear. PCA will not show up again for the same setup program except when the user selected the 'cancel' option on the previous PCA dialog.

Detecting program failures under UAC

The second main scenario category for PCA is to detect program failures while running under User Access Control (UAC). PCA detects 3 different types of program failures under UAC, which are described below.

Detecting program failures while trying to launch installers

PCA detects this particular scenario of a program not running as administrator and is experiencing a failure while launching a child exe, because the child program is required to run as administrator. This will typically be the case for programs trying to launch an updater.exe. This is because Windows Vista returns a new error code to programs trying to launch an executable which is detected to run as administrator. If the same updater.exe is run from explorer it will run as administrator since explorer knows how to handle this error code and launch the UAC consent UI asking for administrator credentials or approval and finally run the program as administrator.

Below is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Figure 12.

Here the test program was trying to launch an updater which is required to run as administrator and failed. In this case, PCA will apply the ELEVATECREATEPROCESS compatibility mode, which will enable the program to successfully launch the child exe as administrator the next time. Now when the program is run the next time and while trying to launch the updater, it will not fail and will successfully run as administrator. The user will see the UAC consent UI.

More details on what happens under the covers is explained through Q/A below.

1. What is the detection logic and how does PCA know that the program failed to launch a child exe which needs to run as administrator?

   The detection for this scenario is accomplished through instrumentation at the CreateProcess API to detect the cases when a child process launch fails due to the requirement to run as administrator.

2. Why are there no options in this PCA dialog?

   Due to the high confidence on the issue detection in this scenario, the solution (ELEVATECREATEPROCESS compatibility mode) is automatically applied and the user is not given any options.

Detecting installers that need to be run as administrator

One of the tenants of Windows is that the installation of most software requires administrative privileges. This is because installed applications are loaded into system directories and manipulate system resources. Install detection feature part of the overall User Access Control (UAC) feature in Windows Vista aids in this by identifying setup programs and automatically prompting the user for administrator approval or credentials. In some cases it is possible that an install program may not be detected by UAC. These are typically custom made installers which are not built using any standard installer technologies like Install Shield, Microsoft Windows Installer, etc.

PCA targets to detect this scenario and will display a user interface similar to the one below after the installer is terminated.

Figure 13.

When the user selects the option to 'Restart the program as administrator', the program will be marked to run as administrator and will be automatically restarted.

More details on what happens under the covers are explained through the Question / Answer below:

1. What is the detection logic and how does PCA know that the program needs to run as administrator?

   The logic used by PCA is to detect if the program tried to create a sub folder under the Program Files directory and subsequently tried to copy an .exe or .dll file inside it. PCA assumes these as the common actions performed by an installer. PCA relies on events from the File virtualization feature as part of the overall User Access Control (UAC) feature for detecting this. When a program is not running administrator, writing to the Program Files directory is not permitted as it is one of the system locations. File Virtualization tries to address this by redirecting the writes attempted on a system location to a Virtual store. For example, it supports redirecting a directory creation in the virtual location and writing document files but does not support redirecting binary files like .DLLs or .EXEs. In either case, File Virtualization sends events that can be consumed by PCA.

2. What does each option in the PCA dialog for this scenario do?
   1. Restart the program as an administrator

      This will apply the 'RunAsAdmin' compatibility mode and restart the program. Refer to the section below on managing PCA settings to get more details on how the compatibility mode is applied.

   2. The program installed correctly

      It is possible that in some cases, PCA might come up for a setup program that completed correctly. In those cases, users can use this option to suppress the PCA dialog the next time.

   3. Cancel

      PCA will do nothing.

PCA will not show up again for the same program except when the user selected the 'cancel' option on the previous PCA dialog.

Detecting legacy control panels that may need to run as administrator

The last UAC related scenario addressed by PCA is to detect control panel items that need to be run as administrator. After a legacy control panel item is run once, a PCA dialog similar to the one below will show up.

Figure 14.

More details on what happens under the covers are explained through the Question / Answer below:

1. What is the detection logic and how does PCA know that the control panel item needs to run as administrator?

   There is no specific issue detection logic used in this scenario and this dialog will show up after a legacy control panel item is completed running. The target is to provide the user with an option to run the control panel item as administrator, which is the most commonly needed solution for a control panel that may not work properly under UAC. This dialog will not show up for control panels tested to work under UAC and manifested with the proper RunLevel marking for UAC (marked to run either as administrator or As Invoker) set. For more information about UAC and how to create this UAC manifest, see Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.

2. What does each option in the PCA dialog for this scenario do?
   1. Open the control panel using recommended settings

      This will apply the 'RunAsAdmin' compatibility mode and restart the control panel item as administrator. Refer to the section below on managing PCA settings to get more details on how the compatibility mode is applied.

   2. The control panel works correctly

      In cases where the control panel item works correctly, users can use this option to suppress the PCA dialog the next time.

   3. Cancel

      PCA will do nothing.

All these options will result in the PCA dialog to disappear. PCA will not show up again for the same control panel item except when the user selected the Cancel option on the previous PCA dialog.

Detecting program failures due to deprecated Windows components

This PCA scenario targets to mitigate the impact on programs due to deprecated (removed) components in Windows Vista. PCA detects programs that are trying to access a DLL or a COM object removed in Windows Vista. If a program is detected to access a known DLL/COM object, PCA will show up an UI at the program termination to inform the user about the same and provide options to check online for a solution.

Below is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Figure 15.

Here the test program was trying to use the COM objects associated with the DHTML editing control, which is removed from Windows Vista.

More details on what happens under the covers is explained through Q/A below.

1. What is the detection logic and how does PCA know that the program failed to launch a child exe which needs to run as administrator?

   The detection for this scenario is accomplished through instrumentation at the CoCreateInstance API and the Loader (NTDLL) to detect load failures on COM objects and DLLs respectively. When there is a failure due to an object or file not found then it will be checked against a known list of DLLs and COM objects. If a match is found then PCA will trigger after the program termination.

2. What happens when Check for solutions online option is selected?

   Check for solutions online sends a Windows Error Report to get an online response from Microsoft. The responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically the response will point the user to a Knowledge Base (KB) article that talks about alternates to the deprecated component and in some cases provides a link to download the deprecated component from online.

Detecting unsigned drivers on 64 bit platform

This is a scenario where PCA is trying to protect the system stability due to programs or devices using unsigned drivers on 64 bit platforms. Windows Vista does not support unsigned drivers on the 64 bit platform and enforces a policy that all drivers should be signed. If an unsigned driver is installed into the system with a 64 bit platform it will not be loaded. After the user reboots the machine, the system will not start if it a boot time driver. The device or program trying to use the driver may experience failures which may also result in a system crash. In order to prevent this, PCA monitors installation of unsigned drivers and whenever PCA detects installation of an unsigned driver it will notify the user as shown below.

Figure 16.

If it is a boot time driver it will disable the driver so that the system will be able to boot.

The detection for this scenario is accomplished by PCA monitoring changes to the KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key for addition of new drivers into system first. Then, based on the location of driver from the registry, each new driver installed will be checked for a valid digital signature. If the driver is found not to have a valid signature, PCA dialog will show up. Unlike the other PCA scenarios this message is not related to specific applications and is related to the driver irrespective of how it was installed.

Inform Users About Compatibility Issues with Known Programs at Startup

Apart from the runtime issue detection scenarios listed above, PCA also includes a scenario to come up at program startup for the list of programs known to have compatibility issues. The list will be stored in the System application compatibility database. This scenario existed from Windows XP and these messages are known as the Application Help (shortly apphelp) messages. This is the only PCA scenario that is also available on Server.

There are two types of apphelp messages. If the program is known to be incompatible and if allowing the program may result in severe impact to the system (for example, a stop error or unable to boot after the install, etc.) then a blocking message as shown below will be displayed.

Note   Microsoft gets approval from the ISVs for programs being blocked.

Figure 17.

The other type of message is a non blocking message similar to the one below. This will be used in the case of programs that have known compatibility issues but the impact is not severe to the system.

Figure 18.

In both cases, Check for solutions online sends a Windows Error Report to get an online response from Microsoft. The responses will be displayed in the client Solutions to Problems (wercon.exe) UI. Typically the responses will be of 3 types:

• Pointing the user to an update from the ISV for that program.
• Pointing the user to an ISV Web site for more information.
• Pointing the user to a Microsoft Knowledge Base article for more information.

Managing Settings Made by PCA

The compatibility modes will be applied to programs by setting a registry key under
Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
with key name = "full path of the exe" and string value = "name of the compatibility mode being applied".

The registry key will be set under HKEY_LOCAL_MACHINE to apply the solutions to be effective for all users except for the scenario where the ELEVATECREATEPROCESS compatibility mode is applied automatically before the PCA dialog shows up. In that scenario, the registry key will be set under HKEY_CURRENT_USER and the solution will be effective only for the current user.

Apart for this key, PCA stores the list of all programs for which it came up under the follow key for each user even if no compatibility modes where applied (e.g., in the case user reported that the program worked correctly).

HKEY_CURRENT_USER\Software\Microsoft\Windows NT
\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted

Excluding Programs from PCA

PCA is intended to detect issues with older programs and not intended to monitor programs developed for Windows Vista. The best option to exclude a program from PCA is to include, with the program, an application manifest with run level (either admin or as limited users) marking for UAC. This means the program is tested to work under UAC (and Windows Vista), and PCA checks for this manifest and will exclude the program. This applies for both installer and regular programs. For more information about UAC and how to create this UAC manifest, see Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.

Another option to exclude apps from PCA is to add the list of .exes with full path under the following registry key:
HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows NT\CurrentVersion\Compatibility Assistant
The value name is ExecutablesToExclude, which is type REG_MULTI_SZ.

Apart from this, PCA automatically excludes programs running from network locations and programs containing fixes applied to them in the application compatibility databases.

A group policy setting is provided to disable PCA for all programs if required. The name of the policy is Turn Off Program Compatibility Assistant and can be found under Administrative Templates -> Windows Components -> Application Compatibility in the group policy editor (gpedit.msc).

There are also individual policies to turn off specific scenarios. These policies are available under Administrative Templates -> System -> Troubleshooting and Diagnostics -> Application Compatibility Diagnostics in the group policy editor (gpedit.msc).

Event logging

After the user has acted on PCA an event will be logged in the event log. The events can be found under Application and Services Logs -> Microsoft -> Windows -> Program Compatibility Assistant -> Operational in the Event viewer. The event log includes the following information: Application name, Application version, Executable path, Scenario ID, User action, and names of the compatibility modes applied (if any). The values of the scenario ID are as follows:

Scenario ID	Description
1	Detecting failures in setup programs (installer)
10	Detecting failures in setup programs (uninstaller)
3	Detecting program failures while trying to launch installers
8	Detecting installers that need to be run as administrator
9	Detecting legacy control panels that may need to run as administrator
5	Detecting program failures due to deprecated Windows components
11	Detecting unsigned drivers on 64 bit platform

Managing Apphelp Messages

An IT Professional in an enterprise can use the Compatibility Administrator tool to disable the apphelp entries present in the System application compatibility database or add custom databases that contain apphelp messages for programs in their enterprise.

The Compatibility Administrator tool ships as part of the Application Compatibility Toolkit. For more information about the Toolkit, see Application Compatibility Tools.

Graphical Device Interface (GDI)

Painting (WM_PAINT) Behavior Differences

Feature Impact

Low

Brief Description

As part of the Desktop Window Manager work, Microsoft has made subtle but important changes to the way applications paint to the screen. Prior to Windows Vista, an hwnd was painted directly to the screen, which had certain benefits but really limited how Windows could display and manage top-level windows. In Windows Vista, all top-level windows are rendered to an off-screen bitmap (similar to WS_EX_LAYERED), and the Desktop Window Manager combines the images together to draw the desktop.

Manifestation

Black areas around tool tips, pop-up menus, balloons, splash screens, etc.

This can happen when the application has not painted the entire hwnd, usually because that application assumed that the pixels in the background windows are good enough. This is an area Microsoft is actively working on, so don't overly optimize based on current bits but please give us the feedback.

Flashes of black

A related issue happens when applications do painting that's not part of a WM_PAINT. USER detects the application is drawing and redraws the desktop, but the application may not have finished drawing the hwnd when that happens, and the result is the backing bitmap contains uninitialized pixels (black). Again, Microsoft is actively working in this area so please send in your feedback on where you think improvement is needed.

Glass disabled for application

This can happen when an application draws to the non-client area of the window (the title bar).

Rubber bands, custom shadows, and other special effects

These are often done using GetDC(NULL); however, reading and writing to GetDC(NULL) tends to be problematic when applications are backed by a bitmap rather than drawing straight to the screen. Reading and writing to the screen is significantly slower than Windows XP. Also, not all GDI rasterops are supported (but we do support XOR).

Improved Far East fonts

Windows Vista has made numerous changes to the Chinese, Japanese and Korean fonts to make them more readable; one of the side effects is that text can layout slightly differently in these new fonts as characters may have different widths. Consider testing how your text lays out on the screen and on the printer. Also consider testing places where Far East languages can be mixed with Latin character sets (for example, English).

Rendering Performance

Feature Impact

Low

Brief Description

Most applications will run as fast or faster on Windows Vista, but there are some changes that may require monitoring.

Manifestation

Overall GDI drawing performance is slower?

GDI primitives like LineTo and Rectangle are now rendered in software rather than video hardware, which greatly simplify the display drivers. We don't think this will impact many real-world applications, but would like your feedback if it does.

Slower text rendering?

Calls such as DrawText better support international and East Asian languages, we don't think this will impact real world applications but want your feedback if it does.

Reduced application address space?

The bitmap for a top-level window is stored in the application's address space (see section on painting), potentially reducing available address space by a few megabytes.

Reading from and writing to GetDC(NULL)?

This operation is slower than previous versions of Windows because applications now render to an offscreen bitmap rather than directly to the screen. Where possible, consider drawing to an HDC backed by your HWND, or creating overlay windows. GetDC(NULL) is still the preferred way to get a screen snapshot.

UIPI (GUI Portion of User Account Control)

Feature Impact

Low

Brief Description

As an added layer of defense against malicious software, Windows Vista allows different UI applications to run with three different levels of UI privilege. Applications can freely interact with other applications of the same and lower permission, but can't modify or talk to applications of higher permission. Most applications will run with the middle permission, while applications that require administrator privileges run in a higher mode, and restricted processes such as low rights Internet Explorer use the lowest privilege mode.

More specifically, applications in lower privilege modes cannot generally send messages to higher privileged applications unless the higher privileged application explicitly allows that message by calling ChangeWindowMessageFilter(). Similarly, lower privileged applications can read but cannot modify an HWND owned by higher privileged applications. For compatibility reasons, SendMessage and other APIs will return success even if the API was blocked because of privilege issues. Similarly, where compatibility impact is high and security risk is low sometimes low-privileged applications are allowed to send unsolicited messages to high privileged applications.

Manifestation

Applications that interact with other applications stop doing so.

Utilities that reposition windows, type keystrokes for you, add extra buttons to windows, etc.

Cut and paste between different applications fails.

Does it work at all, and does it support all the different clipboard formats you expect (rich text, HTML, etc.)?

Remedies

Journaling hooks

WH_JOURNALPLAYBACK and WH_JOURNALRECORD are inherently cross-process, so require the highest privilege level. The SendInput() API, which doesn't require full UI privilege for many cases, can often be used instead of journaling hooks.

For programs you have the source code to, consider reviewing any code that uses the following APIs, as they often indicate cross-process stuff:

SendInput

RegisterWindowMessage

BroadcastSystemMessageEx

BroadcastSystemMessage

SetWindowsHook

SetWindowsHookEx

CallNextHookEx

CallNextHook

SetWinEventHook

AttachThreadInput

FindWindowEx

FindWindow

CreateDesktop

CreateDesktopEx

OpenDesktop

OpenInputDesktop

EnumDesktops

EnumDesktopWindows

SwitchDesktop

SetThreadDesktop

GetThreadDesktop

CloseDesktop

CreateWindowStation

OpenWindowStation

EnumWindowStations

CloseWindowStation

GetProcessWindowStation

That's not an exhaustive list, nor is it a guarantee of anything that needs to change, but it's a good balance of finding issues versus minimizing false positives. You can search source files with findstr /s /g:temp.txt *.c *.cpp *.h *.hpp where temp.txt is the above list of APIs copied to a text file.

High DPI Scaling

Feature Impact

Low

Brief Description

On systems using the high DPI setting, applications that don't natively understand high DPI will be automatically scaled up.

Manifestation

Pixel sizes have been roughly constant for a long time, but LCD manufacturers are increasingly coming out with monitors with smaller and smaller pixels, also known as high dots per inch (DPI). If an application uses the same number of pixels on a high DPI screen as it does on a standard 96 DPI screen, the application will look really small. Windows Vista introduces the ability to scale applications that were written for 96 DPI screens, which it does by rendering the application's bitmap at a larger size. Like all bitmap scaling, this can result in some blurriness, but otherwise gives a correctly sized and properly rendered image. Applications can also decide to support high dpi natively, which will give the crispest possible look. Currently an application can turn off scaling & declare itself DPI-aware by calling SetProcessDPIAware(). A manifest-based way to declare this is under investigation. For more information about writing applications that natively support high DPI, see http://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp.

The rest of this section talks about potential problems with non-DPI aware applications. Applications ask Windows questions like "how many pixels wide is a scrollbar", so when a 96 DPI application asks, Windows Vista gives the application the 96 DPI answer. There are, however cases where Windows doesn't provide an answer based on the application, usually because Windows Vista doesn't yet have enough information (please give us this feedback), and sometimes because the "right" answer depends on what the application is trying to do with the answer. (Screen coordinates often raise this problem.)

Most compatibility problems come from these imperfect conditions. Things to look for when testing:

• Text is clipped (partially hidden).
• Text is too big.
• Something is drawn at the wrong size or in the wrong place.

Remedies

For more information about writing applications that natively support high DPI, see http://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp.

PNG Icons

Feature Impact

Low

Brief Description

The icon file format (*.ico) now supports PNG images in addition to the older BMP-style icons; many Windows Vista icons use the PNG variant.

Manifestation

Applications that view or edit icon files may not understand the new format.

Links

https://blogs.msdn.com/nickkramer/archive/2006/04/24/582365.aspx. (This information is an addendum to the article you are reading.)

Named Pipe Hardening

Brief Description

In Windows Vista, many services are running under lesser privileged accounts like NetworkService (NS) or LocalService (LS) rather than Local System. Service hardening is an initiative to improve the compartmentalization between the services such that if one service is compromised, it cannot easily attack other services on the system. Windows Vista hardens the named pipes used by RPC servers to prevent other processes from being able to hijack them.

Under Windows XP, an RPC server creates a named pipe and the ACL on the pipe grants LocalService or NetworkService Full Control. This includes the ability to create "server instances" of the pipe, so clients can connect. The only process that should create instances of a pipe is the process that initially created the pipe. Microsoft's ACL change restricts the ability to create server instances to the process that created the pipe initially.

Manifestation

The following services have been affected: services that run as LocalService or NetworkService, services that opt-in to using service Sids, and services using RPC over named pipes that request the "default" named pipe security descriptor.

Services that opt-in to using service Sids means no 3rd-party service will be affected by default. Service Sids is a new feature in Windows Vista that you have to opt-in by setting a DWORD in your service configuration. When developers opt-in they have the opportunity to test with the new service hardening behavior. This change would be one of those behaviors.

Services using RPC over named pipes that request the "default" named pipe security descriptor means that if some RPC server is specifying a custom security descriptor because of special needs, they will see no change. Below is a list of the affected Pipes:

Epmapper

Eventlog

Dav rpc

Keysvc

Winreg

Tapserv

W32time_alt

Termsvcapi

Ctx_winsta

Hydralspipe

SPAP Deprecation (Pstore)

Brief Description

Protected Storage (PStore), which provides applications with an interface to store user data that must be kept secure or free from modification, has been changed to read-only in Windows Vista. This means that any application that tries to create new PStore data items will fail.

Remedies

Use DPAPI for future PStore procedures.

For more information about the existing PStore items and use of DPAPI to manage them, see http://msdn.microsoft.com/library/en-us/dnsecure/html/windataprotection-dpapi.asp?frame=true

WMI Providers: Default Security Hosting Model

Brief Description

The Default HostingModel for WMI providers has changed from LocalSystem to NetworkServiceHost.

In previous releases of Windows (Pre-Windows Vista Beta 2), if the HostingModel of a WMI provider (Win32Provider.HostingModel property) is unspecified, it was defaulted to LocalSystem. Because LocalSystem is a highly privileged account, the WMI provider running in this security context exposes the Operating System to a risk of elevation of privileges depending on the provider code quality and testing.

For most cases, LocalSystem is unnecessary and the NetworkServiceHost context is more appropriate. This is especially true because most WMI Providers must impersonate (ImpersonationLevel=1) the client security context to perform the requested operations on behalf of the WMI client.

Manifestation

If a WMI provider lacks a definition for hosting model and executes as if it is running under the LocalSystem level, it will not run properly.

Remedies

The expected hosting model must be changed to ensure that the WMI provider code performs the operations in the client security context by impersonating the WMI client. Cases that require the LocalSystem security context are extremely rare. However, if LocalSystem is an absolute requirement, specify the hosting model explicitly with the HostingModel=LocalSystemHost statement in the provider MOF file.

Links

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/provider_hosting_and_security.asp

Volume Shadow Copy Service

Brief Description

The Volume Shadow Copy Service (VSS) is a new service that was introduced in Windows XP and Windows Server 2003. It is a framework facilitating communication between applications, storage subsystems, and storage management applications (including backup applications). This service defines, persists and exploits point-in-time copies of storage data.

Manifestation

Compatibility with XP backup applications

Several interfaces have changed since XP and the libraries are not compatible with Windows Vista. At a minimum, the application will need to be recompiled using either headers or libraries from VSS SDK 7.2 or from the Platform SDK released with Windows Vista Beta 2.

Compatibility with 2K3 SP 1 backup applications

Binaries from 2K3 SP1 are compatible with Windows Vista. Most backup applications would also need to account for the changes in the inbox writers, file and registry virtualization, WRP as well as the use of hard links in %windir%system32 which makes it unlikely that a backup application from WS 2K3 SP1 would work as is.

Compiling backup applications for Windows Vista

Applications that use interfaces available in Server 2003 can be compiled using the headers and libs provided in VSS SDK 7.2. To use new interfaces specific to Windows Vista, recompile using the VSS headers and libs included in the Platform SDK for Windows Vista. The first release of the SDK containing VSS components will be with Beta 2.

VSS writers in Windows Vista

Registry Writer

The Registry Writer now performs in place backups and restores of the Registry as compared to the spit writer scheme earlier. User hives are not reported by the Registry Writer.

COM+ RegDB Writer

This backs up the contents of %systemroot%\registration. COM+ depends on a registry key being backed up and hence needs to be backed up and restored with the registry.

MS Search Writer

This deletes the search index from shadow copies after creation.

MSDE Writer

This is the default writer for SQL 2000 and SQL 2005 databases.

WMI Writer

WMI VSS writer is used for backing up WMI specific states and data during backup operations. The data includes files from the WBEM Repository and requires Registry Backup.

Background Intelligent Transfer Service (BITS) Writer

This uses the FilesNotToBackup reg key to exclude files from the directory %allusersprofile%\application\data\microsoft\network\downloader.

Automated System Recovery (ASR) Writer

The ASR Writer stores the configuration of the disks on the system.

System Writer

On Windows Vista the System Writer will generate a list of files using the following formula:

1. All static files that have been installed. These are identified by the attribute writeabletype = "static " or writeabletype is "" in the component manifest. This will include all WRP files. Additionally, there may be some files marked as static that are not WRP. For example, games are static but not WRP so that admins can change parental controls.
2. The WinSxS folder which includes all manifests, optional components, and 3rd party Win32 files.
3. All PnP Files for installed drivers (owned by PnP).
4. All User Mode Services and non PNP drivers.
5. All Catalogs owned by CryptSvc.

The files in %windir%\system32 are hard links to the winsxs directory.

The restore app is responsible for laying down files and registry and setting ACLs to match the system snapshot. The appropriate hard links must also be created.

Microsoft Optimization Writer

This writer deletes certain files from the snapshots. The file deletions minimize Copy On Write (COW) I/O during the snapshot maintenance phase and the files are typically temporary files or those that do not constitute user or system state.

Links

http://search.msdn.microsoft.com/search/default.aspx?siteId=0&tab=0&query=Volume+Shadow+Copy+Service

http://search.msdn.microsoft.com/search/default.aspx?__VIEWSTATE=&query=Volume+Shadow+Copy+Service+Vista&siteid=0&tab=0

Standard User Analyzer

The "Standard User Analyzer" (previously known as the "LUA Analyzer") is a tool to help independent software vendors (ISVs), IT professionals, and users diagnose possible issues in an application when it is running as a standard user. The Standard User Analyzer is based upon the "LUA Predictor" technology, which is part of the Microsoft Application Verifier.

Installation Prerequisites and Compatibility

Operating systems: Windows Vista, Windows XP, and Windows Server 2003.

Note   Currently, only a 32-bit version of the Standard User Analyzer is available.

Installation prerequisites: The Application Verifier must be installed before the Standard User Analyzer installation is launched. The Application Verifier is a free download on the Microsoft Web site.

Installation

To install the Standard User Analyzer, run the SUAnalyzer.msi file. All Standard User Analyzer files are installed to the "Program Files\Standard User Analyzer" folder.

Note   The Standard User Analyzer requires you to install latest Application Verifier.

Use the Standard User Analyzer to diagnose standard user compatibility issues within an application.

Note   The Standard User Analyzer should be run on a Windows Vista computer to properly identify an application's standard user compatibility issues. The following procedure is written to be performed by a standard user on a Windows Vista computer.

1. Click Start, point to All Programs, and then double-click Standard User Analyzer.
2. On the App Info tab, in the Target Application field, enter the directory location of the target application's executable file or use the Browse function.
3. On the App Info tab, in the Parameters field, enter parameters for the application, if applicable.
4. On the App Info tab, select the Launch Elevated check box, and then click the Launch button.
5. If a User Account Control credential prompt appears for SUAnalyzerSrv.exe, provide administrator credentials, and click Submit.
6. In the User Account Control credential prompt for the target application, provide administrator credentials and click Submit.

Note   The SUAnalyzerSrv.exe process may request elevation while performing this procedure. This process is a backend process that is responsible for managing tasks that require an administrator access token, such as changing settings in the Application Verifier.

During the test, the Standard User Analyzer will launch the application, monitor its actions, and wait for the application to be closed. The Standard User Analyzer will then generate and parse a log for the application, which might take some time to complete. Once the log has been generated and parsed, click on individual tabs to view specific issues found by Standard User Analyzer.

Interpret the Standard User Analyzer Test Data

Tab	Details
File	Lists file system access issues. For example, an application attempting to write to a file that normally only administrators can access.
Registry	Lists system registry access issues. For example, an application attempting to write to a registry key under HKLM, which is a location that normally only administrators can access.
INI	Lists WriteProfile APIs issues. WriteProfile APIs were originally used for 16-bit Windows but are still popular in some modern applications. For example, the Calculator in Windows XP. If the view is changed from "Standard" to "Scientific", calc.exe calls the WriteProfile API to write into windows\win.ini, which is only writable by administrator users.
Token	Lists access token checking issues. If an application explicitly checks for the "Builtin\Administrators" security identifier (SID) in a user's access token, the application most likely will not work for a standard user.
Privilege	Lists privilege issues. For example, if an application explicitly enables "SeDebugPrivilege", it will not work for a standard user.
Name Space	Lists issues that are caused when an application creates system objects (e.g. events, memory mappings) in restricted namespace. Applications that have this error will not work for a standard user.
Other Objects	Lists issues related to accessing objects other than files and registry keys.

When you click on an issue in any individual tab, the lower left panel of Standard User Analyzer will display all related records from the log file. You can then click on any record, and the lower right panel will display the detailed information for that record, including a formatted message, parameters, and the stack trace. ISVs can use stack trace data to track down the problem in the application's source code.

Standard User Analyzer Main Menu

File menu

Open Log File: load a saved log file.

Export Log File: save current log file.

View Raw Log File: open the current log file in raw xml format. (Warning: if the file is big, it will take a long time to open.)

Exit: exit the program.

View menu

Choose what kinds of messages you want to display. Usually it is necessary only to view "error messages".

Options Menu

Filter Noise: Toggle between display/hide entries that are "noisy".

Load Noise Filter File: Load a noise filter file.

Export Noise Filter File: Save a noise filter file.

Only Display Records with Application Name in StackTrace: This will reduce the noise; however, since the Standard User Analyzer captures only the first 32 stack frames, enabling this option might filter out real issues if a call stack is deeper than 32 frames.

Logging: Logging options. It is recommended that you leave the "Log Information" checkbox unselected in order to keep the log file from getting too large.

Help Engine Support

Compatibility Risks

Deprecated Components

The following components from earlier Windows releases will not be present in Windows Vista:

Windows Help for 32-bit applications (WinHlp32.exe) is being deprecated for Windows Vista. Windows Help is not supported in Beta 2 and some of the Windows Help code has been removed for the release. To view 32-bit Help files with the .HLP file name extension in Windows Vista, you will need to download and install Windows Help from the Microsoft Download Center. This download will not be available for Beta 2 or RC1. For more information, see Help Engine Support.

Note   HTML Help and .CHM files will continue to be supported for Windows Vista.

See "Help Engine Support" (next in this document) for further information.

Help Engine Support

Microsoft is committed to providing Help and Support technology in the Windows Platform and will continue to investigate new solutions for software developers. The following information clarifies the support in Windows Vista for four Microsoft Help technologies: Windows Help, HTML Help 1.x, the Help and Support Center, and the Assistance Platform client.

Windows Help (WinHelp.exe & WinHlp32.exe)

Windows Help WinHlp32.exe is a help program that has been included with Microsoft Windows versions starting with the Microsoft Windows 3.1 operating system. The Windows Help program (WinHlp32.exe) is required to display 32-bit help content files that have the .HLP file name extension.

Windows Help is being deprecated for Windows Vista. To view 32-bit Help files with the .HLP file name extension in Windows Vista, you will need to download and install WinHlp32.exe from the Microsoft Download Center. This download is not available for Beta 2 or RC1.

Microsoft strongly recommends that software developers discontinue using the Windows Help application in Vista. Software developers who ship programs that rely on .HLP files are encouraged to transition their Help experience to an alternative Help file format, such as CHM, HTML, or XML. You will also need to change your calls from the WinHelp() API to the new content source. Several third-party tools are available to assist authors in converting content from one format to the other.

HTML Help 1.x (HH.exe)

Microsoft HTML Help 1.x (HH.exe) is a Help system included in Windows releases starting with Windows 98. HTML Help is required to display compiled Help files with the .CHM file name extension.

HTML Help will ship in Windows Vista. However, only critical updates to the engine will be made. No new features or feature improvements will be added to the HTML Help engine for Windows Vista or future Windows releases.

For more information about the functionality of HTML Help and guidance on authoring files for HTML Help, see the HTML Help 1.4 SDK.

Help and Support Center (HelpCtr.exe)

The Help and Support Center (HelpCtr.exe) was a Help application designed for Windows XP and Windows Server 2003. The Help and Support Center displayed compiled Help files with the .CHM file name extension.

The Help and Support Center is not included in Windows Vista and its features are not supported. Compiled Help files with the .CHM file name extension will only be displayed in the HTML Help application as described above.

Assistance Platform client (HelpPane.exe)

The Assistance Platform client (HelpPane.exe) is a new Help engine designed for Windows Vista. It is not compatible with any previous versions of Windows. The Assistance Platform client is required to display Help files with the .H1S file name extension.

In Windows Vista, the Assistance Platform client can be customized by OEMs, system builders, and enterprise customers under license agreement, but cannot be used by third-party programs. For more information on customizing the Assistance Platform client, see the Windows SDK.

Junction Points and Backup Applications in Windows Vista

In Windows Vista and Longhorn Server the default location of user data has changed. An example of this change is the documents and Settings directory. It was moved from "%systemdrive%\Documents and Settings" to "%systemdrive%\Users". To enable interoperability with legacy apps junction points are used at the deprecated locations and point to the new locations in Windows Vista. For example C:\Documents and Settings is now a junction point which points to C:\Users. Backup application in Windows Vista and Longhorn must be capable of restoring junction points.

These junction points have file attributes of FILE_ATTRIBUTE_REPARSE_POINT & FILE_ATTRIBUTE_SYSTEM and the ACLs are set to "Everyone Deny Read". Applications must have permissions in order to call out and traverse a specific path. However, enumerating the contents of these junction points is not possible.

Classes of Junction Points

There are two Categories of Directory junctions that can be created by profiles for application compatibility in Windows Vista.

• Per user junctions: These are junctions that will be created inside each individual users profile to provide application compatibility for the old legacy namespace.
  • i.e. Junction from C:\Users\<username>\My Documents to C:\Users\<username>\Documents
  • These junctions will be created by the Profile service when the users profile itself is created
• System Junctions: These represent all the other junctions created on the system and are not beneath the <username> node:
  • This includes junctions for:

    Documents and Settings

    Junctions within the All User, Public, Default User profiles

  • These junctions will be created by userenv.dll when invoked from Machine OOBE on the Windows Vista PC.

Parent Folder Junction requirements:

Directory Junction creation location	Destination
..\Documents and Settings\	..\Users\

User Data Legacy Folder Junction requirements:

Directory Junction creation location	Destination
..\Documents and Settings\<username>\My Documents	..\Users\<username>\Documents
..\Documents and Settings\<username>\My Documents\My Music	..\Users\<username>\Music
..\Documents and Settings\<username>\My Documents\My Pictures	..\Users\<username>\Pictures
..\Documents and Settings\<username>\My Documents\My Videos	..\Users\<username>\Videos

Per User Application Data Legacy Folder Junction requirements:

Directory Junction creation location	Destination
..\Documents and Settings\<username>\Local Settings\	..\Users\<username>\AppData\Local
..\Documents and Settings\<username>\Local Settings\Application Data	..\Users\<username>\AppData\Local
..\Documents and Settings\<username>\Local Settings\Temporary Internet Files	..\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files
..\Documents and Settings\<username>\Local Settings\History	..\Users\<username>\AppData\Local\Microsoft\Windows\History
..\Documents and Settings\<username>\Application Data\	..\Users\<username>\AppData\Roaming

Per User OS Settings Legacy Folder Junction requirements:

Directory Junction creation location	Destination
..\Documents and Settings\<username>\Cookies\	..\Roaming\Microsoft\Windows\Cookies
..\Documents and Settings\<username>\Recent	..\Roaming\Microsoft\Windows\Recent
..\Documents and Settings\<username>\Nethood\	..\Roaming\Microsoft\Windows\Network Shortcuts
..\Documents and Settings\<username>\Printhood\	..\Roaming\Microsoft\Windows\Printer Shortcuts
..\Documents and Settings\<username>\SendTo\	..\Roaming\Microsoft\Windows\Send To
..\Documents and Settings\<username>\StartMenu\	..\Roaming\Microsoft\Windows\StartMenu
..\Documents and Settings\<username>\Templates\	..\Roaming\Microsoft\Windows\Templates

Legacy Profile folders where Junctions are not required:

Legacy Location	Reasoning
..\Documents and Settings\<username>\Desktop	Covered by the junction at 'Documents and Settings'
..\Documents and Settings\<username>\Favorites	Covered by the junction at 'Documents and Settings'
..\Documents and Settings\<username>\Local Settings\Temp	Covered by the junction for the Local Settings folder to Local.

All Users Legacy Folder Junction requirements:

Sym links creation location	Destination
..\Users\All Users	..\ProgramData

Directory Junction creation location	Destination
..\ProgramData\Desktop	..\Users\ Public\Desktop
..\ProgramData \Documents	..\Users\Public\Documents
..\ProgramData \Favorites	..\Users\Public\Favorites
..\Users\Public\Documents\My Music	..\Users\Public\Music
..\Users\Public\Documents\My Pictures	..\Users\Public\Pictures
..\Users\Public\Documents\My Videos	..\Users\Public\Videos
..\ProgramData\Application Data\	..\ProgramData
..\ProgramData\Start Menu\	..\ProgramData \Microsoft\Windows\StartMenu
..\ProgramData\Templates\	..\ProgramData \Microsoft\Windows\Templates

Default Users Legacy Folder Junction requirements:

Directory Junction creation location	Destination
..\Documents and Settings\Default User	..\Users\Default
..\Documents and Settings\Default User \Desktop	..\Users\Default \Desktop
..\Documents and Settings\Default User \My Documents	..\Users\Default \Documents
..\Documents and Settings\Default User \Favorites	..\Users\Default \Favorites
..\Documents and Settings\Default User \My Documents\My Music	..\Users\Default \Music
..\Documents and Settings\Default User \My Documents\My Pictures	..\Users\Default \Pictures
..\Documents and Settings\Default User \My Documents\My Videos	..\Users\Default \Videos
..\Documents and Settings\Default User \Application Data\	..\Users\Default \AppData\Roaming
..\Documents and Settings\Default User s\Start Menu\	..\Users\Default \AppData\Roaming\Microsoft\Windows\StartMenu
..\Documents and Settings\Default User \Templates\	..\Users\Default \AppData\Roaming\Microsoft\Windows\Templates

Directory Junction creation location	Destination
..\Program Files (Localized name)	..\Program Files
..\Program Files\Common Files (Localized Name)	..\Program Files\Local Files

Application Compatibility: Notes for Backup and Recovery in Windows Vista and Longhorn Server

Introduction

There as several changes in Windows Vista and Windows Vista Server that affects the compatibility of backup applications. This document addresses those issues and specific requirements concerning those changes. It is intended for backup application developers who are familiar with the Volume Shadow Copy Service (VSS) infrastructure and Windows backup procedures. Some of these features or changes may not be an issue, but vendors should verify that they are not impacted or that they have suitable mitigations in place. This document does not get into exhaustive details of the features and touches primarily on the impact to backup tools. For details on a specific topic follow the links listed at the end of this document or look on MSDN.

Compatibility with Windows XP backup applications

Several interfaces have changed since Windows XP and those libraries are not compatible with Windows Vista. At a minimum applications will need to be recompiled using either headers or libraries from the Microsoft Volume Shadow Copy Service SDK 7.2 (VSS SDK 7.2) or from the Windows Vista Platform SDK.

Compatibility with Windows Server Service 2003 Service pack 1 backup applications

Binaries from Windows Server 2003 SP1 are compatible with Windows Vista. Most backup applications would also need to account for the changes in the inbox writers, file and registry virtualization, WRP as well as the use of hard links in %windir%system32. Therefore these changes will need to be addressed for Windows Server 2003 SP1 backup applications to function under Windows Vista.

Compiling backup applications for Windows Vista

Applications that use interfaces available in Windows Server 2003 can be compiled using the headers and libs provided in VSS SDK 7.2. In order to use new specific Windows Vista interfaces, the user would need to compile the application using VSS headers and libraries included in the Platform SDK for Windows Vista. Note that Binaries compiled using Windows Vista headers and libraries will not run on Windows Server 2003.

In box Volume Shadow Copy Service (VSS) writers in Windows Vista

1. Registry Writer

   The Registry writer now performs in-place backups and restores of the Registry as compared to the spit writer scheme earlier. User hives are not reported by the Registry Writer.

2. COM+ RegDB Writer

   This writer backs up the contents of  %systemroot%\registration. The COM+ writer is an in place writer now as compared to a spit writer earlier.

3. MS Search Writer

   The function of this writer is to delete the search index from shadow copies after creation. This is done to minimize the impact of Copy-On-Write I/O during the shadow copy maintenance phase.

4. MSDE Writer

   This is the default writer for SQL Server™ 2000 and SQL Server™ 2005 databases.

5. Windows Management Instrumentation (WMI) Writer

   This writer is used for identifying WMI specific state and data during backup operations. The data includes files from the WBEM Repository.

6. Background Intelligent Transfer Service (BITS) Writer

   The BITS writer uses the FilesNotToBackup registry key to exclude files from the directory "%allusersprofile%\application data\microsoft\network\downloader.

7. Automated System Recovery (ASR) Writer

   The ASR writer stores the configuration of the disks on the system. It must be included for any backups required for Bare Metal Recovery.

8. System Writer

   The System Writer enumerates all the operating system and driver binaries and runs in the cryptsvc.exe process. On Windows Vista the System Writer will generate a list of files using the following formula.

   1. All static files that have been installed. These are identified by the attribute writeabletype = "static " or writeabletype is "" in the component manifest. This will include all WRP files, additionally there may be some files marked as static that are not WRP. For example, games are static but not WRP so that admins can change parental controls.
   2. The WinSxS folder which includes all manifests, optional components and 3rd party Win32 files.
   3. All PnP Files for installed drivers (owned by PnP)
   4. All User Mode Services and non PNP drivers.
   5. All Catalogs owned by CryptSvc.

   The files in %windir%\system32 are usually hard links to the winsxs directory.

   The restore app is responsible for laying down the files and registry and setting ACLs to match the system snapshot.  The appropriate hard links must also be created for a system state restore to work.

9. Microsoft Optimization Writer

   This writer deletes certain files from the snapshots. The file deletions are done to minimize Copy on Write (COW) I/O during the snapshot maintenance phase and the files are typically temporary files or those that do not constitute user or system state.

Interoperability with Transactions

Windows Vista includes support for transactions and VSS ensures that both the Kernel Transaction Manager (KTM) and Distributed Transaction Coordinator (DTC) are frozen prior to the creation of snapshots. This leads to two new timeout errors:

• VSS_E_TRANSACTION_FREEZE_TIMEOUT
• VSS_E_TRANSACTION_THAW_TIMEOUT

In case the requestor receives either of these errors it must retry snapshot creation. Registry and file system operations may also be transacted. In the case of the registry, the registry writer ensures transactional consistency. Transactional consistency of NTFS operations is ensured by mounting the shadow copy read/write after creation and then rolling pack partially committed operations.

Search the Internet

Overview

Windows Vista has a new feature that allows users to easily search the internet from the start menu. This works by the user clicking on the "Search the internet" option after entering text into the start menu search bar. To implement the "search the internet" feature Windows Vista invokes the application that is the default for the HTTP:// protocol and appends an argument with the search term.

Extensibility

Below outlines how an application can correctly handle being invoked from search the internet feature.

Windows Vista enables users to launch an Internet Search directly from the Start Menu search box. 

Figure 19.

When a user clicks on the "Search the Internet" link (see Figure 19), Windows Vista determines the default program for the http protocol by calling the AssocQueryString function with the following parameters:

AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch)

where szBrowser contains the location of the executable file of the browser currently registered.

Windows Vista then calls ShellExecuteEX to launch this program and passes "? <search term>" as the lpParameters argument, where <search term> is replaced with the contents of the search box. This is roughly equivalent to appending "? <search term>" to the browser's command line.

Figure 20.

It is up to each browser to determine what to do with the passed parameter. The recommended way to handle the parameter is to pass the search string directly to the browsers default search handler.  For example, in Figure 20, Windows Vista has launched the Internet Explorer browser with the search term "Hello World". Internet explorer passes the term directly to the default search handler for Internet explorer.

Any browser can take advantage of this functionality. For example, assume that the Contoso Internet Browser has been registered as the default http protocol handler. The executable for this browser is located at C:\Program Files\Contoso\contoso.exe. A call to AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch) will result in szBrowser containing the path of the exe file. ShellExecuteEX will use this information to launch the Contoso browser and pass it "? Hello World".

Browsers that want to be able to handle this correctly need to make sure its executable can handle being passed an argument with quotations that is pre-pended with a question mark. Below are 2 examples of an executable handling the search parameter being passed.

Internet Explorer:

C:\Program Files\Internet Explorer\iexplore.exe "? <search term> "

C:\Program Files\Internet Explorer\iexplore.exe "? Hello World"

Contoso Browser:

C:\Folder\contoso.exe "? <search term> "

C:\Folder\contoso.exe "? Hello World

See Also

Interoperability & Migration