Windows 2000 Application Compatibility Toolkit Guide

This article examines how Microsoft Windows 2000 handles application compatibility flags using the Application Compatibility Toolkit (ACT). It covers the underlying Shim infrastructure introduced in Windows 2000 Service Packs, the mechanisms used to intercept application programming interface (API) calls, and the deployment of custom compatibility fixes via database files to ensure older applications function seamlessly on modern NT-based systems.

The Windows 2000 Shim Infrastructure

Windows 2000 marked a major transition for enterprise computing, shifting users from MS-DOS-based Windows 9x architectures to the Windows NT kernel. Because many legacy applications relied on undocumented APIs, hardcoded OS version checks, or direct hardware access, Microsoft developed the Shim infrastructure (introduced extensively in Service Pack 2 and refined in Service Pack 3).

A "shim" is a small piece of interceptor code that sits between an application executable and the underlying Windows operating system APIs. When an application attempts to call a function in system libraries such as Kernel32.dll or User32.dll, the shim modifies the input, bypasses the request, or alters the output to match the legacy behavior the program expects.

The Role of the Application Compatibility Toolkit (ACT)

The Application Compatibility Toolkit provides administrators and developers with the utilities needed to diagnose software failures and assign compatibility flags to problematic binaries. In the Windows 2000 era, the primary utilities in ACT included:

  • Apcompat.exe: A lightweight tool used to force individual executables to run under specific compatibility layers (e.g., Windows 95, Windows 98, or Windows NT 4.0).
  • QFixApp.exe: A granular debugging utility that allows users to test individual compatibility flags (fixes) against an executable to identify the exact cause of a crash or failure.
  • Compatibility Administration Tool (Compatadmin.exe): The central management console used to create, modify, and compile application compatibility databases containing collections of shims and matching rules.

How Compatibility Flags Work

Compatibility flags in Windows 2000 are granular behavioral modifications designed to rectify specific coding errors found in legacy software. Common compatibility flags include:

  • Version Lies (e.g., EmulateGetVersion): Intercepts calls to GetVersion or GetVersionEx and returns the build numbers of Windows 95 or Windows 98, bypassing strict installer or executable version checks.
  • Memory Management Shims: Catches illegal memory accesses or null pointer dereferences that modern NT-based memory protection mechanisms would otherwise terminate.
  • Heap Emulation: Simulates the Windows 9x heap management behavior, accommodating software that attempts to read freed memory or incorrectly calculates buffer allocations.
  • Directory and Registry Redirection: Redirects file and registry paths that existed in Windows 9x to their modern Windows 2000 equivalents.

Matching and Execution Process

When a user attempts to launch an executable in Windows 2000, the operating system executes the following sequence:

  1. Process Creation: The system loader begins initializing the process.
  2. Database Lookup: The OS queries the Central Shim Database (Sysmain.sdb), located in %SystemRoot%\AppPatch. It checks application matching attributes, which typically include the executable name, file size, checksum, and PE header timestamps, to prevent applying shims to the wrong software.
  3. Shim Injection: If a match is detected, the loader pulls the designated compatibility flags from the database. The system injects AcLayers.dll or related shim libraries into the target process's virtual address space.
  4. Hook Installation: The shims hook the Import Address Table (IAT) of the application, routing target API calls to the shim functions rather than the core operating system libraries.

Deploying Compatibility Databases

Once the correct combination of compatibility flags is validated using QFixApp, administrators use Compatadmin.exe to package the fixes into a custom database (.sdb file).

To install the custom database across Windows 2000 machines, administrators use the native installation utility:

sdbinst.exe -q path_to_database.sdb

This command registers the database with the Windows registry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. From that point forward, whenever the specified executable is launched on that machine, Windows 2000 automatically resolves the compatibility flags and applies the appropriate runtime shims transparently to the user.