Microsoft Windows Installer, Application Compatibility and Deployments

My Slidedeck – Application Compatibility Toolkit 5.5 Overview

This slidedeck was used at the BITPro november monthly UG meet yesterday.

This session gave a detailed explanation of how the ACT 5.5 tool can be used to mitigate the AppCompat issues. Further, an overview of Windows 7 Core OS changes were also discussed to set the context right.

View more presentations from Vijay Raj.
Microsoft Windows Installer, Application Compatibility and Deployments

Libraries, UAC, WRP: Windows 7 AppCompat Series

In this Last part of the AppCompat Series we will look at the Core OS changes which Windows 7 has undergone and how that can affect your applications. We will discuss on areas like UAC (User Account Control), WRP (Windows Resource Protection), Libraries, Removal of Live Gallery applications from the OS and the importance of porting applications for 64-bit architectures.  We will also see on how these issues can be handled.

UAC (User Account Control)

UAC is a security feature that was firstly presented in Windows Vista., and now in Windows 7. UAC enables the user to run as standard user, and elevate only when an administrative operation is performed. The operating system has a File and Registry Virtualization capabilities, through which the system-wide file system (even to the root drive, for eg: C:\) and Registry writes are automatically and silently redirected to per-user locations (VirtualStore) that won’t harm the wider system. This ensures that, the machine is secured and stable.

You can watch these videos to understand these below,

There could be some issues because of this to the existing applications, Like, Custom installers and updaters need administrator privileges to install. The application does unnecessary administrator checks or administrative actions. Also, if there is a custom method written in the app which writes to file or registry locations that are not virtualized there could be an issue of non-functionality.

Mitigation is to apply some common shims like Virtualization shims and ForceAdminAccess shims. To learn how to apply shims, refer Part 1. Applications needing to run as administrator should manifested (if you are the author) or use RunAsAdmin or RunAsHighestAvailable. If this doesn’t solve, as a last resort, relax ACL’s on files and folders (not a best case solution)

Removal of Windows Live Gallery Applications

Windows Mail utility (Outlook  Express) and Movie Maker have been deprecated from Windows 7.

Which means CoStartOutlookExpress API is disabled. Also other software like Messenger, Address Book, Photo Gallery, and Movie Maker are deprecated. All entry points to Windows Mail and Contacts (for example, Start Menu, user-created Shortcuts, Start -> Run, etc.) are removed or disabled. File types (.eml, .nws, .contact, .group, .wab, .p7c, .vfc, etc.) will need to be associated with other applications

A simple Mitigation is to Install Windows Live applications( or applications of your choice.

Developers, remove application calls to API CoStartOutlookExpress or any other API calling Windows Mail.

File Libraries

Libraries are the primary entry points to user data in Windows 7. They are the natural evolution from the user’s Known Folders, including those for documents, pictures, music, and videos. A Library is a user-defined collection of content that represents the user’s data independently from the folder hierarchy. Libraries provide a centralized folder-like experience for file storage, search, and access across multiple locations, both local and remote. The Documents Library is the default location of common file dialogs. The Library is itself a file, and not a folder. Path manipulations can result in errors. GetFolder() returns a file

IFileDialog->GetFolder() +

IFileDialog->GetFilename() breaks with libraries

Mitigation for your existing applications should be that, when using IFileDialog, you must use GetResult method in conjunction with the shell APIs instead of manipulating the folder path directly.

To Learn more on Libraries – Read the Windows Team Blog here

Windows Resource Protection (WRP)

We all know that, Windows XP and earlier versions of Windows protect system related files.  This process was called Windows File Protection (WFP).  These protected files were saved in C:\Windows\System32\dllcache. In Windows Vista and Windows 7, the security is spread even to registries and folders as well.  Hence, this technology is called Windows Resource Protection (WRP). WRP components are saved in C:\Windows\winSxS folder. Application installers that attempt to replace, modify, or delete OS files and/or registry keys that are protected will fail with an access denied error message because the resource could not be updated.

A simple Mitigation is to apply shims for WRP issues. See Part 1, to understand how to create a new shim. IT Pros should never repackage Microsoft redistributables (Use the Microsoft provided redistributable package instead).

Developers should not write any resources to system files and registry keys (if possible, use User profiles folders and HKCU)

64 Bit Applications

Windows Vista and newer operating systems fully support the 64-bit architecture processors from AMD and Intel. The 64-bit version of Windows Vista can run all 32-bit applications with the help of the WOW64 emulator.  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.

Mitigations for this issue is to remove all 16-bit components, and Port 16-bit installers to 32-bit or 64-bit installers. Also it’s important to ensure that all 64-bit drivers are digitally signed.

This completes the AppCompat Series. This series of posts covered information on how the core changes of Windows 7 will affect the Day-to-Day applications. We also saw methods to mitigate the issues from the basic viewpoint of Developers, IT Pros and End-Users.  I will cover a lot more on critical issues as individual posts in the future. I would also recommend Chris jackon’s blog for high level information on Application Compatiblilty.

To get the list of the Applications which are compatible on Windows 7, check this sheet.

For More Compatibility articles, Check here –

The Complete Application Compatibility Series

Microsoft Windows Installer, Application Compatibility and Deployments

Session 0 Isolation and Secure Desktop: Windows 7 AppCompat Series

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

In Windows 7, the OS creates Session 0 for Services and User Mode Drivers, and creates Session 1 for first user logging in. Running services and user applications in two different Sessions avoid the security risk, because services cannot run at elevated privilege and therefore stops malicious agents. Now when we have a legacy application, in which the application which is running in Session 1 invokes a system service and waits for the user’s interaction, UI displayed by this service is not visible as it is running in a secure desktop. Interaction between Session 0 and Session 1 does not happen. Hence an application, which has a Service and user application communicate using window message functions or local objects fail to execute.


How OS Responds

If the application’s service uses a UI, a built-in mitigation in Windows 7 allows the user to interact with the Session 0 UI in a special desktop. This will make available the UI specific to the application, instead of the entire Session 0 desktop. For example – : When we try to convert any document to pdf using the application which uses this mechanism, it throws the Session 0 isolation error message. On Clicking, Show me the message, it takes the user to a secure desktop, where only the dialog/service which is prompting for the user’s interaction will be showed.


Also check out this presentation on Session 0 Isolation – Windows 7

Few developer guidelines involve

  1. Redesigning the application and service to use client or server mechanisms, e.g. Remote procedure calls (RPC) or named pipes. Also, redesign the service to no longer interact directly with the user
  2. 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.
  3. 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 7.
  4. Apply “Session Shim” in the compatibility administrator for fixing these issues and Verify that the application functions properly after applying the Windows XP compatibility mode, which contains mitigation for some of the Session 0 issues.
  5. For other Developer Guidelines, Click here

For More Compatibility articles, Check here –

The Complete Application Compatibility Series

Microsoft Windows Installer, Application Compatibility and Deployments

Install and Setup Virtual XP Mode in Windows 7 – AppCompat Series

3/18/2010 – Update: Windows XP Mode will no longer require hardware Virtualization technology

The Microsoft team announced an update to Windows XP Mode today that will make it a more accessible to PCs in small and midsize businesses who want to migrate to Windows 7 Professional but have applications that still require Windows XP. Windows XP Mode will no longer require hardware virtualization technology to run. This change makes it extremely easy for businesses to use Windows XP Mode to address any application incompatibility roadblocks they might have in migrating to Windows 7. – Read more here on the Windows Team blog

Windows XP Mode is a virtual machine package for Windows Virtual PC containing a pre-installed, licensed copy of Windows XP Service Pack 3 as its guest Operating System. XP Mode provides an additional layer of application compatibility in windows 7, which means that, you will have additional time to migrate your existing applications to the new operating system. XP Mode applications run in a Terminal Services session in the virtualized Windows XP, and are accessed via Remote Desktop Protocol by a client running on the Windows 7 host.

Windows XP Mode will work only under Windows Ultimate, Professional and enterprise flavours


Your hardware should have a virtualization capability such as Intel VT or AMD VT in the CPU and also this feature should be enabled in your BIOS settings (Update: Windows XP Mode will no linder require hardware Virtualization Technology – check the first section of this article).

In addition because XP mode is running a virtual instance of Windows XP; it needs additional RAM and Disk Space.

XP Mode can be downloaded from here!!!

Install the executable which you get as a download, along with the Virtual PC Update. Once installed, you can just trigger it in a single click from the start menu.  A tutorial will also run to help you. Once the setup is done, the XP mode will run in the Virtual PC. You can install all the incompatible applications in the XP mode VM.

startmenu_XPMThis will automatically publish all the shortcuts in the start menu. From there on, you can go to windows 7 start menu, open the application from the (Start Menu->Programs->Windows Virtual PC->Windows XP Mode Applications). You can also pin the application to the start menu or Task bar.

Pre-installed integration components allow applications running within the virtualized environment to appear as if running directly on the host, sharing the native desktop and Start Menu of Windows 7 as well as participating in file type associations.

When you invoke the application for the first time, you will get this below dialog. This is just setting and configuring your Virtual mode. Also, you may see the risk dialog near the system tray.


risk_trayThis signifies that a Proper security is needed – You should consider Windows XP in XP Mode as just another OS on your network. So the deal here is that, you should patch the system, run antivirus on it and keep it protected just like Win 7.

Internet Explorer ver 6 and 8 Flock Together

Many organizations have their internal websites and web applications which have their compatibility concerns while moving to a different browser or a different version of the same browser (IE6 to IE8). Redesigning and modifying this will involve a lot of effort and time. Using the Windows XP Mode, you can have 2 versions of Internet Explorer running on your machine.  This signifies that, you can have your internal web-applications launched from the IE6 (through the Virtual XP Mode).



The Virtualization layer is so well made that, when we go to the default directories from the application, it points to the Windows 7 machine and not the Windows XP Virtual Machine.

For eg: I am running a Adobe reader 7.0 from the Virtual XP mode (see image), and when I did an open file from the File-> Open dialog, I get the Windows 7 Desktop and not the Windows XP machine.

This also takes care of the file extentions. I mean, if you dont have a adobe reader installed on your Windows 7 machine, having a file say, test.pdf will autmatically associate itself to the Adobe reader of the Virtual XP and open the file.

Summing Up

Applications running in Windows XP mode do not have compatibility issues as they are actually running inside a Windows XP virtual machine and redirected using RDP to the Windows 7 host.  As an IT-Pro, you also save a lot of time in training the user on how to run this app in the new OS. It also eases the user to use the applications as if they are running the applications natively from Windows 7.

Graphic intense applications (like 3d games, AutoCAD etc) do not have an optimal functionality in the XP Mode.  Also, some enhancements which can be made to nurture the User Experience is to provide the desktop snapping for left, right screen alignment and Takbar icon of the application (as of now, we get a Virtual machine Taskbar Icon).

For More Compatibility articles, Check here –

Just wanted to add these 2 documents available on the Microsoft download center about Windows 7 XP Mode

The Complete Application Compatibility Series

Microsoft Windows Installer, Application Compatibility and Deployments

Fix Browser Compatibility Issues in Windows 7 – AppCompat Series

Many Web designers use browser detection techniques to ensure that their sites display properly when viewed with specific browsers. Some browser detection techniques encounter problems when viewed with later versions of the browser they’re made for. Internet Explorer has the User Agent String which is the identifier that provides data about its version and other attributes to Web servers. Many Websites and applications rely on the User Agent String to detect the Browser settings.

internet-explorer-8Now the issue is that, web pages that explicitly check the User Agent String and do not support the Internet Explorer 8 User Agent String may not run properly. Applications that host Trident will default to Internet Explorer 7 using the Web Optional Component, but will not have access to Internet Explorer 8 features.

A simple Mitigation to this issue would be to ensure that your web applications properly handle the new ‘MSIE 8.0’ version in the User Agent String. see below for example:

Without compatibility mode:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
With compatibility mode:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)

Also, use Internet Explorer 7 Compatibility View for those applications based on Internet Explorer 7. This can be done either by clicking on the Compatiblity view button or by using meta tags.


See below for meta tag examples.

<!-- Mimic Internet Explorer 7 -->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<title>My Web Page</title>
<p>Content goes here.</p>

IIS Compatibilty mode

<?xml version="1.0" encoding="utf-8"?>
<clear />
<add name="X-UA-Compatible" value="IE=EmulateIE7" />

A best practice to detect IE more effectively, is to detect features and not the browser Version details using the “User Agent String”. You will find this MSDN article handy, when you wanna know a way to detect IE effectively – Here

The Complete Application Compatibility Series

How-to Microsoft Windows Installer, Application Compatibility and Deployments

Create Shims or Compat Modes in Windows 7 – AppCompat Series

In this first part of the AppCompat Series, we will look at the significance of the OS version number change (6.1 in Windows 7) and how will this impact the existing applications. We will also look at the ways to mitigate them. The internal version number for Windows Vista is changed to 6.0 and 6.1 for Windows 7.  The GetVersion function will now return these version numbers to applications when queried { dwMajorVersion (6) and dwMinorVersion (0 or 1) }.

Any application that specifically checks for the OS version may get a higher version number which it may not be designed to handle. Setup packages may prevent themselves from installing and applications may prevent themselves from starting. Summing up, when a developer writes the code to check for the version numbers, there are some potentional issues with few of the applications.

  1. They only check the dwMajorVersion (These application will only install in Windows 2000,XP and Server 2003)
  2. They hardcoded the Version checks { if (majorVersion = 5 && minorVersion = 1) } (These application will only install in Windows XP)
  3. They implemented a wrong condition check { if (majorVersion > 5 && minorVersion > 1) } (Though the check condition loooks correct, this fails on Windows Vista)

The windows Team suggests the developers not to use the Version Numbers Checks in their applications !!


For new applications,

  1. Best Practice is to check for features instead of versions
  2. Look for OS versions greater than (>) compatible OS version

You can get the version numbers for all the Windows OS here

For existing applications,

Method 1: Compatiblity modes – Right click on the executable (StockViewer.exe in this example), goto the compatibilty tab. You will find all the previous operating systems. You can select the version in which it had worked/installed. Click on Apply and close the window.  Now you can invoke the executable.


Method 2: Applying Shims / Layers – If you are planning to deploy this fix to all the machines where this application needs to be installed. You can use this option. In this method, you can create a shim using Compatibilty Administrator and install this shim database file(sdb) file.

Compatibilty Administrator is a part of the Application Compatiblity Toolkit 5.5, which can be downloaded here

Step 1: Launch the Compatiblity Administrator, and create a new application fix


Step 2: Select the Compatiblity modes, Click next, and complete this dialog.


On completing the dialog, you can see the shim which was just created.


Step 3: Install the Shims which was just created.


Step 4: Now launch the application.

You can also deploy this sdb file to all the machines, where this application is to be installed. (you can either export these mitigations as an MSI, or run this in a command line using sdbinst.exe)

Both of these above methods add the Compatibility layers in the registry key – HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\[app path]

PS: This OS fix is only an interim solution and cannot promise complete functionality. Getting back to the Vendor for the compatible version is always a better practice.

The Complete Application Compatibility Series