How ACT Deployed Shims in Windows XP

When Microsoft transitioned consumer PCs to the Windows NT kernel with Windows XP, many legacy Windows 9x applications failed due to hardcoded OS version checks, improper memory access, and restricted file system permissions. To resolve this without requiring changes to source code, Microsoft introduced the Application Compatibility Toolkit (ACT), which allowed administrators to package and deploy "shims"—small code intercepts that masquerade API behavior—via customized Shim Database (.sdb) files. This article explains the technical mechanics of how ACT created, packaged, and deployed these shims across Windows XP environments.

The Role of the Shim Engine

Windows XP includes a native Shim Infrastructure built directly into the operating system loader (ntdll.dll) and kernel32.dll. When a user launches an executable, the loader consults apphelp.dll to inspect the program's metadata against installed compatibility databases.

A shim works via API hooking. Instead of calling a native Windows XP API directly, the application's Import Address Table (IAT) is dynamically redirected to a compatibility DLL. This wrapper alters inputs or outputs—for example, returning "Windows 98" when the application requests the OS version (via the Win95VersionLie shim) or granting virtualized administrative privileges—before passing control back to the application or the real operating system API.

Creating Compatibility Fixes with Compatibility Administrator

ACT included the Compatibility Administrator utility (compatadmin.exe), the primary tool used to create custom shim configurations:

  1. Application Profiling: Administrators selected the target executable and specified unique matching criteria (such as file size, checksum, and version metadata) to ensure the shim only applied to the intended application and not other files sharing the same name.
  2. Selecting Fixes: Administrators selected from hundreds of pre-built shims (e.g., EmulateHeap, CorrectFilePaths, or display-related fixes) or compatibility modes.
  3. Database Generation: The tool compiled these matching rules and associated shims into a single binary file with the .sdb (Shim Database) extension.

Packaging and Registration Using sdbinst.exe

To make the Windows XP loader aware of custom shims, the .sdb file had to be installed locally on target machines. ACT utilized a native command-line utility called sdbinst.exe (Shim Database Installer) to register the database.

The deployment command typically followed this format:

sdbinst.exe -q path\to\database.sdb

The -q switch ran the installer silently, suppressing any user-facing confirmation dialogs.

When sdbinst.exe executed, it performed two main actions:

  • Copied the .sdb file to the system directory (typically %windir%\AppPatch\Custom\).
  • Registered the database GUID and matching criteria in the Windows Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB.

Enterprise Deployment Methods

In corporate networks running Windows XP, administrators deployed the compiled .sdb files and executed sdbinst.exe at scale using standard management infrastructure:

  • Group Policy (GPO): Deploying a startup script via Computer Configuration that ran sdbinst.exe -q \\network_share\custom_fix.sdb. Running as a startup script ensured the registration occurred under the SYSTEM context with full administrative privileges.
  • Systems Management Server (SMS) / Early SCCM: Creating a deployment package containing the .sdb file and running sdbinst.exe -q across targeted machine collections.
  • Custom Installers: Bundling the .sdb file alongside legacy application setup scripts, executing sdbinst.exe during post-installation routines.

Once installed, the integration was seamless: the next time the target executable was launched, Windows XP intercepted the process creation, applied the specified shims, and executed the legacy software transparently to the end user.