Peek into the future of legacy compatibility in Windows

Windows 3.1The 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.

Shims

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.

Application Compatibility Module

The proposed solution in some ways takes the best bits of both. It works first by detecting if the application was written for the native operating system. If not, it will load the application with its respective legacy system binaries. To accommodate the difference in system calls between the legacy binaries and native kernel, an Application Compatibility Module is placed in between to act as a translator for these calls. In certain cases where a comparative native system calls may not exist at all, the ACM could also be smart enough to provide the same functionality as the missing system call.

Hypothetically speaking, if the system detected an XP application running on Windows 9, it would load the XP system binaries (ex. system32_xp) and then a “XP-to-Win9” compatibility module.

The benefit of this solution is it offers much broader application compatibility with relatively low investment on Microsoft’s behalf on the scale of per-application – they will only have to write a ACM for each legacy system they wish to support. Legacy applications will also be able to take full advantage of the system resources as a native application, because there is no emulation involved.

Notable Windows on Windows – the compatibility system used to provide 16-bit on 32-bit systems support and 32-bit on 64-bit systems support uses a similar concept.

One of the biggest gripes from most Windows enthusiasts has been the bloat legacy compatibility forces into Windows. Whilst this patent doesn’t specifically mention so, I presume such ACMs are modular and can be installed and removed on demand. For example, if you need to run Windows Vista applications in future versions of Windows, you will only download and install the Vista ACM Pack (with Vista binaries) for that operating system. Those who do not require legacy support will then be not required to install any ACMs.

Thinking about it, it could become a business model to sell ACMs separately to Windows – reducing the overall cost of Windows and charging a tiered price for legacy support. A cheaper and less bloated Windows, wouldn’t that be nice.

9 insightful thoughts

  1. selling a new os which isn’t compatible to old software and then selling an acm pack which provides the files of the old os to make old software run – that would be pretty smart in a money-making perspective 😉

  2. @the dude: Of course bear in mind that’s only an idea I proposed. However they could also sell something like Ultimate that ships with all ACMs.

  3. Microsoft has been investing a lot in virtualization lately…hopefully whatever compatibility route they decide on is low impacting on performance for the native OS and non native app.

  4. Great… then some of our ISVs would be encouraged NEVER to update their applications. It’s hard enough getting them to update anything as it is. Now we’ll have applications that look like they were designed for Win 3.1 for all eternity.

    At any rate, this sounds nice in theory, but I would imagine in practice it would be pretty complex. The ACM would probably be a beastly undertaking. Consider, too, that older versions of Windows themselves had components that may not be installed by default… say IIS, or Message Queueing, etc. I would think that simply providing a VM of the older OS would be a much simpler and lower-overhead (in terms of development) solution, and they should put all their virtualization efforts to make that as high-performance as possible. With RDP app publishing and/or something like Coherence from Parallels, it could be a relatively seamless experience, even graphically–RDP supports desktop composition for Vista, so even if the hardware itself for the host doesn’t support Aero, you can get it as long as the client hardware supports it. And with Microsoft’s acquisition of Calista, RDP will improve considerably. I hope they aren’t thinking of it only in terms of VDI solutions!

  5. Very good investigating Long. Jim Allchin talked with me specifically about this exact system in my interview with him before the Vista launch. I’ve heard recently however that you may not see this functionality in Windows 7… it may be farther out than that.

  6. Wow. Microsoft got such a great and innovative idea again: copy Apple. Come on! Apple has good ways to run old apps (with different requirements) without having resource problems. Programs written for pre-OSX versions will run (even though OS X is a totally different UNIX based OS) using basic processing for it, Rosetta is used for programs made for a different processor, and Apple even has 32 bit apps running at full speed in a 64 bit Leopard OS.

  7. @Jack: As I see it, it’s not really the same thing. Rosetta is an emulator. Apple rewrote the APIs for Intel in the same way so applications only need their own code rewritten, not the entire OS. That means Rosetta only translates instructions. OS calls and loading of shared objects may only need reordering(little endian-big endian differenes).
    The currently speculated solution wants to translate library calls that are no longer valid to new versions of Windows to the new equivalents. That doesn’t really mean emulating anything. It just means applications are redirected to wrapper libraries and then the new versions are executed.

    For the sake of argument, Microsoft is copying Apple. But Apple announced the transition to Intel in 2005. Microsoft had WOW64 for some time before that. Wikipedia says WoW64 was even in a limited edition of Windows 2000. So there goes Microsoft copying Apple… again..

  8. Do you honestly think Microsoft copies everything from Apple!?!? they actually have these systems and development in place for years before it is announced.

    It is amazing that the Apple fans have no clue how systems work. Microsoft develops at a lower level, systems-wise, than any other company. What languages, for example, have been released by Apple over the past 10 years? AppleScript?

    Microsoft invests a lot at the low level, including O/S design. Yes, they can learn from Apple (and have) on UI design but give me a break on languages and O/S. The Microsoft guys have far more experience and innovation than Apple ever would.

Comments are closed.