Well, it finally happened. After years of patching and tweaking the Windows runtime to preserve backward compatibility (and placate its perpetually cranky customer base), Microsoft has finally said enough is enough. With Windows 7, it's putting the legacy Win32 API genie back in the bottle -- or more precisely, tucking it inside a custom-integrated virtual machine where it, and its notoriously hard-to-kill XP underpinnings, can coexist peacefully alongside newer, hipper versions of Windows.
It's a great idea, on paper.
[ Find out why Microsoft's own App-V would be a better solution to support the XP legacy. ]
Keeping the proverbial east (legacy) and west (managed) sides of Windows separate while allowing users to seamlessly access both environments is a feature that has been on IT wish lists forever. Unfortunately, by taking the VM route -- Microsoft is bundling a tweaked version of Windows XP with SP3 inside an improved Virtual PC image with a kind of coherence-mode rip-off -- Microsoft is ignoring other technologies that might have proven a better fit for the role.
I'm speaking, naturally, of application virtualization. The capability to isolate legacy applications into their own separate, virtualized runtime environments has long been one of the major selling points for this product category. And few vendors have as much experience and technical competence in this segment as Microsoft. The company's App-V platform is one of the pioneering application virtualization products, with thousands of successful installations.
With App-V, there's no need for a clumsy VM with its myriad integration and configuration management headaches. App-V virtualized programs run at or near native speed, with full fidelity, yet their impact on the system is negligible: All registry and file system modifications are sandboxed, keeping the local environment clean and immune from DLL hell and other legacy Windows baggage.
It's an elegant solution, and it begs the question: Why isn't Microsoft using App-V as opposed to shoehorning a copy of a XP into a slow, bloated VM that uses a bunch of screen-scraping smoke and mirrors to make it look like a program has been "integrated" with the local desktop?
As I've mentioned in several previous posts, an App-V-based solution could be made entirely invisible to the user. Simply intercept a legacy Setup program at startup and redirect it to an automated version of the App-V Sequencer. The end product would look and work just like any locally installed application, right down to local shell integration and drag-and-drop functionality. Contrast this with the proposed "XP mode" solution where you have to interact with an entirely different operating environment (you install virtualized applications from within the Windows XP VM), not to mention managing multiple file systems, program directories, and registry hives.
Perhaps Microsoft just got lazy. Perhaps it was looking for a quick fix, and stuffing a copy of XP into a VM seemed like the path of least resistance. To the uninitiated, it probably seems like a great idea. However, to those of us who know better and have extensive experience with the full range of virtualization and legacy integration options, an XP mode seems like a cop-out. It's another "good enough" solution from a company that stopped shooting for technical excellence long ago.