Welcome to the first Guest Blogger post here at

Vijay Raj is a Microsoft MVP and his contact info is at the bottom of this article.

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 potential 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 looks 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: Compatibility modes – Right click on the executable (StockViewer.exe in this example), go to the compatibility 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 Compatibility Toolkit 5.5, which can be downloaded here

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


Step 2: Select the Compatibility 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.

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.

This completes the fixes for the OS version numbers. There are few more areas like UAC, Session 0, IE 8 etc.. We will look at these in the subsequent articles in this AppCompat series.

Thanks for reading !!

About the Author:

clip_image001Vijay is a Microsoft MVP in the stream of Setup and Deploy. He writes a technology blog called In his blog, Vijay writes on Application development techniques, Deployment guidelines, Windows Installer (MSI) Packaging tips and Windows 7 Tricks.

To subscribe to blog, check this –