The last couple of weeks I saw a lot of discussions on application compatibility for the Hosted Private Computer Infrastructure (HPCI)/ Hosted Shared Computer Infrastructure (HSCI). I was wondering if application compatibility still is an issue as we have plausible alternatives.
The way I look at it there are two paths to handle the application compatibility issues, one is focusing on the infrastructure (platform) and the other is focusing on the application. Depending on the requirements of your customer you can choose either way (or both)..and of course there’s Citrix’s AppDNA and ChangeBase has it’s products to avoid surprises during the project but it happens to often that there’s no budget and/or time to use this tooling.
Platform
First we can find a solution in the platform for the application, as we’re delivering applications on (mostly) Windows Operating Systems we can choose an operating system based on application requirements.
Basically there are server and client options:
| Server OS | Client OS1 |
| Windows Server 2003(R2) | Windows XP |
| Windows Server 2008(R2) | Windows 7 |
| Windows Server 2012 | Windows 8 |
1 Note: I didn’t list Vista as I don’t see my clients choosing Vista a lot.
The next question usually is if it should be a x64 or x86 platform. Andy Baker wrote a blog post on this topic: Virtual Desktops: 32-bit or 64-bit Desktop Operating Systems? and it was covered in one of the newer ProjectVRC survey’s “State of the VDI and SBC Union 2013“. Over 34% of the people who took the time to complete the survey is using Windows 7 x64 on their VDI platform:
In certain situations you can’t choose the platform as Windows Server 2008R2 and Windows Server 2012 are only x64. That means you can always deliver a x86 client OS platform for those applications that can’t (or shouldn’t) run on a x64 platform. I said ‘shouldn’t’ as 32bits applications can run on a 64bits OS but:
WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. WOW64 is provided with the operating system and does not have to be explicitly enabled.
According to Microsoft, 32-bit software running under WOW64 has a similar performance when executing under 32-bit Windows, but with fewer threads possible and other overheads: Performance and Memory Consumption Under WOW64. There are reasons to go for Windows 7 x64 as you want to try to keep a minimum of images or if users need more than 4Gb of RAM as Helge Klein pointed out during his presentations at Citrix Synergy and E2EVC. With modern days technology it’s possible to mix and match client Operating Systems with just a couple of base images but because of a fragmented application landscape you can only solve a limit amount of application compatibility issues.
These choices should cover the platform part.. but there’s more!
Applications
So we can provide different platforms to host applications based on the requirements of the application set but what if you don’t want to build and manage different platforms.. You can always take a closer look at the application itself.
Update/Upgrade
When you encounter an application that’s not supported on the platform you’re using one of the steps to take is to take a look at a possible update of the application. This could be a solution but there’s a risk in a change of functionality so an update is possible but an upgrade is often out of the question.
Compatibility Mode
With the newer platforms the applications can be altered so that certain features can be enabled/disabled to close the gap between the newer and the old Operating System.
As you can see the program can be faked into Windows XP but can also be started in certain colors, screen resolution and visual themes.
Shims
The Shim Infrastructure implements a form of application programming interface (API) hooking. Specifically, it leverages the nature of linking to redirect API calls from Windows itself to alternative code—the shim itself. The Windows Portable Executable (PE) and Common Object File Format (COFF) Specification includes several headers, and the data directories in this header provide a layer of indirection between the application and the linked file. Calls to external binary files take place through the Import Address Table (IAT). Consequently, a call into Windows to the system.
There are tools that can help you with shims, the Microsoft Application Compatibility Toolkit (ACT) is one of them and I added a short video to demonstrate the use of ACT and shims:
Application virtualization
In some cases application virtualization can be a solution for application compatibility but the official statement from the APP-V team is as following:
As noted in prior discussions, App-V is not a general purpose application-to-OS compatibility solution; however, if an application compatibility shim allows an app to work on a given Windows version natively (non-virtualized), it will in most cases, and for most shims, work with App-V when the shimmed app is virtualized. Thus, as a general rule, App-V will support app use with shims that are provided as part of Microsoft’s App Compat tools as long as the shimmed application can run natively on the targeted OS version.
So, it’s pretty clear that App-V isn’t intended to be an application-to-OS compatibility solution.
Hack the app!
If there’s is no support for the application because it was an in-house developed application with no documentation or the vendor is already vanished of the face of the earth this offers a solution. To change the application has it’s consequences for support and maybe even for the relationship with the vendor. Ask yourself: ‘if an application doesn’t work on current Operating Systems do you really want to implement it?’ Maybe this could be the moment for an application refresh but this should be a decision based on business requirements and not made by an admin/consultant.
And.. if everything else fails.. Call Remko! Remko is one of those IT Pro’s who can do black magic with applications that won’t run/can’t run on your platform. He did presentations on this topic during E2EVC in Vienna and at the Citrix UG meeting in London this month and he has numerous blog posts on this topic:
Application Compatibility Fixing to the Extreme?
Java has discovered application components that could indicate a security concern
The case of the COM Port Redirection
Choose your platform wisely, think about the x64/x86 discussion and take a look at the possibilities on updating the app, work with the ACT or AppDNA and if everything else fails: Call Remko but in the end application compatibility can cause some headaches but shouldn’t be a show stopper anymore.
Kees Baggerman
Latest posts by Kees Baggerman (see all)
- Nutanix AHV and Citrix MCS: Adding a persistent disk via Powershell – v2 - November 19, 2019
- Recovering a Protection Domain snapshot to a VM - September 13, 2019
- Checking power settings on VMs using powershell - September 11, 2019
- Updated: VM Reporting Script for Nutanix with Powershell - July 3, 2019
- Updated (again!): VM Reporting Script for Nutanix AHV/vSphere with Powershell - June 17, 2019
I think that App Compat will become more important than ever because the legacy platforms that we’re using to deliver incompatible applications (Windows XP, Server 2003, XenApp 5) are finally EOL.
This means we need to choose: bite the bullet and migrate those Apps to current platforms (x64, UAC etc) or replace them with well written Apps.
In an ideal world we would push Vendors hard enough to fix their CRAPplications or convince the customer to replace them. This depends on the Vendor’s cooperation though and IT should be in control to enforce it. Sadly this isn’t always the reality. The difficulty is often that the business sees the App from a functional point of view where it might work brilliantly.
I guess we’ll always have some legacy applications around for whatever reasons…
We need to make a choice: do we deliver those Apps from non-supported platforms? Or do we apply mitigations, shims or even patches so we can deliver them from supported platforms?
Either way we’ll be on our own because we don’t have vendor support for the Apps or no Vendor support for the OS. As IT, do you really want to be responsible for an OS that no longer gets security updates?? That’s a big risk for your whole environment! I’d rather run an App no longer supported by the Vendor but on a secured and supported OS.
As an extra argument for that choice: I am assuming that if we did have proper vendor support, they would fix the App in the first place. If they didn’t, what’s their support actually worth?
So my personal choice is to run the App on a supported platform, even if this means we need to apply (serious) mitigations.