Export (0) Print
Expand All

Appendix A: Addressing Application Compatibility in Windows Vista

Published: November 30, 2006

The Application Compatibility feature team can evaluate and resolve application compatibility issues in Windows Vista by using ACT 5. As in earlier versions of the ACT, there are tools for collecting application and hardware inventories, analyzing compatibility data, and deploying mitigation packages. ACT 5 is managed centrally from the Application Compatibility Manager. The updated Agent Framework provides additional evaluators specific to Windows Vista.

After collecting and analyzing the compatibility information for the organization, use the Microsoft Compatibility Exchange to share the information with other IT professionals and benefit from their information. The shared compatibility information can greatly reduce application testing time requirements in larger environments.

For more information on ACT 5, see Windows Application Compatibility at http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/default.mspx.

On This Page

Testing Basic Compatibility in Windows Vista Testing Basic Compatibility in Windows Vista
Compatibility Issues Compatibility Issues

Testing Basic Compatibility in Windows Vista

This section provides guidance on testing and evaluating the compatibility of an application on Windows Vista. This simple level of application testing has two scenarios to test: one on a clean installation of Windows Vista and the other on a Windows Vista installation upgraded from Windows XP SP2.

Test Applications on a Clean Installation of Windows Vista

This scenario assumes that Windows Vista has been installed on a freshly formatted computer. This type of installation will quickly expose application compatibility issues caused by deprecated components or specific version changes in the operating system.

  • Normal installation. Install the application on a test computer running Windows Vista. If prompted for permission to install the application, click Permit and continue. If the application completes this step without issue, continue with functionality testing.

  • Elevated installation. If the application installation fails and no installation permission prompt displays, right-click the installer executable file, and then click Run this program as administrator. Attempt to install the program again.

  • Compatibility layer. If errors appear that prevent the application setup from continuing, right-click the installer executable file, click the Compatibility tab, and then select the Windows XP SP2 compatibility mode. Test it again. If the application still fails to install, count it as incompatible and check with the manufacturer for an update.

After installing the application and addressing setup issues, move on to testing the application functionality:

  • Launch the application. If the application did not launch properly or if errors appear, apply the Windows XP SP2 compatibility mode to the application executable file and try again.

  • Perform functionality testing. If the application launches successfully, run through the full suite of tests typically used to test the application on Windows XP. Verify application functionality, and then confirm that the application performs properly.

If the application fails these steps, the changes in Windows Vista have affected it. Check with the application manufacturer for updates to the program or for an upgraded version that does work with Windows Vista.

Test Applications on Windows Vista (Upgrade from Windows XP SP2)

This scenario assumes that Windows Vista has been installed as an upgrade from Windows XP SP2. In this scenario, support files may still be in place on the computer’s hard disk that will enable the application to run normally, whereas the fresh installation would not have these older support files. Test applications in both scenarios to identify the applications that may be affected by missing support files on a fresh installation of Windows Vista.

  • Install Windows XP SP2 on a test computer, and then install the application. Verify that all features of the application work properly before proceeding.

  • Upgrade the test computer to Windows Vista.

  • Launch the application. If the application does not launch properly or if errors appear, apply the Windows XP SP2 compatibility mode to the application and launch the program again.

  • If the application launches successfully, run through the full suite of tests typically used to test the application on Windows XP. Verify application functionality, and then confirm that the application performs properly.

If the application fails these steps, the changes in Windows Vista have affected it. Check with the application manufacturer for updates to the program or for an upgraded version that does work with Windows Vista.

Compatibility Issues

Application compatibility issues that apply specifically to Windows Vista can often be grouped into one of the following areas:

  • Windows Vista User Account Control (UAC)

  • Windows Resource Protection (WRP)

  • X64 platform changes

  • Deprecated components

User Account Control

UAC limits the inherent rights and permissions associated with user accounts in Windows Vista. By default, even administrators are prompted for permissions to perform tasks that might affect the security of the computer. UAC does not have an impact on normal application use, but it may have an impact on applications that require administrative privileges to install or to perform updates.

Windows Vista attempts to detect update processes for installed applications. If it correctly identifies the update program, it is able to automatically elevate the user process and performs the update without prompting the user. Applications that require administrative access to install or to update will prompt the user for credentials to elevate the process by default.

Because limiting user privileges is a core tenet of computer and network security, attempt to eliminate applications that require administrative access to run unless they are required for administrative functions. View the option to elevate the user process, and run the application as an administrator as a workaround and not as a permanent solution.

Most UAC compatibility issues occur either during initial setup or when updating the application. Windows Vista can identify many types of application update programs but may have difficulty identifying the following:

  • Out-of-process updaters. Update programs that run outside the main application’s process.

  • Overloaded executables. Application executables that contain both the main program and the updater in a single binary executable file.

For additional information on resolving UAC compatibility issues in Windows Vista, see “Understanding and Configuring User Account Control in Windows Vista” at http://www.microsoft.com/technet/windowsvista/library/00d04415-2b2f-422c-b70e-b18ff918c281.mspx.

Windows Resource Protection

WRP restricts access to critical operating system files and registry keys. Updates to protected resources are restricted to trusted installers such as Windows Servicing. WRP protects Windows Vista from applications or users who try to replace critical files or settings.

Attempts to replace or alter protected resources may result in:

  • Application installers and updaters that attempt to access protected resources failing with an error message indicating that the resource could not be updated.

  • Attempts to write new registry keys or values to protected registry keys failing with an error message that indicates access was denied.

X64 Platform Changes

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

While most 32-bit applications will run on Windows Vista 64-bit editions, some may encounter issues that may include:

  • Windows Vista 64-bit editions require that all 64-bit drivers be digitally signed. Unsigned drivers are not supported and will not install on 64-bit Windows Vista.

  • Folder path changes include separate Program Files folders for 32-bit and 64-bit applications.

Deprecated Components

Each new operating system incorporates new features and occasionally removes, or deprecates, old components. Applications that depend on those removed components may fail to run or may lose functionality. This compatibility issue ranges from changes to API calls to support components being removed from the operating system.

Some of the changes most likely to have an impact on existing applications include the following:

  • Printer drivers can no longer be loaded in kernel mode. In Windows Vista, all printer drivers are required to follow the User-Mode Driver Framework (UMDF). For more information, see the “Introduction to UMDF” at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/umdf_d/hh/UMDF_d/umdfobjectdg_6a21eab3-a7eb-4aa8-b517-578024932e26.xml.asp.

  • Services for Macintosh are not included in Windows Vista.

  • Direct3D Retained Mode (D3DRM) is not included in Windows Vista.

  • Windows Vista does not provide Network Dynamic Data Exchange (NetDDE) support to applications. As a workaround where possible, use a network communication technology such as DCOM or Windows Communication Foundation (WCF).

  • Microsoft Office FrontPage® server extensions are not included in Windows Vista.

Help and Support Center

The Help and Support Center (HelpCtr.exe), designed for Windows XP and Windows Server 2003, displayed compiled Help files with the .chm file name extension. The Help and Support Center is not included in Windows Vista, and its features are not supported. Compiled Help (.chm) files can be displayed in Windows Vista if opened directly and not through the Help and Support Center.

Assistance Platform Client

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

In Windows Vista, original equipment manufacturers (OEMs), system builders, and enterprise customers under license agreement with Microsoft can customize the Assistance Platform client, but non-Microsoft programs cannot use it. For more information on customizing the Assistance Platform client, see the Windows SDK.

Windows Vista Display Driver Model

Windows Vista employs a new driver model for display devices. The Windows Vista Display Driver Model (WVDDM) provides support for features including the new “glass” interface, the ability to change video drivers without restarting the computer, and dynamic recovery of graphics processor hang conditions.

Most applications should be fully compatible with WVDDM. However, some older applications may suffer from compatibility issues in the following areas:

  • Microsoft DirectX® game compatibility may suffer, where the games expect functionality that is no longer supported.

  • Mobile functionality like hotkey, cloneview, brightness, and zoom may not function correctly.

  • Accessibility applications designed for Windows XP, specifically screen magnification utilities, may not work on Windows Vista.

Safe Exception Handling

Many older applications have used functions such as IsBadReadPtr and IsBadWritePtr to validate call parameters. These functions are not supported on Windows Vista. Applications that rely on these functions to validate parameters will fail.

The preferred method to provide Safe Exception Handling (SEH) is to provide adequate error-checking routines in the application itself rather than relying on Windows to handle application exceptions.

Fast User Switching

Fast User Switching (FUS) is available on all versions of Windows Vista, including computers that are members of a domain. Applications need to be able to handle multiple user sessions and terminal server scenarios. For more information on FUS, see “Microsoft Windows XP Fast User Switching: Design Guide for Building Business Applications” at http://go.microsoft.com/fwlink/?LinkId=62693.

CriticalSection Code Changes

The operation of CriticalSection code was changed in Windows Vista. Applications using critical section locks:

  • Should always initialize critical sections.

  • Should not read into undocumented objects to look for uninitialized and freed critical sections.

  • Should prevent thread “starvation.” Applications that call Sleep while holding the critical section lock may cause starvation conditions for other threads that need the lock. To prevent this situation, issue the LeaveCriticalSection call before issuing the Sleep call.

For more information, see “Critical Section Objects” at http://go.microsoft.com/fwlink/?LinkId=62692.

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft