Solving the legacy Windows compatibility puzzle

There's been a lot of chatter lately about how Microsoft needs to start over with Windows. Many point to the (NT) code base's 16-year history and how the need to maintain backward compatibility is hampering efforts to move the platform forward. According to these critics, a clean break is necessary in order to stop the kind of bloatware madness that so crippled Windows Vista. Dump the creaking legacy that is the Win32 API/ATL/MFC, they say, and solve the compatibility riddle through VM technology.

While I can appreciate the logic behind these assertions, I don't agree with the proposed remedy. For starters, the inferred replacement for these outmoded APIs is Microsoft .Net. As those who are familiar with .Net programming will attest, so-called managed code runs like a slug in a molasses bath -- a least on the client side of the fence (I've personally had success with .Net for server application development). Convincing developers to dump tried and true -- if somewhat anachronistic -- programming models in favor of a fatter, slower runtime is even harder than it sounds.

Then there is the issue of application fidelity. Despite advancements in VM technology -- most notably, support for accelerated 3-D graphics in VMware Workstation 6.5 -- the fact remains that running legacy applications in a virtual machine is far from ideal. In addition to the sizable overhead (several hundred megabytes of RAM to house the applications and their supporting OS images), you lose the seamless integration of a natively executing Windows program. Popular workflow functionality, such as COM/OLE automation, becomes nearly impossible to implement across VM boundaries. Even simple tasks, such as dragging and dropping a data file onto an application window, take on new levels of complexity. No matter how cleverly disguised, these virtual walls of isolation will simply aggravate users who are accustomed to a consistent operational experience.

It would seem that Microsoft is faced with a dilemma. On the one hand, it's being called upon to move the Windows platform forward by eliminating the compatibility baggage, while on the other, it's stuck with the expectation that Windows will somehow continue supporting legacy applications, most likely through virtual machine technology. But is VM compatibility -- with its inherent shortcomings -- the only option?

Fortunately, the answer is no. There is another compatibility avenue that Microsoft might consider: application virtualization. Instead of building in a complex VM compatibility box, Microsoft could simply tweak its SoftGrid-derived Microsoft Application Virtualization (MAV) technology to provide a controlled runtime environment in which to execute legacy applications.