Future of legacy compatibility in Windows

The ability to run decade-old applications on the newest releases of Windows has almost become a rite of passage. Most people would agree that software backwards compatibility on Windows is easily one of the important factors for its success. However with each release, Microsoft digs itself deeper and deeper into this pit of support as […]

The ability to run decade-old applications on the newest releases of Windows has almost become a rite of passage. Most people would agree that software backwards compatibility on Windows is easily one of the important factors for its success. However with each release, Microsoft digs itself deeper and deeper into this pit of support as the breadth and depth of software grows exponentially. So much so some predict it will eventually ruin Windows, if it hasn’t already.

A recently published patent application, “Environment For Executing Legacy Applications On A Native Operating System” for those of you playing at home, filed in April of 2007 by Microsoft’s Hoi Vo and Samer Arafeh (who works on the Windows kernel) reveals some details of how they might (and emphasis on might because patents are just words on a piece of paper) accommodate and dramatically improve software compatibility in future releases of Windows.

As described in the patent, the problem of legacy applications support lies in binaries (DLLs and EXEs). As operating systems are updated, system binaries change. Older system calls, callbacks and exceptions may not exist at all in the new operating system, may exist to some degree or may generate alternate responses. Any of which is likely to wreck havok on legacy applications which depend on these binaries.

Currently there are two conventional solutions to the problem. Each with their respective advantages and disadvantages.

The first employs the use of “shims”. Metaphorically speaking, it’s basically sticky tape around the edges to make sure things don’t fall out. Technically, it’s a custom-written patch that is applied on-the-fly when legacy applications are loaded and will sit in between the legacy application and the native system binaries. Reportedly Microsoft has written thousands of shims for Windows Vista, and are still writing. The upside is that shims are relatively easy to implement, but having to generate shims on a per application-by-application basis means it doesn’t scale well at all.

The second solution takes advantage virtualization technology. By hosting a legacy OS virtual machine, legacy applications won’t any know any better. Virtualization offers full application support but at a hefty performance cost. Hardware support is also primitive, making it difficult to share resources like 3D graphics for example. It also requires users to be able to install each version of the legacy operating systems.

Full Article

Microsoft, Windows, Future, Legacy, Compatibility