Windows XP, a beloved operating system that debuted in 2001, is often celebrated for its remarkable ability to run a wide array of legacy software. This compatibility was not merely a stroke of luck; it was, in part, a clever strategy employed by Microsoft. The operating system came equipped with a hidden database of problematic applications, allowing it to adapt and respond to older software in ways that would surprise many.
According to Microsoft engineer Raymond Chen, who has dedicated over three decades to the Windows project, XP contained a list of compatibility fixes stored in the C:WINDOWSAppPatch folder. This list was formatted in a binary style to facilitate rapid scanning. What’s particularly fascinating is how Windows XP could modify its behavior specifically for an application once it identified it. This capability, reminiscent of artificial intelligence, was achieved through pure human ingenuity long before AI became a buzzword.
Windows XP could recognise an app and change Windows just for it
The Application Compatibility Database, as Microsoft refers to it, was an indexed binary file with an .sdb extension. The primary database, Sysmain.sdb, contained approximately 200 compatibility fixes at the time of XP’s launch. Rather than relying solely on the executable name, Windows XP employed a sophisticated matching system that considered file size, checksum, version, and date. This allowed it to apply fixes tailored to specific versions of applications without affecting newer iterations that functioned correctly.
Once a match was found, Windows applied what are known as shims. These shims acted as intermediaries, intercepting calls made by the application to the Windows API. They could adjust the data sent by the app, alter the responses from Windows, or even execute custom code before relaying the request to the appropriate Windows function. For instance, some applications would only run if they detected a specific version of Windows. Shims like Win98VersionLie would cleverly return Windows 98 version information, regardless of the actual operating system in use.
Chen has expressed concern over developers relying on these workarounds. In a 2010 post, he emphasized that if an application only functioned with the aid of VersionLie, it was the developer’s responsibility to rectify the version checks, as compatibility mode was intended for the user’s benefit, not the software’s.
Microsoft went much further than lying about the Windows version
While faking a version number is one tactic, Chen’s favorite shim, EmulateHeap, takes compatibility to another level. This shim replicates the Windows 95 heap manager, allowing older applications that were overly dependent on that specific memory management style to function seamlessly on XP. Instead of informing users that the application was poorly designed, Windows provided it with the memory manager it was accustomed to.
Such compatibility measures were not exclusive to XP. Chen recalls that even in Windows 95, special provisions were made for applications like SimCity, which had quirks in their memory handling. Microsoft’s foresight in addressing these issues extended beyond mere convenience; it was a strategic move to ensure that users would not be deterred from upgrading due to compatibility concerns.
Microsoft couldn’t afford to let one broken app kill a Windows upgrade
Chen articulated a critical point: blocking applications that relied on undocumented features could deter users from upgrading. He noted that even a single incompatible program could sour the experience of transitioning to a new version of Windows. IT managers faced with the prospect of a non-functional word processor on XP would find the upgrade costs ballooning, especially if they had to purchase new licenses for essential software.
Many organizations had at least one “deal-breaker” application—often a legacy program whose developer had long since departed. The thought of upgrading an entire office to XP only to lose access to a vital tool was a daunting prospect, one that Microsoft understood all too well.
Windows XP also allowed Microsoft to manage compatibility fixes more effectively. Many of these workarounds transitioned into DLLs within the AppPatch folder, ensuring that the core operating system files remained untainted by these modifications. Over the years, Microsoft continued to enhance XP’s compatibility, with updates that expanded the compatibility database significantly, even years after its initial release.
As Windows XP approaches its 25th anniversary, it remains a nostalgic symbol of a time when software compatibility was paramount. Despite the occasional shortcomings of the applications that earned XP its reputation, the operating system’s ability to run them seamlessly is a testament to the innovative strategies employed by Microsoft. The next time someone praises XP for its exceptional compatibility, one can appreciate the intricate dance of technology and ingenuity that made it all possible.
