Windows XP OS Version Compatibility Shims

When Microsoft released Windows XP on the Windows NT kernel, many legacy consumer applications failed simply because their hardcoded version checks did not recognize the new operating system. To resolve this, Windows XP utilized an Application Compatibility (AppCompat) infrastructure powered by targeted "Version Lie" shims. These shims intercepted Win32 API calls querying the operating system identity and returned values corresponding to legacy environments, allowing programs designed for Windows 95, Windows 98, Windows NT 4.0, or Windows 2000 to run properly.

The Version Lie Shims

The primary shims responsible for spoofing operating system versions in Windows XP were categorized as "VersionLie" shims. These shims specifically targeted calls to Win32 functions in kernel32.dll, such as GetVersion, GetVersionEx, and later VerifyVersionInfo. Instead of returning Windows XP's true identifiers (major version 5, minor version 1, VER_PLATFORM_WIN32_NT), the shim engine substituted legacy metadata.

The key version-mimicking shims included:

  • Win95VersionLie: Intercepted version requests and reported Windows 95 identifiers (Platform ID VER_PLATFORM_WIN32_WINDOWS, Major Version 4, Minor Version 0). This bypassed legacy checks that specifically looked for Windows 9x architecture.
  • Win98VersionLie: Returned Windows 98 metrics (Platform ID VER_PLATFORM_WIN32_WINDOWS, Major Version 4, Minor Version 10). It was essential for software that required features introduced specifically in Windows 98 or its Second Edition.
  • WinNT4SP5VersionLie: Mimicked Windows NT 4.0 with Service Pack 5 (Platform ID VER_PLATFORM_WIN32_NT, Major Version 4, Minor Version 0, build 1381, with the Service Pack 5 string in the szCSDVersion field). This enabled older enterprise software to execute without triggering NT-specific version aborts.
  • Win2kVersionLie: Spoofed Windows 2000 metrics (Platform ID VER_PLATFORM_WIN32_NT, Major Version 5, Minor Version 0, build 2195).

How the Shims Operated

Version shims in Windows XP operated by hooking the target executable's Import Address Table (IAT). When an application launched, the operating system's loader referenced the Shim Database (sysmain.sdb). If a matching application signature was detected, the compatibility infrastructure loaded AcLayers.dll into the process address space.

AcLayers.dll redirected calls directed to GetVersion or GetVersionEx toward shimmed wrapper functions. When the application populated an OSVERSIONINFO or OSVERSIONINFOEX structure, the shim populated the fields with spoofed values for major version, minor version, build number, platform ID, and service pack string. The application evaluated the spoofed structures, assumed it was running on its intended legacy host, and proceeded to execute without aborting.

Implementation Through Compatibility Modes

End users and administrators accessed these shims collectively via Windows XP's built-in "Compatibility Mode" tab in file properties or via the Application Compatibility Toolkit (ACT). Selecting options such as "Run this program in compatibility mode for Windows 95" or "Windows 2000" applied layers containing the respective VersionLie shim along with supporting shims that altered memory handling, registry paths, and system metrics to maintain complete legacy parity.