Windows 7 still is available in both 32-bit and 64-bit (x64) editions. A lot of folks are thinking about jumping right into the x64 edition for their new environments. This is great plan, except for one small problem: x64 editions of Windows do not support 16-bit applications.
At this point, you might think, "But we don't have any 16-bit apps." Not so fast. Unfortunately, many 32-bit apps actually have 16-bit components under the hood. Maybe you have 32-bit apps that have 16-bit Dynamic Link Libraries (DLLs) for report generation or certain menu functions? Maybe your app is fully 32-bit, but its installer is 16-bit? Of course, you may just have some old-fashioned 16-bit apps.
If you choose the x64 edition of Windows 7, the first thing to do is take an inventory of your current apps to figure out which ones might have 16-bit components. (This is something I
Run the 16-bit apps on a 32-bit terminal server
This is probably the easiest and cheapest solution. If you have only a few applications with 16-bit components, you can just build a 32-bit terminal server and seamlessly publish your 16-bit apps into your x64 desktop environment. You can do this with something like Quest vWorkspace, Citrix XenApp or, if you're using Windows Server 2008 R1, Terminal Services RemoteApp.
Also note that if your 16-bit apps don't play nicely with Terminal Services, you can run them as remote VDI-hosted apps running on the 32-bit version of Windows XP or Windows 7. Citrix calls this "XenDesktop published apps," Microsoft calls it "RemoteApp for Hyper-V," and Quest doesn't call it anything because the feature is built right-in to vWorkspace.
Of course, since Terminal Server or virtual desktop infrastructure (VDI) hosting requires 16-bit applications to be hosted from the data center, this method won't work for apps that need to run locally on your client device (if you need offline access, for example).
Run the 16-bit app in a 32-bit virtual machine on your client
The second option is to deliver a 32-bit Windows virtual machine (possibly Windows XP) to your client. Windows 7 includes something called "Windows XP Mode," which is essentially a local copy of Windows XP running in a virtual machine (VM) on the client. The Windows XP Mode functionality hides the XP desktop and publishes the apps from the XP VM into the Start Menu of the Windows 7 host. In this case, you can run a 32-bit version of Windows XP in the VM on an x64 Windows 7 host.
Windows XP mode works well, but it's difficult to manage for more than a few users at a time. The "enterprise" version of Windows XP Mode is Microsoft MED-V, which is included in the Microsoft Desktop Optimization Pack (MDOP) add-on. MED-V also lets you run a 32-bit Windows XP VM on an x64 Windows 7 host.
Of course, you don't have to use Microsoft tools for this. You could also use the Virtual Box free VMware Player or any other client-based virtualization environment to get your 32-bit VM on your x64 hosts.
Just don't use x64 Windows
It's important to remember that 16-bit app components are only a problem for x64 Windows 7 environments. If you really have a lot of 16-bit apps that are going to be a problem, the easiest solution might be to just use the 32-bit version of Windows 7 and run your 16-bit apps like normal. Then if Microsoft finally kills 32-bit support in Windows 8 or Windows 9, it will be someone else's problem to deal with.
ABOUT THE AUTHOR
Brian Madden is an independent industry analyst and blogger, known throughout the world as an opinionated, supertechnical desktop virtualization expert. He has written several books and more than 1,000 articles about desktop and application virtualization. Madden's blog, BrianMadden.com, receives millions of visitors per year and is a leading source for conversation, debate and discourse about the application and desktop virtualization industry. He is also the creator of BriForum, the premier independent application delivery technical conference.