How Windows XP Ran Any App by Lying to Them

The Hidden Compatibility Database

Windows XP's ability to run almost any application, including pre-2001 games and business software, stemmed from a hidden problem application database stored in C:\WINDOWS\AppPatch. As Microsoft engineer Raymond Chen explained in a 2003 blog post, the main database file Sysmain.sdb is an indexed binary file (extension .sdb) designed for fast scanning. At XP's release it contained roughly 200 compatibility fixes.

Precise Application Matching

Windows does not rely solely on the executable name. It matches applications using file size, checksum, version, date, and even other files in the application folder. This allows fixes to target a specific buggy version without affecting newer, working releases.

Shims: The Core Mechanism

When a match is found, Windows applies shims — small stub functions that intercept API calls. A shim can modify the parameters the app sends, change the return values from Windows, or run custom code before forwarding the call to the real API.

Version Lying: Win98VersionLie

Some applications refuse to run unless they detect a specific Windows version. The Win98VersionLie shim makes Windows report Windows 98's version information to the application, regardless of the actual OS version. As Chen put it, Windows lies to the application, and the application never knows.

Heap Emulation: EmulateHeap

Chen's favorite shim, EmulateHeap, replaces the standard heap with an exact copy of the Windows 95 heap manager. Older programs that depended on Windows 95's memory allocation behavior would crash on XP's new heap; instead of flagging the app as broken, Windows gives it the memory manager it grew up with.

Historical Precedent: SimCity on Windows 95

Joel Spolsky, a former Microsoft programmer, documented that SimCity read memory it had just freed. Windows 95 included special code that detected SimCity and ran the allocator in a mode that delayed freeing memory — an early example of bug-for-bug compatibility .

Security Trade-offs

In a 2017 article Chen noted that Windows 2000 compatibility mode forces programs to load DLLs using pre- SafeDllSearchMode rules, which are less secure. Microsoft deliberately kept this behavior for apps that depended on the old search order, calling it "bug-for-bug compatibility." A vendor that hasn't fixed its app in 15 years won't fix it now.

Why Not Just Block Broken Apps?

Chen's 2003 post argued that every blocked application becomes a reason for customers not to upgrade. He illustrated: an IT manager's word processor fails on XP; the vendor charges $150 for version 2.0 — "Congratulations, the cost of upgrading to Windows XP just tripled." That assumes the vendor is still in business. Microsoft's survey found nearly every company had at least one mission-critical internal Visual Basic app whose original developer had left.

Architectural Cleanliness

XP moved many compatibility fixes into DLLs inside the AppPatch folder so "these compatibility workarounds no longer pollute core operating system files." Shims operate only inside the application's own process, leaving system-wide security boundaries intact and not helping incompatible kernel-mode drivers.

Ongoing Updates and Side Effects

Microsoft continued shipping new fixes years after release. The April 2011 Application Compatibility Update replaced Sysmain.sdb on XP SP3 with a 1,206,508-byte version. Compatibility concerns also influenced other decisions: XP SP2 capped 32-bit Windows at 4 GB of memory to avoid driver crashes, and the OS retained features like file system tunneling solely for legacy software.

From the user's perspective, these mechanisms are invisible internal technology. After a system update, double-clicking a program still works — the user never knows how much compatibility work happened behind the scenes.