The Windows Vista and Windows Server 2008 Developer Story: Application Compatibility Cookbook

[アーティクル]
05/11/2010

Microsoft Corporation

July 2006
Revised April 2007

The Windows Vista and Windows Server 2008 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 To provide feedback about the articles, please send e-mail to Vistadev@microsoft.com.

Introduction
Quick Compatibility Check
Operating System Versioning
User Account Control (Standard User Changes)
UAC: Application Update Guidelines
UAC: COM Per-User Configuration
Windows Resource Protection (WRP)
Internet Explorer Protected Mode
Windows 64-bit
IIS 7
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
Compatibility Risks
Windows Display Driver Model
Default Programs
Program Compatibility Assistant (PCA)
Graphical Device Interface GDI
User Interface Privilege Isolation (UIPI)
High DPI Scaling
PNG Icons
Named Pipe Hardening
SPAP Deprecation (Pstore)
WMI Providers: Default Security Hosting Model
Volume Shadow Copy Service
Standard User Analyzer
DHTML Editing Control
Help Engine Support
Junction Points and Backup Applications
Application Compatibility for Backup and Recovery
Integrating with the Search the Internet Feature
MMCs Must Be Data Execution Protection (DEP) Aware
Networking: Turning off the Windows Firewall
Issues Relevant to Windows Server Codename "Longhorn"
Active Directory Changes in Windows Server Codename "Longhorn"
Windows Server Codename "Longhorn" Roles
Windows Application Experience in Windows Server Codename "Longhorn"
Windows Server Codename "Longhorn" Server Core
Windows Server Failover Clustering on Windows Server codename "Longhorn"
Networking: Windows Firewall Enabled by Default on Windows Server codename "Longhorn"

Introduction

Windows Vista and Windows Server Codename "Longhorn" introduce 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 and Windows Server Codename "Longhorn", many new features have been introduced and existing features have been improved.

While Windows Vista and Windows Server Codename "Longhorn" are 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 and Windows Server Codename "Longhorn" compatibility is high, and Microsoft is continuously striving to achieve the best possible compatibility solutions for existing applications for Windows Vista and Windows Server Codename "Longhorn."

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 Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn", such as the 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 section User Account Control (Standard User Changes).

Note All items in this document are appropriate for both Windows Vista and Windows Server Codename "Longhorn" unless otherwise noted. There are no architectural changes for Windows Vista SP1. Applications that are compatible with Windows Vista RTM should continue to be compatible with Windows Vista SP1.

Quick Compatibility Check

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

Working with a Clean Installation of Windows Vista

Install Windows Vista or Windows Server Codename "Longhorn" on a test machine.
Install the application on the test machine. If a prompt is displayed requesting permission to install the application, click Permit and continue. If installation succeeds, go to step 6.
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.
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.
Go back to step 2. If you cannot install the application, go to step 9.
The application should now be installed.
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.
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.
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.
You have completed the scenario.

Working with an Upgrade to Windows Vista from Windows XP Service Pack 2

Install Windows XP SP2 on a test machine and then install the application. Verify all the functionality of the application before proceeding.
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.
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.
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.
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 and Windows Server Codename "Longhorn" changes. Use the topics in this document to check your application.
You have completed the scenario.

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

Links to Other Resources

Operating System Versioning

Feature Impact

High

Brief Description

The internal version number for Windows Vista and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn" because the application compatibility in Windows Vista and Windows Server Codename "Longhorn" is very high. However, for applications and installers that check for OS version, a Compatibility mode is provided in Windows Vista and Windows Server Codename "Longhorn."

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 (Standard User Changes)

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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn" 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 may 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 to 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.
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 Compatibility Administrator to identify those areas of an application that are performing administrator operations.

Leverage Windows Vista and Windows Server Codename "Longhorn" capability solution

Windows Vista and Windows Server Codename "Longhorn" based applications need to:

Follow the prescribed guidelines found in the Windows Vista and Windows Server Codename "Longhorn" LOGO programs and user experience (UX) guidelines documentation (see the below Links to Other Resources 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 to Other Resources

UAC: 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.

Some applications require more privileges than that of a Standard user when they perform their updating functions. Often times, 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.

Windows Vista and Windows Server Codename "Longhorn" includes built-in Installer Detection heuristics to detect many application 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 be completed successfully as follows:

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. e.g. 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 Windows Vista and Windows Server Codename "Longhorn", there isn't a good way to create a multi-purpose executable that performs updates because it is not possible to 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:

Utilizing Patching technology in MSI (Latest versions of Windows Installer, Installshield, Wise for Windows Installer etc. support this)
- MSI is a key installer technology because it provides the ability to manage updates for you.
  
  i. Use MSI to create your initial installer and embed a certificate in the MsiPatchCertificate table.
  
  ii. Create an update for your application and sign it with the previously specified certificate.
  
  iii. MSI will perform the elevation for the application when applying the patch.
  
  iv. The main advantage of this method over others is that it works with Standard User, and keeps the system 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 run the application.
Using other custom installer mechanisms
- This is discouraged for the enterprise environment because this will prohibit the user from running as non-Administrators
- The updater should be written as a separate process with a desired run level of requiresAdministrator.
  
  i. This process should only execute when necessary for updating purposes. Checking for whether the program needs updates should be done as the user.
Updating while running as a "Standard User" application
- 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 to Other Resources

The following videos on Windows Vista User Account Protection are designed to help developers understand and write code:

Part 1: Watch Video
Part 2: Watch Video
Part 3: Watch Video
Part 4: Watch Video
Part 5: Watch Video
User Account Control Application Compatibility Toolkit: Watch Video
User Account Control Demo: Watch Video

UAC: COM Per-User Configuration

Feature Impact

Medium

Brief Description

The Component Object Model (COM) leverages the registry to maintain information about all of the COM objects installed on a computer. This registry hive (HKEY_CLASSES_ROOT) is a virtual registry hive, which allows for both per-user and per-machine object registration. Per-user COM objects configurations are stored in HKEY_CURRENT_USER\Software\Classes, while per-machine configurations are stored in HKEY_LOCAL_MACHINE\Software\Classes. Typically, COM per-user configurations take precedence.

Beginning with Windows Vista and Windows Server Codename "Longhorn", if the Integrity Level of a process is higher than Medium, the COM runtime ignores per-user COM configuration, and only accesses per-machine COM configuration. This reduces the surface area for elevation of privilege attacks, preventing a process with standard user privileges from configuring a COM object with arbitrary code and having this code called from an elevated process.

Manifestation

Applications that are run elevated (whether manifested as requireAdministrator or user-selected by right click → Run as Administrator), as well as applications run from an account that is a member of the Administrators group where UAC is disabled, will not be able to access any COM objects configured per-user.

Remedies

Applications that will require administrator rights should register any dependent COM objects during installation to the per-machine COM configuration store (HKEY_LOCAL_MACHINE\Software\Classes).

Links to Other Resources

Windows Resource Protection (WRP)

Feature Impact

High (blocks 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 the Protected Resource List for a full accounting of protected resources.

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, this improves system stability.

Manifestation

Applications will not succeed in replacing or modifying protected OS resources, (typically this happens during application install and uninstall) 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 this may result in runtime errors.

Mitigations

Important The following mitigation will not be applied if the application is identified as being a Windows Vista and Windows Server Codename "Longhorn"-based application.

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

When an application installer is detected as a legacy installer (that is, the installer does not have a manifest).
When there is an Access Denied error that is due to the application trying to create or modify a WRP resource.
In some scenarios, mitigation is automatically provided when delete attempts are made on WRP-protected resources.
If an application tries to create a new subkey or value under a WRP COM registry key, it may receive an Access Denied error.

Note In this case, success is returned, although no changes are applied to the WRP resource.

Remedies

Do not install or update system state (files and registry) on Windows Vista and Windows Server Codename "Longhorn" except when using Microsoft provided redistributable packages designed for Windows Vista and Windows Server Codename "Longhorn."
Do not install individual components of a whole Microsoft-provided redistributable designed for Windows Vista and Windows Server Codename "Longhorn."
Use the SfcIsFileProtected API to detect WRP-protected files. If a file is WRP, then the application installer should not install or modify the file.
For registry keys protected by WRP, applications should gracefully handle "Access Denied" messages that are due to WRP.
Test and verify that legacy applications that rely on WRP mitigation are working properly by installing the application.
Use SfcIsKeyProtected API to detect WRP-protected key. 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 message because of WRP will depend on the impact of this failure for the application:

If the application is trying to write a key or value that already exists, then the application can ignore the error message.
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 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 key is WRP:

For the Registry:

Through code use the SfcIsKeyProtected API.
Or use Regedit to check permissions on the key.
- Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators and Users will only have Read permissions.
- Click Start, and then click Run.
- Type Regedit, and then click OK
- Search for the key. Right-click the registry key. Click Permissions.
- Files that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators and Users will only have Read permissions.

For files:

Through code, use SfcIsFileProtected API.
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 only have Read permissions.

Links to Other Resources

Windows Vista Management Features

Functions/APIs

https://msdn2.microsoft.com/en-gb/library/aa382545.aspx

Reference

https://msdn2.microsoft.com/en-gb/library/aa382550.aspx

Internet Explorer Protected Mode

Feature Impact

High

Brief Description

In Windows Vista and Windows Server Codename "Longhorn", 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 and Windows Server Codename "Longhorn" 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 folder.

Furthermore, the Protected Mode process will run with a low desktop integrity level when Windows Vista and Windows Server Codename "Longhorn" ship, which will prevent Protected Mode 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.

Aa480152.appcompat_01(en-us,MSDN.10).gif

Figure 1. IE Protected Mode Compatibility Architecture

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 and Windows Server Codename "Longhorn" capability solution

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

Links to Other Resources

Windows 64-bit

Feature Impact

High

Brief Description

Windows Vista and Windows Server Codename "Longhorn" fully support the 64-bit architecture processors from AMD and Intel. The 64-bit version of Windows Vista and Windows Server Codename "Longhorn" can run all 32-bit applications with the help of the WOW64 emulator. However, 16-bit applications, 32-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 and Windows Server Codename "Longhorn" 64-bit editions. Unsigned drivers are not supported and cannot be installed on 64-bit Windows Vista and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn." 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 new 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 and Windows Server Codename "Longhorn" machine. The application should function properly on both architectures.

Links to Other Resources

IIS 7

Feature Impact

High

Brief Description

Internet Information Server 7 provides a revolutionary way to develop and manage web applications. It introduces granular controls over the various components, reduces administrative costs, provides better security, and simplifies development.

IIS 7 also enhances features from the older versions in various ways. Some of the changes that could impact compatibility for applications developed for IIS 6 or older versions are below:

IIS is componentized and Setup is granular; not all components are installed by default: NTLM is not installed by default
Buffering files to memory is on by default
ISAPI changes
Metabase changes (backup/restore; import/export)
MMC snap-in extensions will not work
IIS reset does not stop W3svc; starting W3svc does not start IISAdmin
Aspnet_regiis.exe has undergone significant changes

Deprecated components in IIS

The following IIS features have been retired and will not be available in IIS 7:

IIS 5.0 Isolation Mode
Metabase account recreation (checker code)
Sub-authentication (password synchronization and old digest authentication)
Built-in Passport support
Convlog.exe
Clustering UI support
IISRESET—reboot option
IIS Shell Extension
NNTP
ASP content rotator and nextlink
Server-side image maps
Internet Data Connector (HTTPODBC.DLL)
URLContent Rating UI
Authorization ISAPI
Password change code
IIS*.VBS command-line tools in %windir%\system32
WebDAV
Front Page Server Extensions

Manifestation

Sites using missing components may fail to run.
Sites using deprecated components will not run without modification.
Management tools and methods dependent upon the deprecated IIS metabase will break.
Cycling the W3SVC alone may not resolve problems like it did in earlier versions.

Remedies

Review installed IIS features and enable those that are required to enable proper functionality. IIS 7.0 breaks up the Web server into a lightweight server core and more than 40 feature modules that can be plugged into this core. These modules—like StaticFileModule, which allows downloads of static Web content, or WindowsAuthModule, which supports integrated NTLM authentication—can be independently installed on the server to provide the exact functionality you need.

Aa480152.appcompat_01b(en-us,MSDN.10).gif

Figure 2. IIS features hierarchy

IIS 7.0 features a new delegated configuration system based on a hierarchy of distributed XML configuration files. These files provide a portable method of configuration management which allows the side-by-side storage of IIS and ASP.NET configuration, using clean and strongly structured XML directives.

Cycling of all IIS 7 related services may be necessary to provide the reset functionality from earlier versions. Each service should be checked when restarted to confirm the restart.

Links to Other Resources

Microsoft Graphical Identification and Authentication (GINA)

Feature Impact

High (frequency: low)

Brief Description

Prior to Windows Vista and Windows Server Codename "Longhorn", 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 and Windows Server Codename "Longhorn" introduce 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 Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn." The GINA modules of applications will not function and must be re-authored using the new authentication model for Windows Vista and Windows Server Codename "Longhorn."

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 and Windows Server Codename "Longhorn." These may include biometric devices, custom UI for logon, or virtual private network (VPN) solutions for remote users with custom logon UI.

Remedies

Leverage new capability solution.

The applications or components that use the GINA technology must be re-authored to use the new logon authentication model for Windows Vista and Windows Server Codename "Longhorn."

Links to Other Resources

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 that are looking for a means to elevate their own privilege levels.

The Microsoft Windows Vista and Windows Server Codename "Longhorn" and Windows Server Codename "Longhorn" operating systems mitigate this security risk by isolating services in Session 0 and making Session 0 non-interactive. In Windows Vista and Windows Server Codename "Longhorn", 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 include:

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 applications service uses a UI, a built-in mitigation in Windows Vista and Windows Server Codename "Longhorn" allows the user to interact with the Session 0 UI in a special desktop. This will make available the UI specific to the application, rather than 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 and Windows Server Codename "Longhorn."

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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn."

Leverage Windows Vista and Windows Server Codename "Longhorn" 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 a 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 to Other Resources

Networking: TCP/IP Stack and the Windows Filtering Platform

Feature Impact

High

Brief Description

The Windows Vista and Windows Server Codename "Longhorn" 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), the networking stack implements a new architecture whereby there is a single transport and framing layer that supports multiple IP layers. There are several new features along with several protocol 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. 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 Windows Server Codename "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 applications 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 and Windows Server Codename "Longhorn":

The firewall-hook driver functions and the filter-hook driver functions have been deprecated.
The R-series tools, including rexec, rsh, finger, etc. These tools are available from the Services for Unix components, if needed.
The Internetwork Packet Exchange (IPX) protocol. IPX has been deprecated and is no longer available from Microsoft There should be little, if any impact on application compatibility 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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn."

Remedies

Leverage new capability solution

The WFP exposes a rich set of functions and services for 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 to Other Resources

WFP MSDN Query

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 has changed in Windows Vista and Windows Server Codename "Longhorn." Also, Windows Vista and Windows Server Codename "Longhorn" now support IPv6 by default. Instead of providing separate APIs for IPv4 and IPv6, a new Helper API set has been 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 sub-interfaces

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.

Networking: IPv6

Feature Impact

High (frequency: medium)

Brief Description

The TCP/IP stack in Windows Vista and Windows Server Codename "Longhorn" 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:

Applications and services that are IPv6 compatible can have a much improved peer-to-peer connection success rate on IPv4 networks due to the built-in NAT traversal capabilities of Teredo (which encapsulates IPv6 inside of IPv4 across NATs).
IPv6 traffic will be created by the Windows Vista and Windows Server Codename "Longhorn" stack regardless of whether the network supports IPv6 or not. Therefore, for example, all Windows Vista and Windows Server Codename "Longhorn" systems will have at least one IPv6 address (for link-local), and will attempt DNS lookups for both IPv4 and IPv6.
The Windows Vista and Windows Server Codename "Longhorn" stack will always prefer using IPv6 when it can find an IPv6 address for the remote system it needs to talk to. Network communication will take place for any IPv6 compatible application or service if both systems in a session have IPv6 addresses (e.g. sharing files on a LAN will usually be done over IPv6).
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, but remains dormant unless an application or service tries to use it. The Teredo service becomes active if: 1. The Windows Firewall exception for a listening application or service has Edge Traversal option enabled (an advanced setting in the MMC snap-in of the Windows Firewall, or invoked via an option in the Windows Firewall APIs). 2. An application or service attempts to communicate with a Teredo address (the regular stateful inspection features of the Windows Firewall will ensure that only IPv6 responses matching the outbound requests will be allowed in).
Windows Vista and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn" 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 or Windows Server Codename "Longhorn" machine on a network.

Applications that do not use protocol agnostic APIs, and aren't IPv6 compatible, will not be able to take advantage of Teredo IPv4 NAT traversal and connections may fail when one or more parties is behind an NAT.

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.

IPv6 compatible applications that set the Edge Traversal flag in the Windows Firewall exceptions (using Windows Firewall APIs) will automatically take advantage of Teredo for traversing IPv4 NATs.

Links to Other Resources

https://msdn2.microsoft.com/en-us/library/ms738649.aspx

Compatibility Risks

Deprecated Components

The following components from earlier Windows releases will not be present in Windows Vista nor Windows Server Codename "Longhorn":

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 and Windows Server Codename "Longhorn." For more information, see the User-Mode Driver Framework (UMDF) site.
Windows Help for 32-bit applications (WinHlp32.exe) -Windows Help is not supported 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 and Windows Server Codename "Longhorn", you will need to download and install Windows Help from the Microsoft Download Center. For more information, see Help Engine Support.

Note HTML Help and .CHM files will continue to be supported for Windows Vista and Windows Server Codename "Longhorn."
Microsoft FrontPage server extensions—Windows SharePoint Services now provides an enhanced feature set to the developer community.
Services for Macintosh—There is no replacement for this component.
D3DRM—DirectX will be the only supported graphics package for Windows Vista and Windows Server Codename "Longhorn."
Web Publishing Wizard—There is no replacement for this component.
NTLMSSSP Service
Windows Management Instrumentation Driver Extensions (WMI) Services
RPC-Locator Service
POP3 Email Server—There is no replacement for this component.
NetDDE—For security reasons, Windows Vista and Windows Server Codename "Longhorn" 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.

Links to Other Resources

https://support.microsoft.com/default.aspx?scid=kb;en-us;125703 provides details on NetDDE.

Windows Help (WinHlp32.exe) is being deprecated for Windows Vista and Windows Server Codename "Longhorn." To view 32-bit Help files with the .HLP file name extension in Windows Vista and Windows Server Codename "Longhorn", you will need to download and install Windows Help from the Microsoft Download Center. For more information, see Help Engine Support.

Note HTML Help and .CHM files will continue to be supported for Windows Vista and Windows Server Codename "Longhorn."

Windows Help for Vista and Windows Server Codename "Longhorn"

Windows Display Driver Model

Windows Vista and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn."
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 or Windows Server Codename "Longhorn."

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 and Windows Server Codename "Longhorn." 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:

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 and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn" 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 the Microsoft Windows XP Fast User Switching: Design Guide for Building Business Applications page.

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.

Default Programs

Brief Description

Default Programs has 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 Windows Server Codename "Longhorn" 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. Care must be taken when trying applications as many applications can inadvertently change the default behavior unbeknownst to the user.

The problem gets worse as we start adding multiple users onto the same computer. As multiple users use different applications they unintentionally change each others' defaults. The root of this problem is that both protocols and file associations 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 reclaim its 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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn", 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 Windows Server Codename "Longhorn" 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 a 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 applications 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 and Windows Server Codename "Longhorn"
Default Programs allows applications to maintain Windows 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 the default. Using the new API set this can be done in a single API call instead of crawling the registry which was the method in previous versions of the OS.

Using the new API set also helps applications to function correctly in the new world with UAC (User Account Control). 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 Windows Server Codename "Longhorn" 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 to update an application to use Default Programs is to consistently achieve the desired results. File and protocol associations are derived from a hierarchical structure in 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 its 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 uses 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

Aa480152.appcompat_01c(en-us,MSDN.10).gif

Figure 3. Default Programs UI flow

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

Figure 5. Control Panel, Change Program Defaults (Click on the image for a larger picture)

Figure 6. Set a Default Program Page (Click on the image for a larger picture)

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

Figure 7. Description of the Registered Application (Click on 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 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.

This view shows everything that the application has registered for and which 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.

Figure 8. Details of Registration and Default (Click on the image for a larger picture)

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:

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

Note Applications need to create application specific ProgIDs for their associations.
Claim machine level file associations (Like XP)
Write to new Default Programs schema (New for LH)

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:

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

Accept defaults should call 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 the 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.

Figure 9. Litware Media Player (Click on the image for a larger picture)

In this view a user will see all the defaults a specific application has registered. A user will be able to see what application owns the current defaults, and will be able to 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 whether 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 to see whether they are the default through the new Default Programs API set. If the application is not the default, the application should present the users with a UI that ask the user to:

Keep everything the way it is
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 applications registered defaults.

Aa480152.appcompat_08(en-us,MSDN.10).gif

Figure 10. An example using Internet Explore

Registering with Default Programs

Default Programs functions by having each application explicitly register for what file associations and protocols it wants 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 types of applications to point to the same .exe file 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:

HKLM\software\Contoso\WebBrowser\Capabilities
Descritpion =" The award-winning Web browser is better than ever. 
Search the internet in seconds and find anything you want. 
Use integrated tabs and new phishing detectors to enhance your internet 
experience."

Note This would really be a dll to allow for localization.

\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 Application 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 well. In the example above, ContosoHTML points to a single progId that has the shellexecute information for htm, html, shtml, xht, xhtml. For the protocols, a specific progId is defined per protocol. This allows the execution string to be different for each 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:

Capabilities are the registry subkey that all Defaults 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. (Be sure to localize your strings.).

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

ApplicationName:

This field 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 FileAssociations 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 UrlAssociations 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 MIMEAssociations 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 defaults MAPI client.

Note There is a separate start menu registration. See Registering Programs with Client Types for more information.

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.

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 https:// 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), the type of extension it is and it will set the default 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. A defined partner or 3rd party scenario where we would expect anyone to call this does not currently exist; however 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 that want to provide a UX direct link to their advanced associations' configuration.

Note This API set is only available for Windows Vista and Windows Server Codename "Longhorn" and beyond. Applications supporting downlevel OSs (XP, Win2K, and Win98) should use their pre-existing defaults code on those OSs by using a sku check to differentiate between pre-Windows Vista and Windows Server Codename "Longhorn" and post-Windows Vista and Windows Server Codename "Longhorn" OSs.

Code Examples

Using the registration for the Contoso Web browser, this 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;
}

Default User Check List

Registers correctly for SPAD
Registers correctly for Program Defaults
Registers correctly file associations, protocol handling, OpenWith, Start Menu, QuickLaunch
Install follows guidelines (Sets per-machine registration, does not take defaults)
First run follows guidelines (ask user for settings, file associations, etc)
Install or upgrade doesn't take defaults
Correctly self-checks for default. User permission before taking default
Never triggers virtualization
No AppCompat warnings or blocks (PCA)
Also continues to work correctly in XP
[use OS UI for file associations, etc]
[Signed code – URL in Program Defaults]

Links to Other Resources

File Association Documentation

Videos

Default Programs Videos—Watch Video

Program Compatibility Assistant (PCA)

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 and Windows Server Codename "Longhorn" 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.

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 Windows Server Codename "Longhorn" 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. These installers will typically fail with an error message saying that the current version of Windows is not supported and installation will be terminated.

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

Aa480152.appcompat_11(en-us,MSDN.10).gif

Figure 11. Example of a PCA Error Message

Programs commonly use GetVersion or the GetVersionEx APIs to get information on the Windows OS version they are running on. In Windows Vista and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn." 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 soon be shown.

Aa480152.appcompat_12(en-us,MSDN.10).gif

Figure 12. PCA UI after Installer Termination

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 and answer section below:

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 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 Windows Server Codename "Longhorn" and checks whether 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 was deleted from ARP.
How does PCA get information about the setup programs?

PCA relies on the User Access Control (UAC) feature in Windows Vista and Windows Server Codename "Longhorn" to know whether a program is a setup program. 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.
What does each option in the PCA dialog for setups do?

"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.

"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.

"Cancel"

PCA will do nothing.

All these options will result in the PCA dialog disappearing. 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 that 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 and Windows Server Codename "Longhorn" 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. Explorer launches the UAC consent UI asking for administrator credentials or approval and finally runs the program as administrator. Below is an example of a PCA dialog that will show up in this scenario, illustrated by a test program.

Aa480152.appcompat_13(en-us,MSDN.10).gif

Figure 13. PCA dialog box for program trying to launch a child.exe

Here the test program has tried to launch an updater which is required to run as administrator and has 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 are explained through Question/Answer below.

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.
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 tenets 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. The install detection part of the overall User Access Control (UAC) feature 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 standard installer technologies like Install Shield, Microsoft Windows Installer, etc.,

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

Aa480152.appcompat_14(en-us,MSDN.10).gif

Figure 14. Detecting installers that need to run as Administrator

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:

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 whether 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 are 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 as 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.
What does each option in the PCA dialog for this scenario do?

"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.

"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.

"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 "The program installed correctly" 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.

Aa480152.appcompat_15(en-us,MSDN.10).gif

Figure15. Legacy Control Panel item that needs to run as Administrator

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

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

Adding a UAC Manifest to Managed Code

What does each option in the PCA dialog for this scenario do?

"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.

"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.

"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 "The control panel works correctly" PCA dialog.

Detecting program failures due to deprecated Windows components

This PCA scenario mitigates the impact on programs due to deprecated (removed) components in Windows Vista and Windows Server Codename "Longhorn." PCA detects programs that are trying to access a DLL or a COM object removed in Windows Vista and Windows Server Codename "Longhorn." If a program is detected trying to access a known DLL/COM object, PCA will provide a UI at the program termination to inform the user 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.

Aa480152.appcompat_16(en-us,MSDN.10).gif

Figure 16. Dialog displayed when PCA detects a deprecated Windows component

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

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

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 PCA will trigger after the program termination.

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 article that talks about alternatives 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 and Windows Server Codename "Longhorn" do not support unsigned drivers on the 64 bit platform and enforce 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 is 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.

Aa480152.appcompat_17(en-us,MSDN.10).gif

Figure 17. PCA dialog when unsigned driver detected

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

PCA detects this scenario first by monitoring changes to the KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key for addition of new drivers into the system. 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 does not have a valid signature, PCA dialog will be displayed. 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 informs users at program startup if the program belongs to a list of programs known to have compatibility issues. The list is stored in the System application compatibility database. This scenario also exists in Windows XP and these messages are known as the Application Help (shortly Apphelp) messages. There are two types of Apphelp messages.

Hard Block Messages—If the program is known to be incompatible and if allowing the program could 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 each ISV whose program is going to be blocked.

Aa480152.appcompat_18(en-us,MSDN.10).gif

Figure 18. Hard block apphelp message—displayed when incompatibility would have severe impact

Soft Block Messages—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.

Aa480152.appcompat_19(en-us,MSDN.10).gif

Figure 19. Soft block dialog displayed when incompatibility issues would not cause severe impact

In both cases, "Check for solutions" 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 website 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 from this key, PCA stores the list of all programs for which it came up under the following key for each user, even if no compatibility modes where applied (e.g. in the case the 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 and Windows Server Codename "Longhorn." 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 Windows Server Codename "Longhorn"). PCA checks for this manifest and will exclude the program. This applies for both installer and regular programs.

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\ AppCompatFlags\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 desired. The name of the policy is "Turn Off Program Compatibility Assistant." It 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 listed in the table below.

Values of the Scenario ID

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

In an Enterprise setting, an IT Professional 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 used in the enterprise.

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

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 and Windows Server Codename "Longhorn", 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 and Windows Server Codename "Longhorn", 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.

Flashes of black

A related issue can occur where the background contains uninitialized pixels that appear to the user as flashes of black on the screen. This occurs when applications do painting that is not part of a WM_PAINT message. The system detects that the application is drawing and redraws the desktop, but the application may not have finished drawing the hwnd. This causes the flashes of black.

Glass disabled for an 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 and Windows Server Codename "Longhorn" include 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 and Windows Server Codename "Longhorn", 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.

Slower text rendering

Calls such as DrawText better support international and East Asian languages.

Reduced application address space

The bitmap for a top-level window is stored in the applications 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.

User Interface Privilege Isolation (UIPI)

Feature Impact

Low

Brief Description

As an added layer of defense against malicious software, Windows Vista and Windows Server Codename "Longhorn" allow 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. 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 a higher privileged application. 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.

An Application may not work at all, or it may not 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 they 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 where the source code is available, consider reviewing any code that uses the following APIs, as they often indicate cross-process communications and associated issues:

SendInput

Search for 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. While not an exhaustive search, it will help to identify issues versus minimizing false positives.

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 very small. Windows Vista and Windows Server Codename "Longhorn" introduce the ability to scale applications that were written for 96 dpi screens, which they do by rendering the applications 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 the article How to Write High-DPI Applications.

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 and Windows Server Codename "Longhorn" give 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 and Windows Server Codename "Longhorn" don'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 the article How to Write High-DPI Applications.

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 and Windows Server Codename "Longhorn" icons use the PNG variant.

Manifestation

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

Links to Other Resources

https://blogs.msdn.com/nickkramer/archive/2006/04/24/582365.aspx

Named Pipe Hardening

Brief Description

In Windows Vista and Windows Server Codename "Longhorn", 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 and Windows Server Codename "Longhorn" harden 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 third party service will be affected by default. Service Sids is a new feature in Windows Vista and Windows Server Codename "Longhorn" 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) provides applications with an interface to store user data that must be kept secure or free from modification. Pstore has been changed to read only in Windows Vista and Windows Server Codename "Longhorn." This means that any application that tries to create new PStore data items without using DPAPI will fail.

Remedies

Use DPAPI for future PStore procedures.

Links to Other Resources

To learn more about the existing PStore items and use of DPAPI to manage them instead, please read Windows Data Protection.

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 and Windows Server Codename "Longhorn" Beta2), if the HostingModel of a WMI provider (__Win32Provider.HostingModel property) was 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 to Other Resources

Provider Hosting and Security

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.

Manifestations

Compatibility with XP backup applications

Several interfaces have changed since XP and the libraries are not compatible with Windows Vista and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn" Beta 2.

Compatibility with 2K3 SP 1 backup applications

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

Compiling backup applications for Windows Vista and Windows Server Codename "Longhorn"

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 and Windows Server Codename "Longhorn", recompile using the VSS headers and libs included in the Platform SDK for Windows Vista and Windows Server Codename "Longhorn."

VSS writers

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 and Windows Server Codename "Longhorn" the System Writer will generate a list of files using the following formula:

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 administrators can change parental controls.
The WinSxS folder which includes all manifests, optional components and 3rd party Win32 files
All PnP Files for installed drivers (owned by PnP)
All User Mode Services and non PNP drivers
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 are done 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 to Other Resources

Standard User Analyzer

Introduction

The "Standard User Analyzer" (previously known as the "LUA Analyzer") is a tool to help independent software vendors (ISVs), IT professionals, and end 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

Prerequisites

Operating systems: Windows Vista and Windows Server Codename "Longhorn", 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 Prior to using Standard User Analyzer, you must install the 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 or Windows Server Codename "Longhorn" computer to properly identify an applications standard user compatibility issues.

The following procedure is written to be performed by a standard user on a Windows Vista and Windows Server Codename "Longhorn" computer:

Click Start, point to All Programs, and then double-click Standard User Analyzer.
On the App Info tab, in the Target Application field, enter the directory location of the target applications executable file or use the Browse function.
On the App Info tab, in the Parameters field, enter parameters for the application, if applicable.
On the App Info tab, select the Launch Elevated checkbox, and then click the Launch button.
If a User Account Control credential prompt appears for SUAnalyzerSrv.exe, provide administrator credentials and click Submit.
In the User Account Control credential prompt for 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.

Standard User Analyzer Tab Details

Tab	Details
File	Lists file system access issues. For example, an application to write to a file that normally only administrators can access.
Registry	Lists system registry access issues. Fore 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 for some modern applications. One example is the Calculator in Windows XP. If the view is changed from "Standard" to "Scientific", calc.exe calls WriteProfile API to write into windows\win.ini, which is only writeable 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.
NameSpace	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 applications source code.

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 only view "error messages" is necessary.

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 only captures 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 unchecked in order to keep the log file from getting too large.

Help menu:

Help menu.

DHTML Editing Control

Links to Other Resources

Relevant documentation in the SDK on the built-in editing capabilities of IE in 5.5 can be found in Overview and tutorials.

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 and Windows Server Codename "Longhorn" for four Microsoft Help technologies: Windows Help, HTML Help 1.x, the Help and Support Center, and the Assistance Platform client.

Windows Help—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 and Windows Server Codename "Longhorn." To view 32-bit Help files with the .HLP file name extension in Windows Vista and Windows Server Codename "Longhorn", you will need to download and install WinHlp32.exe from the Microsoft Download Center.

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 and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn" or future Windows releases.

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

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 Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn", 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 and Windows Server Codename "Longhorn" and Longhorn Server the default location of user data has changed. An example of this change is the Documents and Settings directory which has been 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 and Windows Server Codename "Longhorn." For example C:\Documents and Settings is now a junction point which points to C:\Users. Backup application in Windows Vista and Windows Server Codename "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 and Windows Server Codename "Longhorn."

Per user junctions: These are junctions that will be created inside each individual user's 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:
  
  i. Documents and Settings
  
  ii. 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 and Windows Server Codename "Longhorn" 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\My Music	..\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

User Junction Points

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\Start Menu\	..\Users\Default \AppData\Roaming\Microsoft\Windows\StartMenu
..\Documents and Settings\Default User\Templates\	..\Users\Default \AppData\Roaming\Microsoft\Windows\Templates

Program Files Junction Points

Directory Junction Creation Location	Destination
..\Program Files (Localized name)	..\Program Files
..\Program Files\Common Files (Localized Name)	..\Program Files\Local Files

Application Compatibility for Backup and Recovery

Introduction

There are several changes in Windows Vista and Windows Vista and Windows Server Codename "Longhorn" Server that affect the compatibility of backup applications. This document addresses those issues and specific requirements concerning those changes. This section 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 section 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 and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn" Platform SDK.

Compatibility with Windows Server Service 2003 Service Pack 1 Backup Applications

Binaries from Windows Server 2003 SP1 are compatible with Windows Vista and Windows Server Codename "Longhorn." 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 and Windows Server Codename "Longhorn."

Compiling Backup Applications for Windows Vista and Windows Server Codename "Longhorn"

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

Interoperability with Transactions

Windows Vista and Windows Server Codename "Longhorn" 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.

Integrating with the Search the Internet Feature

Overview

Windows Vista and Windows Server Codename "Longhorn" have 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 and Windows Server Codename "Longhorn" invoke the application that is the default for the https:// protocol and appends an argument with the search term.

Extensibility

Below outlines how an application can correctly handle being invoked from the Search the Internet feature.

Windows Vista and Windows Server Codename "Longhorn" enable users to launch an Internet Search directly from the Start Menu search box.

Figure 20. Start Menu Search Box
When a user clicks on the "Search the Internet" link, Windows Vista and Windows Server Codename "Longhorn" 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.

Figure 21. Windows Live Search (Click on the image for a larger picture)

Windows Vista and Windows Server Codename "Longhorn" then calls ShellExecuteEX to launch this program and pass "? <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 browsers command line.

Each browser must 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 21, Windows Vista and Windows Server Codename "Longhorn" 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".

To handle this correctly, a browsers must executable must be able to handle being passed an argument with quotations that is pre-pended with a question mark. Below are two 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"

Links to Other Resources

MMCs Must Be Data Execution Protection (DEP) Aware

Feature Impact

Moderate

Brief Description

MMC.EXE always runs with DEP (Data execution protection) enabled. Snap-ins must be DEP aware. This feature cannot be turned off, and no compatibility mode exists.

Manifestation

Snap-ins that are not DEP aware may cause a failure to load within MMC or not work properly.

Remedies

This feature cannot be turned off, and no compatibility mode exists.

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 and Windows Server Codename "Longhorn") attempts to turn off the Windows Firewall in Windows Vista and Windows Server Codename "Longhorn", Microsoft has deprecated the Windows Firewall XP SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) function in Windows Vista and Windows Server Codename "Longhorn." When called on Windows Vista and Windows Server Codename "Longhorn", this function will:

Return an error code of E_NOTIMPL
Show a message to the user
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 and Windows Server Codename "Longhorn" 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 and Windows Server Codename "Longhorn" support IPv6 and IPv4 out-of-the-box and will automatically have an IPv6 address; therefore, it is essential that your firewall solution filters BOTH IPv4 & IPv6.
Windows Vista and Windows Server Codename "Longhorn" also support 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 and Windows Server Codename "Longhorn" 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 your application addresses all of the security-related points specified above.
Check the firewall status before your application turns-off or disables Windows Firewall with Advanced Security so that it can be restored later if necessary.
Do not turn off the firewall service (mpssvc) since this is the service that enforces Windows Service Hardening restrictions. Instead, use the Windows Firewall APIs to modify the firewall state to "OFF" so that the firewall is effectively disabled but the Windows Service Hardening restrictions are still in place.

To protect users, you should only disable Windows Firewall with Advanced Security after:

You have successfully turned on your firewall solution with the recommended settings.
You have notified the user that Windows Firewall with Advanced Security is going to be disabled.

Links to Other Resources

Windows Firewall with Advanced Security Reference
Windows Vista Development Center
Devreadiness.org
Newest All Things Appcompat blog entries

Presentations

Windows Vista MUP Changes
Testing Applications on Windows Vista
SQL Server with Windows Vista and Windows Server "Longhorn"
File System and File System Filter Ecosystem Update

Videos

Virtual Labs:
- Windows Vista Readiness Virtual Lab
Feature Intros:
- Application Compatibility with Hatem Zeine—Watch Video
- Application Toolkit with John Melton—Watch Video
- Error Reporting with Jeff Braunstein and Jason Hardester—Watch Video
- Introduction to Default Programs with Ed Averett—Watch Video
- Kernel Mode Signing with Ramesh Chinta—Watch Video
- Networking with Neeraj Garg—Watch Video
- Windows Filtering Platform w/ Madhurima Pawar & Salahuddin Khan—Watch Video
- Windows Resource Protection with RoseMarie FitzSimons—Watch Video
- Windows Vista Logo Programs with Brad Sullivan & Venkat Krishnamachari—Watch Video, Watch Video
- User Account Control with Chris Corio—Watch Video
Windows Vista and Windows Server Codename "Longhorn" and Windows Server "Longhorn": Understanding, Enhancing, and Extending Security Videos
- Part 1: Watch Video (23:23 minutes)
- Part 2: Watch Video (7:33 minutes)
- Part 3: Watch Video (19:16 minutes)
- Part 4: Watch Video (2:50 minutes)
- Part 5: Watch Video (15:12 minutes)

Issues Relevant to Windows Server Codename "Longhorn"

The remainder of this document contains items that are applicable only to Windows Server Codename "Longhorn" and not to Windows Vista.

Active Directory Changes in Windows Server Codename "Longhorn"

Feature Impact

Moderate

Brief Description

Active Directory in Windows Server Codename "Longhorn" provides a new unified model with features such as:

Common architecture and programming model
Administration across domain controllers
Directory services
Rights Management
Federated services
Integration (metadirectory services)
Read-Only Domain controller feature

This model is extensible to application developers and allows connections across organizations to metasystems.

Going forward, some nomenclature changes have been made to provide a consistent naming convention for Windows features related to Active Directory. These include:

Active Directory Domain Controller > Active Directory Domain Services
Active Directory App mode > Active Directory Lightweight Directory Services
Windows Rights Management Services > Active Directory Rights Management Services
Windows Certificate Services > Active Directory Certificate services
Identity integration feature pack > Active Directory Metadirectory Services

Manifestation

Applications not aware of read-only Doman Controller (DC) need to be updated to handle the read-only function. Management applications for Active Directory need to be updated to take advantage of new features and services. Care must be taken to avoid issues when a Read Only Domain Controller (RODC) is placed in a site where a fully functional DC is needed.

To deploy an RODC, the domain controller that holds the PDC emulator operations master role (also known as flexible single master operations or FSMO) for the domain must be running Windows Server Codename "Longhorn." Although in Windows Server Codename "Longhorn" an RODC cannot also be a global catalog server, universal group membership caching is automatically enabled for the site in which the RODC is deployed. In addition, the functional level for the forest must be Microsoft Windows Server 2003.

Remedies

A Read Only Domain Controller is a new type of domain controller in the Windows Server Codename "Longhorn" operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts a read-only replica of the database in Active Directory Domain Services (AD DS) for a given domain.

Before the release of Windows Server Codename "Longhorn", if users had to authenticate with a domain controller over a wide area network (WAN), there was no real alternative. In many cases, this was not an efficient solution. Branch offices often cannot provide adequate physical security that is required for a writable domain controller. Furthermore, branch offices often have poor network bandwidth when connected to a hub site. This can increase the amount of time required to log on; it can also hamper access to network resources.

Beginning with Windows Server Codename "Longhorn", an organization can deploy an RODC to address these problems. As a result, users in this situation can benefit from:

Improved security
Faster logon times
More efficient access to resources on the network

Infrastructure architecture must take RODCs into account when planning out site topologies and costing. Improper site topologies may result in an RODC being the closest DC to a server that needs a fully functional writable DC, like Microsoft Exchange Server. The result of this improper configuration would be high failure rates on the member server.

Links to Other Resources

Windows Server Codename "Longhorn" Roles

Feature Impact

Low

Brief Description

Windows Server Codename "Longhorn" is now completely componentized. The roles for Windows Server Codename "Longhorn" are now highly granular and optional. By default, no server roles are activated. Server roles from prior versions of Windows Server are not exactly the same in Windows Server Codename "Longhorn."

Web Server and Application Server which were one role in Win2k3 and are now split into two roles for Windows Server Codename "Longhorn."

Manifestation

Installation instructions and scripts may break or produce improper results.

Remedies

Installation instructions and scripts to install new servers will have to be updated.

Links to Other Resources

Product guide: Introducing the Windows Server Code Name "Longhorn" Operating System
TechNet Webcast: Introducing Windows Server Code-Named "Longhorn"
TechNet Webcast: Installing, Configuring, and Managing Server Roles in Windows Server "Longhorn"

Windows Application Experience in Windows Server Codename "Longhorn"

Feature Impact

Low

Brief Description

Windows Server Codename "Longhorn" does not, by default, install applications and accessories that are considered to be part of a user's desktop experience. These applications can be selectively installed using Server Manager.

Manifestation

Applications and Installers that rely on windows desktop applications and accessories may fail to run or install. Desktop accessories and tools have been removed into a separate feature install since most users of Windows Server do not need desktop applications.

Remedies

Applications dependent upon desktop accessories and tools will need to ensure that they are installed prior to application installation.

Windows Server Codename "Longhorn" Server Core

Feature Impact

Low

Brief Description

Windows Server Codename "Longhorn" introduces a new concept called Server Core. Server Core is a minimal server installation option for computers running on the Windows Server Codename "Longhorn" operating system. Server Core provides a low-maintenance server environment with limited functionality. The server core supports a limited set of roles (AD, DNS, DHCP, File Server) and does not support any application installs. It also does not support .NET functionality; however, it does support development of management tools, utilities, and agents.

Since Server Core is new, it has little impact on current applications. Understanding the limitations of Server Core is imperative to proper implementation for maximum benefit.

Links to Other Resources

Windows Server Codename "Longhorn" Server Core

DLLs included with Server Core

Windows Server Failover Clustering on Windows Server codename "Longhorn"

Feature Impact

High

Brief Description

Windows Server Codename "Longhorn" clustering platform has undergone a revolutionary change. A new set of platform APIs provide better functionality, scalability and easier manageability (including remote management) for clustering environments. Some of the new features include:

Integrated Configuration Validation Tools
Streamlined Cluster Setup
Easy Management of Clusters
Enhanced Quorum Model
Designed for Storage Area Networks
Networking Enhancements
Stretched Cluster Enhancements
Cluster migration tool
Support for Server Core

Manifestation

Applications that rely on current APIs may break or provide incorrect results when used on a Windows Server Codename "Longhorn" Cluster.

Remedies

Applications that support clustering will have to be re-engineered to take advantage of the new clustering platform APIs. Care must be taken to ensure that applications written using older cluster APIs do not get installed and used on Windows Server Codename "Longhorn."

Links to Other Resources

Failover Clustering in Windows Server Codename "Longhorn"

Networking: Windows Firewall Enabled by Default on Windows Server codename "Longhorn"

Feature Impact

Moderate

Brief Description

Windows Firewall is on by default: This means that the application installers need to be aware of the ports that the application uses so that these firewall ports are explicit opened, or to turn off Windows Firewall (recommended only if another firewall is installed).

On Server, Server Roles and Optional Components are aware of the firewall and will plumb firewall rules automatically upon installation. Conversely, the same components and roles will remove their firewall rules when they are uninstalled.

Manifestation

Legacy application installers may break because dependent TCP/IP ports will not be open by default.

Legacy applications may break after installation because dependent TCP/IP ports will not be open by default. On Vista, client applications will prompt the user for a decision to Allow or to Keep Blocking the application. On Server, there's no such prompt. Instead, a Security audit event is logged to signal that an application was blocked.

Remedies

For legacy application installers, the ports need to be explicitly opened by an administrator, or turn Windows Firewall off.

Administrators can leverage:

The "netsh advfirewall" context to work with firewall rules from scripts.
Security Configuration Wizard templates to configure their Servers only

Developers can leverage:

The INetFwPolicy2 Firewall APIs to integrate their installers with the Windows Firewall with Advanced Security

次の方法で共有

The Windows Vista and Windows Server 2008 Developer Story: Application Compatibility Cookbook

Contents

Introduction

Quick Compatibility Check

Working with a Clean Installation of Windows Vista

Working with an Upgrade to Windows Vista from Windows XP Service Pack 2

Links to Other Resources

Operating System Versioning

Feature Impact

Brief Description

Manifestation

Mitigation

Remedies

User Account Control (Standard User Changes)

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

UAC: Application Update Guidelines

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

UAC: COM Per-User Configuration

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Windows Resource Protection (WRP)

Feature Impact

Brief Description

Manifestation

Mitigations

Remedies

WRP protected keys

Links to Other Resources

Internet Explorer Protected Mode

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Windows 64-bit

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

IIS 7

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Microsoft Graphical Identification and Authentication (GINA)

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Session 0 Isolation

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Networking: TCP/IP Stack and the Windows Filtering Platform

Feature Impact

Brief Description

Manifestation

Remedies

Links to Other Resources

Networking: Kernel Mode IP Helper APIs

Feature Impact

Brief Description

Manifestation