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.
- They only check the dwMajorVersion (These application will only install in Windows 2000,XP and Server 2003)
- They hardcoded the Version checks { if (majorVersion = 5 && minorVersion = 1) } (These application will only install in Windows XP)
- 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 !!
Mitigations
For new applications,
- Best Practice is to check for features instead of versions
- 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.
0 comments:
Post a Comment