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.
Thursday, 24 July 2008
Saturday, 19 July 2008
Application Compatiblity and Ageing Applications
Ageing Applications and Vista Compatibility
I still maintain that most applications will work under Vista and Longhorn (just today re-branded as Windows Server 2008) but by reading this blog you might think that there are quite a few issues. My gut feeling is on application compatibility is will follow a sliding scale of something like:
1 year-old application - 95% will be compatible with Vista
2-4 year-old application - 90% will be compatible with Vista
4-7 year-old application - 80% will be compatible with Vista
8 years and older applications - 50% will be compatible with Vista
What drives these kind of numbers? Not hard-core scientific research but experience with thousands of applications from Windows 3.1, NT4, 2K and Windows XP.
Hence, the reference to "gut feel". That said, these estimates can be backed up by the following events;
1) In 2005 Service Pack 2 (SP2) introduced a majority of the restrictions that are now in place with Windows Vista. Excluding the new UAC functionality, most the local registry, local machine IE restrictions were expected to cause a large issue with corporate applications with the release of SP2 - the reality was the only a small proportion of applications were affected.
2) In 2003, Microsoft released Windows XP with a new driver model and enhanced application compatibility support for legacy applications. This is the big hurdle for most developers (excluding driver developers) - if you got your application working on XP - then you are likely to get most of the application working on Vista and Windows Server 2008. The driver developers had to pretty much start again.
3) From 2001-2002 Vendors starting delivering application installations in the MSI format moving from the early days of a few poorly constructed MSI's (some packages were just Setup.exe's within a single custom action inside an MSI) to the present where roughly 80% of applications are shipped in the MSI format. Note: an install may be released an SETUP.EXE but really is a boot-strap MSI.
4) In 2000, Windows Installer started the installation standardization process that allowed vendors and corporate IT system administrator to rationalize their application management strategies to a single deployment technology (MSI) thus removing two of the primary reasons for application installation failure;
- Non-standard installation technology
- Non-transparent installation logic
It may seem straight-forward but vast majority of application failures are due to poor application installation routines.
5) Most application in use today that were shipped pre-Windows 2000 would have been targeted for Windows NT 4 or 3.51 and may have dependencies on 16-bit components or the NT driver model. These older applications represent the greatest challenge to application compatibility on Windows Vista.
But hey, that's why we can use SoftGrid under Citrix to deliver these legacy apps. No more need for kiosk machines (aka total security liability).
I still maintain that most applications will work under Vista and Longhorn (just today re-branded as Windows Server 2008) but by reading this blog you might think that there are quite a few issues. My gut feeling is on application compatibility is will follow a sliding scale of something like:
1 year-old application - 95% will be compatible with Vista
2-4 year-old application - 90% will be compatible with Vista
4-7 year-old application - 80% will be compatible with Vista
8 years and older applications - 50% will be compatible with Vista
What drives these kind of numbers? Not hard-core scientific research but experience with thousands of applications from Windows 3.1, NT4, 2K and Windows XP.
Hence, the reference to "gut feel". That said, these estimates can be backed up by the following events;
1) In 2005 Service Pack 2 (SP2) introduced a majority of the restrictions that are now in place with Windows Vista. Excluding the new UAC functionality, most the local registry, local machine IE restrictions were expected to cause a large issue with corporate applications with the release of SP2 - the reality was the only a small proportion of applications were affected.
2) In 2003, Microsoft released Windows XP with a new driver model and enhanced application compatibility support for legacy applications. This is the big hurdle for most developers (excluding driver developers) - if you got your application working on XP - then you are likely to get most of the application working on Vista and Windows Server 2008. The driver developers had to pretty much start again.
3) From 2001-2002 Vendors starting delivering application installations in the MSI format moving from the early days of a few poorly constructed MSI's (some packages were just Setup.exe's within a single custom action inside an MSI) to the present where roughly 80% of applications are shipped in the MSI format. Note: an install may be released an SETUP.EXE but really is a boot-strap MSI.
4) In 2000, Windows Installer started the installation standardization process that allowed vendors and corporate IT system administrator to rationalize their application management strategies to a single deployment technology (MSI) thus removing two of the primary reasons for application installation failure;
- Non-standard installation technology
- Non-transparent installation logic
It may seem straight-forward but vast majority of application failures are due to poor application installation routines.
5) Most application in use today that were shipped pre-Windows 2000 would have been targeted for Windows NT 4 or 3.51 and may have dependencies on 16-bit components or the NT driver model. These older applications represent the greatest challenge to application compatibility on Windows Vista.
But hey, that's why we can use SoftGrid under Citrix to deliver these legacy apps. No more need for kiosk machines (aka total security liability).
Saturday, 12 July 2008
Microsoft has recently updated the Group Policy objects (GPO's) for managing Windows Vista. These GPO's are essential for managing the security and local machine configuration for Vista and for the general day-to-day management of the platform.
There is now a new download (VistaADMX- RTM.msi) located here:
http://www.microsoft.com/downloads/details.aspx?familyid=05D0598B-95F9-4BDD-AF36-B365D68EC5F6&displaylang=en
This update includes approximately 2500 registry settings and is composed of a number of ADMX files (XML files with the Group Policy object name and the registry settings).
Our team had a quick review of the Group Policy settings and the corresponding registry changes and decided to build a WorkBench Plug-in that scans for each of these settings.
We thought, it would be "bad practice" for an application package to change or update these core local machine and user settings. This new Plug-in analyses each application package for entries that match the registry settings contained within these 2500+ GPO reference and if an item is detected an automated clean-up solution is provided.
The Vista Group Policy Analysis scan is now available for download under the Downloads section of the website and is included with the 1.06 Release of the Platform Integrity Report Pack.
To learn more about Group Policy objects refer to the following links;
Step by Step guide for Managing ADMX files And Deploying Group Policy using Windows Vista
There is now a new download (VistaADMX- RTM.msi) located here:
http://www.microsoft.com/downloads/details.aspx?familyid=05D0598B-95F9-4BDD-AF36-B365D68EC5F6&displaylang=en
This update includes approximately 2500 registry settings and is composed of a number of ADMX files (XML files with the Group Policy object name and the registry settings).
Our team had a quick review of the Group Policy settings and the corresponding registry changes and decided to build a WorkBench Plug-in that scans for each of these settings.
We thought, it would be "bad practice" for an application package to change or update these core local machine and user settings. This new Plug-in analyses each application package for entries that match the registry settings contained within these 2500+ GPO reference and if an item is detected an automated clean-up solution is provided.
The Vista Group Policy Analysis scan is now available for download under the Downloads section of the website and is included with the 1.06 Release of the Platform Integrity Report Pack.
To learn more about Group Policy objects refer to the following links;
Step by Step guide for Managing ADMX files And Deploying Group Policy using Windows Vista
Tuesday, 8 July 2008
Patch Tuesday - July 2008
Hi,
This is one of the initial views on the AOK Patch Impact Assessment of Microsoft's Patch Tuesday Security bulletin update.
Let me know what you think of the following;
The July release of Windows updates and patches includes the following critical patches;
1. Microsoft Security Bulletin MS08-030: Vulnerability in Bluetooth Stack Could Allow Remote Code Execution (951376)
2. Microsoft Security Bulletin MS08-031: Cumulative Security Update for Internet Explorer (950759)
3. Microsoft Security Bulletin MS08-033: Vulnerabilities in DirectX Could Allow Remote Code Execution (951698)
Further details can be found about these patches on the following Microsoft site;
http://www.microsoft.com/technet/security/bulletin/MS08-jun.mspx?
Using the Patch Impact Assessment functionality found in the ChangeBase AOK WorkBench tool-set, we analysed just under 700 unique applications and generated the following results;
The following table illustrates the number of application "overlaps" or conflicts with each listed patch. Where the RAG (Red, Amber, Green) icons indicate the corresponding risk to deployment of each patch on this sample application portfolio.
This is one of the initial views on the AOK Patch Impact Assessment of Microsoft's Patch Tuesday Security bulletin update.
Let me know what you think of the following;
The July release of Windows updates and patches includes the following critical patches;
1. Microsoft Security Bulletin MS08-030: Vulnerability in Bluetooth Stack Could Allow Remote Code Execution (951376)
2. Microsoft Security Bulletin MS08-031: Cumulative Security Update for Internet Explorer (950759)
3. Microsoft Security Bulletin MS08-033: Vulnerabilities in DirectX Could Allow Remote Code Execution (951698)
Further details can be found about these patches on the following Microsoft site;
http://www.microsoft.com/technet/security/bulletin/MS08-jun.mspx?
Using the Patch Impact Assessment functionality found in the ChangeBase AOK WorkBench tool-set, we analysed just under 700 unique applications and generated the following results;
The following table illustrates the number of application "overlaps" or conflicts with each listed patch. Where the RAG (Red, Amber, Green) icons indicate the corresponding risk to deployment of each patch on this sample application portfolio.
Saturday, 5 July 2008
Another look...
OK, so we had a nice (but brief) Introduction to the problem of application compatibility on Windows XP and Vista. So where do we go from here? And, what help is out there right now?
Microsoft has done a pretty good job of trying to manage application compatibility issues since Windows 2000 with the introduction of the Application Compatibility Tool-kit (now at version 5 for Vista) which is available here: www.microsoft.com/technet/desktopdeployment/appcompat/toolkit.mspx
In addition, Microsoft offers some pretty in-depth advice for software developers on how to ensure that your application will comply with the Logo certification program. You can find the latest version here that details the requirements for Windows Vista and Windows 2003: http://msdn.microsoft.com/certification/appspec.asp
There are plenty of other, more detailed resources including:
Low-level System Compatibility located at: http://www.microsoft.com/whdc/system/vista/default.mspx
and Developer Best Practices for working in a least privileged environment: http://msdn2.microsoft.com/en-us/library/aa480150.aspx
And my favorite is the Developers Story - Compatibility cookbook is located here: http://msdn2.microsoft.com/en-us/library/aa480152.aspx
This is the THE bible for getting applications working under Vista, working through the security restrictions with Windows XP Service Pack (XPSP2). This rather lengthy document details not only what the issues are, but provides some clues as to what is causing the problems. As GI Joe said, "Knowing the problem, is half the problem."
More details coming soon...
Microsoft has done a pretty good job of trying to manage application compatibility issues since Windows 2000 with the introduction of the Application Compatibility Tool-kit (now at version 5 for Vista) which is available here: www.microsoft.com/technet/desktopdeployment/appcompat/toolkit.mspx
In addition, Microsoft offers some pretty in-depth advice for software developers on how to ensure that your application will comply with the Logo certification program. You can find the latest version here that details the requirements for Windows Vista and Windows 2003: http://msdn.microsoft.com/certification/appspec.asp
There are plenty of other, more detailed resources including:
Low-level System Compatibility located at: http://www.microsoft.com/whdc/system/vista/default.mspx
and Developer Best Practices for working in a least privileged environment: http://msdn2.microsoft.com/en-us/library/aa480150.aspx
And my favorite is the Developers Story - Compatibility cookbook is located here: http://msdn2.microsoft.com/en-us/library/aa480152.aspx
This is the THE bible for getting applications working under Vista, working through the security restrictions with Windows XP Service Pack (XPSP2). This rather lengthy document details not only what the issues are, but provides some clues as to what is causing the problems. As GI Joe said, "Knowing the problem, is half the problem."
More details coming soon...
Subscribe to:
Posts (Atom)