Windows 7 Application Compatability - Part 1

by Peter Murray 3. July 2009 07:28

Windows 7 Application Compatibility – Part 1

Define the Problem

When moving to a new Operating System platform there are number of factors and potential issues to consider, but probably one key burning question is: Will all my applications still work as before?

The short answer is: Probably Yes, but to have some degree of absolute certainty, requires understanding a bit about Windows Application Compatibility works and what the features and areas are that change in the new Operating System, which could cause applications to break.

Needless to say, this is quite a big topic and covers a number of tools, processes and remediation paths that are all tied up as part of what Microsoft calls the Application Compatibility Toolkit

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971 (and why I’ve decided to split this up into a series of successive posts)

Understand the Rules of the Game

However to start this off, I’d like to cover how all Windows Versions (Since Windows 2000) have dealt with the problem of application compatibility, because once you understand the basics, knowing which applications might be at risk and how to fix them-up if they are affected, becomes a whole lot simpler.

All version of Windows (since Windows 2000) include a database of application compatibility fixes automatically installed by setup or updated through service pack upgrades (for Windows 7, in the c:\windows\apppatch folder). There’s no interface built into windows to view or amend this database, but it can be viewed using the Compatibility Administrator Tool that is installed as part of the Application Compatibility Toolkit.

The picture below shows a selection from the Compatibility Administrator tool and details how Access 97 (as an example) is made to run on later Windows versions:

The Interesting part, is the Compatibility Fixes and these are made up of 3 mitigations (often referred to as “Shims”) that do the following:-

Redirect Files

CorrectFilePaths: Is the application trying to write to a protected location? Is it using hard-coded paths to save something, but special folders (%WinDir%, %Userprofile%) are now in new locations and/or naming structure, CorrectFilePaths, with no options specified, will correct many of the most common file redirection locations using a number of default fixes.

Virtual Registry

Just as Redirect Files deals with changes to file structure and prevents the application from writing to protected locations as a “Standard User”, this shim does the same for the Windows registry.

Lie About the Operating System Version

WinNT4Sp5VersionLie: Many applications check the version of the operating system and behave differently when they detect you are running versions they are not aware of. This can often be resolved, simply just by pretending to be an older Windows version number. There are several version lies to choose from, including all Windows Versions Post Windows 95

Fixing the Problems

Obviously is unlikely that anyone would really want to use Access 97 on Windows 7 (though thanks to it’s built in Compatibility Shim it would work fine) and this is just an example. However, the same issues are among the most common fixes that are used when addressing compatibility issues with individual applications that might not be already accommodated in the built-in compatibility database.

Specific examples and many more ways to provide Application remediation and these and some of the other tools and techniques available will be covered in the follow-up parts to this blog posting

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Bookmark and Share

Tags: ,

Category: Windows 7 No. of views: 4436

Add comment


 

  • Comment
  • Preview
Loading