Monday 29 September 2008

Microsoft Program Compatibility Assistant

I was working my through some our compatibility checks this morning when I realized that it had been a few months since I last read the Vista Application Compatibility cookbook. This is a rich-text of application compatibility resources and every once in a while, it's worth a re-read.

One section caught my eye - the Program Compatibility Assistant, which is part of the Vista OS and monitors how applications install and how application behave in a run-time environment. 

In Microsoft's own words; 

"The Program Compatibility Assistant (PCA) is a new feature in Windows Vista® and Windows Server® 2008 that can make older programs that have compatibility problems work better in an automated manner. PCA monitors programs for known issues. If an issue is detected, PCA notifies the user of the problem and offers to apply solutions that will be effective before the user runs the program the next time."

There are a number of features to the PCA including;

  • Detecting Failures in Setup Programs
  • Detecting Program Failures under UAC
  • Detecting Program Failures While Trying to Launch Installers
  • Detecting Installers That Need to Be Run as Administrator
  • Detecting Legacy Control Panels That Might Need to Run as Administrator
  • Detecting Program Failures Due to Deprecated Windows Components
  • Detecting Unsigned Drivers on 64-Bit Platforms

I had a pretty good handle on the installation, legacy control panel issues, administrator requirement scenarios and the 64-bit driver installation issues but the Deprecated components area needed some more research.

I have seen the PCA pop-up dialog boxes a number of times, most commonly to advise the user that the application in question required access to a DLL that is no longer available on Windows Vista; a prime example is an application having a dependency on MSVBM50.DLL.

This got me thinking; What algorithm is the PCA using to determine a missing/deprecated component?

Is it;

1) Comparing missing dependencies against a list known missing DLL's?
- If so, are these files documented somewhere?
2) Hooking in the EXE loader (NT.DLL) and logging all failed loads

My thinking is that this is a bit reactive. We should be able to, prior to deployment be able to determine  which applications will experience runtime PCA issues relating to deprecated components.

I suggest the following analysis. Each package should have all of its dependencies  listed for each file contained in the target application package against;

- The target operating system
- All deployed middleware
- What files are contained within the package
Remember, this not about Vista compatibility, but about your build of Vista , your middleware in your environment and your packages.


1 comment:

Chris Jackson said...

Yes, it's totally reactive. The target audience is the consumer, where a single failure followed by success is far superior to infinite failures. But the fixes PCA applies are either shims or dropping bits, and in the enterprise you have complete control over that. It's far superior to just fix the problem up front and have the end user experience 0 failures. I typically advertise this as a testing feature, and to consider turning it off in production. Particularly if you are planning a standard user deployment, in which case about half of your choices result in the RUNASADMIN layer, which is equivalent to "make this never work for me again."