Wednesday 7 October 2009, 10:07 AM
Application Compatibility: Microsoft Shims
I was doing some thinking about a central database of application compatibility shims. Shims are a Microsoft application compatibility technology that is "baked" into the Windows 7 operating system to assist with installation and run-time compatibility issues.
I have a couple of concerns regarding the implementation/deployment of these compatibility shims – but these may be more due to my ignorance rather than the limitations of the design/deployment of this compatibility technology.
First, is that the shim is “attached” to the application object and is not related to the user and second, I have found it hard to separate shims into “machine” shims and "user" shims; effectively separating changes to the target desktop or server environment based on machine or user privileges .
This is important for deployment reasons and that we may not want to apply a particular shim to a particular user on a particular machine or a particular machine etc… you get the kind of matrix of deployment scenarios that one could encounter - a pretty complex mesh of possibilities here.
So, following along these lines, I wanted to move up the problem tree and start dealing with the compatibility problem on a larger (let’s call it Enterprise) level.
Some of the things that I would require from an application compatibility framework/approach would include the following “pillars”;
- Leverage existing management approaches and technologies covering
- Deployment
- Reporting/Audit
- Updating/Removal
- Support for central management, remote access and disconnected use
- Support for machine, user, grouping and domain focused management
- Support for versioning, incremental updates and roll-backs
Using these pillars of Enterprise Compatibility Management, my thinking led me to use Active Directory as a central store for all compatibility settings. These GP objects would contain either the machine or the user appropriate settings for each app compatibility issue and would benefit from both GPO deployment and reporting technologies.
Monday 5 October 2009, 1:39 PM
Windows 7 to come in 'Steve Ballmer' edition
For Steve Ballmer fans, Microsoft plans to release a special edition of Windows 7 Ultimate that comes in a package with the chief executive's signature on the front.
The software maker did the same thing with Vista, Ina Fried of CNET News.com points out, but that time it was Bill Gates whose autograph adorned the packaging.
It looks like that for now, only people who have signed up to host a Windows 7 launch party are going to get their hands on it. For more on the Ballmer version of Windows 7, take a look at the CNET News.com story.
Monday 5 October 2009, 10:34 AM
API Calls that break under Windows 7
As mentioned in the Microsoft Compatibility tool-kit, the Developer cookbook and Microsoft Developer Network (MSDN - see references below) there is a section called "Safe Exception handling" under Windows 7 that refers to the deprecation (end of support and removal from the operating system) for two Application Programming Interfaces (API's) under Windows 7 and Windows Server2008.
These two API calls (IsBadReadPtr and IsBadWritePtr) relate to the handling of pointer to the global memory stack used by Windows. These API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.
Microsoft has removed support for the two API's for security reasons and Windows 7 and Windows 2008 Server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;
· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server
The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.
Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e. not a developer testing or debugging mode). To generate an accurate assessment of these API related issues, you will need to ensure that you are scanning the IAT table for files (EXE's and DLL's) that are actually going to be installed on the target platform.
Once done, you should see relatively few instances of this particular application compatibility issue across your application portfolio.
For further reading, please have a loo at the following links;
IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx
IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx
Thursday 1 October 2009, 7:11 AM
6 Laws of Application Compatibility
There is much in the news about migrating to Windows 7 recently. Of prime concern is application compatibility which when simply put means getting applications to work on the target desktop or server environment. There is a lot of complexity in getting applications working - whether on Windows XP or Windows 7 or the recently released Windows Server 2008.
And this is where I think there is some general confusion. Application compatibility is not simply about getting applications to function or work correctly on an Operating system such as Windows 7. Unfortunately, you more work to do. Getting applications to work really means getting the application to work on the target platform which involves the following;
1. Ensuring Operating System (e.g. Windows 7 ) compatibility
2. Ensuring the availability of the complete and correct versions of middleware
3. Ensuring that applications do not conflict with each other (on install and un-install)
4. Ensuring that user environment is correctly setup and available
Breaking the application compatibility question into these four layers delivers a fundamental step change in the understanding and resolution of application compatibility issues. No longer can we just get one application to work on a desktop, we need to get several or even tens of applications to successfully install, update and un-install without breaking other applications. We now have large, complex and constantly changing middleware layers (Java, Crystal Reports, ODBC) that applications depend upon.
Adding to the confusion, differing applications may require different versions of middleware components or worse, may ship from the software vendors with incomplete ("middleware fragments") dependencies which may allow the application in question to function but may prevent another application from working or even installing successfully. Viewing application compatibility with these four layers in mind requires a paradigm shift; to the Platform Integrity model which takes into account all of the requirements to successfully install, use and maintain applications.
To further this goal, we have developed the "AOK Laws of Application Compatibility" which include;
1. Enable the installation package to install successfully
2. Provide the application the required privileges and security access levels
3. Ensure that the required dependencies (middleware) are available and complete
4. Ensure that applications do not conflict with each other on installation, updating/patching or un-installation
5. Ensure that the user environment is correctly configured
6. Ensure that future changes/patches/updates do not adversely affect any of the four layers; the OS, the Middleware layer, Applications or the User Environment
When you follow these guidelines, your chances of successfully developing, deploying and maintaining your application portfolio are significantly increased; today and when dealing with future changes.
Tuesday 29 September 2009, 7:51 AM
PCA: 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 7. I wasn't surprised to learn that Microsoft views application (and driver) compatibility as a vital element to the migration effort to Windows 7. 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 7 is worth $1,000,000,000.00 a month to Microsoft. That should focus the mind, eh?
Windows 7 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 7 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 7 "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.
Wednesday 23 September 2009, 3:54 PM
Microsoft Virtual Round Table - Part 2
I was lucky enough to be invited to the initial Application Compatibility focused Microsoft Virtual Round Table session that was televised a few months back. I really enjoyed chatting with Mark Russinovich, Jeremy Chapman and especially appreciated Gov Maharaj's thoughts on application compatibility issues with Windows 7.
If you missed the 1st session (filmed and then broadcast live), you can catch a replay of the video here: http://www.computertech4u.com/the-springboard-application-compatibility-vrt-rebroadcast-is-live/
And, a direct link to the video here: http://technet.microsoft.com/en-us/windows/dd981014.aspx?ITPID=sprblog
Well, I am back again.
This time, the boys and I will be discussing Microsoft Virtualization issues. The link (for scheduling and viewing details ) can be found here: http://www.computertech4u.com/springboard-series-virtual-roundtable-windows-7-application-compatibility-part-2-virtualization/
For this session, we plan to cover the following topics;
Microsoft App-V
Microsoft Med-V
Windows XP Mode
Windows 7 Compatibility issues
Should be fun...
Once the video is posted online for this session, I will update this Blog posting.
Tuesday 22 September 2009, 2:27 PM
Ageing Applications and Windows 7 Compatibility
I still maintain that most applications will work under Windows 7 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 Windows 7
2-4 year-old application - 90% will be compatible with Windows 7
4-7 year-old application - 80% will be compatible with Windows 7
8 years and older applications - 50% will be compatible with Windows 7
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 Windows 7. 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 Windows 7 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 Windows 7.
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).
Monday 21 September 2009, 7:40 AM
Application Compatibility: A Starter for Ten
OK, so we had a nice (but brief) Introduction to the problem of application compatibility on Windows XP and Windows 7. 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 Windows 7) 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 Windows 7 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/Windows 7/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 Windows 7, 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."
Thursday 17 September 2009, 11:36 AM
What causes compatibility problems for Windows 7
Hi... Getting my "writing style" up to the right level will take a little while but I really hope that the topic of application compatibility will be well represented here.
As you could guess, the real focus for this blog will be application compatibility issues on Microsoft desktop and server products
Working with the fine technical people Microsoft it appears that most application compatibility issues for Windows 7 will stem from the following issues;
1. Driver incompatibility (Display, Printer peripheral devices)
2. Legacy 16-bit Memory Issues
3. Networking Restrictions
4. Security Restrictions
If you are using specific drivers for DVD writers or relying on TWAIN drivers for your Scanner, you will probably have to get an upgrade from the software vendor. And if you are still dependant on the really old 16-bit applications (poor you) there is a solution for you - it's called SoftGrid but more on that topic later. Network restrictions will cause some applications to behave in unexpected ways, but my belief is that this will be quite a rare occurrence.
Security restrictions under Vista are very similar to those imposed on Windows XP Service Pack 2 (SP2) and will be the root cause of most failed installations and expected behaviors. Which, is great news for us application packagers, deployment engineers, and sysadmins. It means that for the most part, Microsoft has provided (or allowed) work-arounds through Shims (through the Application Compatibility toolkit), registry configurations or through the create of manifest security files.
And, this follows the approach of ChangeBASE on application Compatibility. My feeling is that if we can report on an application compatibility issue; we should be able to fix it - meaning to get that application successfully deployed to the target platform (server or desktop) and get the desired functionality user standard user privileges. Quite a challenge, eh?
Wednesday 16 September 2009, 7:54 AM
Getting Started: Common Application Compatibility Issues
One of the most common (and yet rarely publicized) issues to affect almost all applications that are over two years old will be Help file compatibility. Microsoft has deprecated all Microsoft Help file formats and components. Meaning, help files are not supported under Windows Vista and definitely will not be supported under Longhorn Server (due H2 2007).
Help files (HLP extension) are the files that include the application specific documentation on usage, troubleshooting and further support options. While not absolutely essential to application functionality they are a key element to the user experience.
In addition to no longer allowing users to read/use Help (HLP) files; the following Help file components are no longer supported under Windows Vista;
Windows.hlp
Winhlp32.hlp
Winhlp32.cnt
Winhelp.cnt
Nocntnt.cnt
Reading the Microsoft knowledge base article (KB917607), Microsoft has the following to say about Help files on Windows Vista,
"The .HLP files that depend on these files may return an error when users try to open them. These files will be available in the future from the Microsoft download center to address compatibility issues. "
When Microsoft "deprecates a component" it effectively does four things;
1) Disable support for that component on the target OS - meaning it will no longer work
2) No longer provide technical support for that component - meaning Microsoft will not help you on this issue
3) Actively encourage you to try other options - i.e. direct to you to a later component
4) Possibly remove support for component dependencies
Following this methodology, Microsoft no longer will "load" a help file and display it's contents. Instead you will receive a message indicating that this functionality is now longer supported and will direct you to a Microsoft knowledge base article detailing the security issues surrounding Help files.
This will cause a number of "Known Issues" when using Help files including;
· Help Macros are disabled
· You cannot access .HLP files that are stored on intranet sites
· Non-interactive user access has been blocked
· Drag-and-drop functionality has been disabled
I am really surprised at this approach. The WinHelp.EXE engine (version 5.0x) under Windows XP SP2 may be a significant security issue so I understand that an upgrade or update is necessary. However, why not include WinHelp.exe (version 6.0) in Windows Vista?
Microsoft makes an update available (version 6.0 of the WinHelp engine) on their knowledge base website (http://www.microsoft.com/downloads/details.aspx?familyid=6EBCFAD9-D3F5-4365-8070-334CD175D4BB&displaylang=en).
So, you can download it and continue using older, "non-compatible" HLP files as long as you like. Hmmm...
Actually, there are two further points. If you need to support any of the following features you also need to add the following registry entries on your target machine.
Allow Help Macros
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinHelp
Value: AllowProgrammaticMacros
Type: DWORD
Unblock .HLP files that are stored on the intranet
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinHelp
Value: AllowIntranetAccess
Type: DWORD
Previous
