Thursday 24 July 2008

Microsoft Program Compatibility Assistant

For this blog, I thought that I would spend a little time looking at some of the compatibility features included in Windows Vista. I wasn't surprised to learn that Microsoft views application (and driver) compatibility as a vital element to the migration effort to Windows Vista. Microsoft internally has placed a number on application compatibility somewhere near $60 Billion over the next five years. Meaning that just getting and keeping things working on Vista is worth $1,000,000,000.00 a month to Microsoft. That should focus the mind, eh?

Windows Vista delivers a number of compatibility features beyond the compatibility layers introduced in Windows XP (and enhanced in Service Pack 2). One of the more interesting compatibility functions delivered by Microsoft is the Program Compatibility (PCA) Wizard which analyses the following;

- Application installation routines (including un-installation)
- Application Updates and Patches
- Application Re-Installs (but not MSI driven Repairs)
- Application Loads
- Session Startup events
- Verification of post-install application events

This compatibility tool is "baked" into Windows Vista but is NOT available on any of the Microsoft server products - this includes Longhorn.

Surely, getting applications working on the server platform would be just as important as the desktop. Maybe Microsoft's answer will be the hyper-visor virtualization technology. But, as we found out this week from WinHEC 2007, we are going to have to wait a while - for OS level virtualization to be integrated into the server OS will not be released until the end of this year and I feel that we will have to wait another 9-12 months for a service pack before this technology is ready for production deployment.

Getting back to the Microsoft Program Compatibility Assistant, there are 3 main scenarios where the PCA is used;

- Detecting application installation failures
- Detecting program failures under UAC
- Assessing startup failures

The PCA monitors application installation actions through a heuristic or "recipe" approach that will display a dialog box if a known application compatibility problem exists with that application and where a "compatibility layer" fix is available. These layer fixes effectively deliver Windows XP SP2 compatibility. The thinking here is that if the application worked under XPSP2, then it will also work with the Vista "XPSP2" compatibility layer applied. I will discuss compatibility layers in-depth in a later blog as this is a huge area (so big, that there should be a Oreilly book on the topic)

When it comes handling application errors with the User Account Control feature, the PCA will analyze the detected compatibility issue and automatically raises the process' security profile (using ElevateCreateProcess) so that next time the application is loaded, the application just works. Microsoft is so confident about this process, that there are no configuration options for the PCA and UAC.

When it comes to application startup issues, the Program Compatibility Application (PCA), there are two main approaches; limited application compatibility issues and sever compatibility limitations. When an application is loaded in the "startup" session three events are likely to be triggered by the PCA. The PCA will display a dialog box relating to the application compatibility issue and deliver one or all of the messages.

· Pointing the user to an update from the software vendor for that program.
· Pointing the user to an Software vendor website for more information.
· Pointing the user to a Microsoft Knowledge base article for more information.


I think more automated fixing could be done here - Microsoft has intimate knowledge of what works and what does not? More on this question, in my next entry.

1 comment:

Chris Jackson said...

I actually believe that PCA is remarkably non-interesting for the enterprise end-user. Why have the application fail once? Those doing the testing can note the shims applied, and if they worked. If so, then why have the end users ever see that failure? Fix it and deploy an SDB before the user ever runs the app.