At the Windows Server 2008 launch event last year, I spent some time in David Allen’s (not the GTD guy – and not the Irish Comedian either) Windows Vista application compatibility session and I meant to blog some of the stuff I learned about making legacy applications work with on modern versions of Windows. Time passed by and that became just one of the many blog posts that never made it to completion but today I spent a whole day on one of David’s workshops and I intend to write a series of posts looking at some of the “appcompat” issues around Windows 7.

Whilst the UK launch of Windows 7 is tomorrow, and general availability is later this month, many of Microsoft’s partners and corporate customers already have access to release versions of Windows 7 (after a wide public beta programme) and, if you’re looking a Windows 7 deployment, then the process of application remediation should already have begun. For those who are already on Vista, life should be a little easier as you already went through the pain – 90% of applications that run on Vista should run on 7 and the only real problem applications I’ve seen have been those that interact with the operating system at a low level, such as the Zone Alarm firewall product and the Cisco VPN client. In both these cases my remediation method was to select another product.

You may ask why Microsoft has created this complex scenario where applications no longer work on new operating system releases but Windows today has to cope with new threats that were simply not present when Windows NT was first brought to market. Then there’s new functionality to meet the demands of our changing world (increased mobility, new methods of communication, etc.). Whilst competing operating systems (e.g. Apple’s Mac OS X) can drop support for technology perhaps only one or two versions after announcing that it would be deprecated, many of Microsoft’s customers are still wrestling with 16-bit applications from the days of MS-DOS and Windows 3.x or with applications that were written for Windows 95, where security was almost non-existent and Microsoft had yet to acknowledge the potential of the world wide web.

So, if you’re looking at rolling out Windows 7 (and you should be, if you’re on Windows XP or earlier), what are the main steps:

• Perform an inventory of your applications and separate them into core (bought-in), core (in-house developed) and non-core applications.
• For the core (bought-in) applications, check if they are certified for Windows 7. If they are, then you have no worries, if they’re not then is there a version available for Windows 7 that the ISV will support? If the ISV doesn’t support Windows 7, then do they plan to provide support soon (many will within 90 days of Windows 7 general availability, although with the widespread availability of pre-release versions of Windows 7, I’d have to question why they are taking so long…). If you can’t achieve a satisfactory response to this question, start to think about migrating to another application that does run on Windows 7. The basic premise here is not to end up with any core applications that are out of support. Even if the applications can be made to run on Windows 7, support should be a concern.
• For line of business applications developed in house, test them on Windows 7. Automated tools such as those from ChangeBASE may help here, identifying known problem areas and possibly even performing automated remediation. This should leave a list of applications that work, and some that do not. For the in-house applications that don’t work on Windows 7 and where the source code is available, fix the application (more on that later) and issue a new release. If the source is unavailable, or the product is no longer being actively developed, consider a shim.
  If the application can’t run locally, consider whether this application is critical to business operation or not. If it’s not, then you have two options: replace it; or, if there is no suitable replacement, remove it from the estate (remember, this application is not business critical). If the application is essential to the business then ask yourself why a critical application is based on legacy technology and cannot be updated. That sounds like a risk to me.
• At this stage, you may have a few “problem” applications and there are a few options: you could consider managed diversity – i.e. deliberately leaving a few Windows XP PCs in place for these applications until the application can be replaced (and it should be); you could look at options such as terminal services, or maybe MED-V (if you have software assurance) but these solutions may not help you in the long term if they still rely on Windows XP or Server 2003, both of which are in their twilight years.
• Finally there is Windows 7’s XP Mode. Let me be clear about this: from an appcompat perspective, XP Mode is a last resort. It’s great for consumers but for businesses it has some significant drawbacks: it still involves a legacy operating system; it involves managing multiple operating system environments and lacks any management toolsets; it may impose additional application licensing costs on the desktop; it requires specific hardware capabilities (that will not be present in legacy PC hardware); it’s only available with certain product editions; and it may be withdrawn at a future date. You may think that this point that I have a problem with XP Mode but the truth is, it’s fine for use on my own, self-supported, IT but I’d never recommend it to a customer – at least not one with more than a handful of PCs. Quoting Microsoft’s Dave Allen: “I think XP Mode is basically there to keep the boys in Computer Weekly happy” (and he’s right – it’s purely sticking plaster to ensure that applications work and to ensure that Windows 7 receives positive press, unlike Vista, which suffered unfairly, even after Microsoft had fixed it).

By now, you should have managed to identify options for just about every application, so what are the sort of issues that are really likely to present themselves? Well, this is the list of topics that David covered in the workshop today:

• User Account Control (UAC).
• New folder locations.
• Windows Resource Protection (WRP).
• Mandatory Integrity Control (MIC).
• User Interface Privilege Isolation (UIPI).
• Internet Explorer Protected Mode.
• Operating System and Internet Explorer versioning.
• Session 0 isolation.
• Shims and the Microsoft Application Compatibility Toolkit.

Over the next few weeks, I’ll try and cover most of these topics in a way that IT admins like myself can understand with the intention of helping everyone understand common Windows application compatibility issues and what to do about them, rather than just thinking of appcompat as “a developer issue”.

Credit

The contents of this blog post were heavily influenced by David Allen’s Windows 7 Application Compatibility workshop. Read more about David’s work on the Microsoft ISV developer evangelism team’s blog.