Compatibility has long been a cornerstone of Microsoft’s Windows operating system, a challenge that has persisted since its inception. In the early days of Windows 3.1, users were tasked with identifying applications themselves, particularly when faced with shared filenames. Veteran Microsoft engineer Raymond Chen recalls the ambiguity surrounding C:MAILMAIL.EXE, which could represent either Microsoft Mail or cc:Mail for MS-DOS, depending on the context.
During this period, the APPS.INF file served as a guide for Windows, but it was ultimately up to the user to discern which application was which. A simpler time, indeed, where the onus of compatibility rested squarely on the shoulders of the user.
Advancements with Windows 95
The landscape shifted dramatically with the introduction of Windows 95, which brought forth an application compatibility database that allowed the operating system to adapt based on compatibility flags. This innovation enabled Microsoft to automatically patch programs when a mere tweak to the operating system would not suffice.
However, patching third-party code is fraught with risks. Chen explains that the Windows 95 team exercised caution by obtaining written permission from vendors before implementing any patches. This process involved a thorough consultation, where the team detailed the issues at hand and the proposed fixes. In return, they sought vital information from the vendors regarding affected product versions and a commitment to rectify the problems in future releases, ensuring that subsequent versions would not rely on the temporary patches.
Detection Mechanisms
Identifying applications eligible for patches became a more systematic process with Windows 95. Instead of depending on user input, the operating system utilized detection strings stored in the Registry. When a 16-bit module was loaded, particularly one targeting a version of Windows prior to 4.0, the kernel would systematically test each detection string until a match was found.
These detection strings were not mere checksums; they were intricately designed sequences decoded into bytes. The initial byte determined the matching algorithm, which guided the subsequent checks. “In practice, you tend to see a lot of file size matches,” Chen notes, adding that file content matches were rare due to the additional I/O costs they incurred.
While tools eventually emerged to facilitate the creation of these detection strings, earlier versions required manual input, a task that demanded precision and attention to detail. Upon finding a match, the subkeys would indicate which segments required patching, with the values containing the binary data necessary for the application of the patch.
Interestingly, the naming conventions for these patches followed a traditional format: ‘Add’ patches were simply labeled as Add, while ‘Change’ patches were designated as Change. If multiple patches of the same type were present, numeric suffixes were added to distinguish them.
Microsoft’s unwavering commitment to backward compatibility has often been heralded as a significant factor in its success during the late 20th and early 21st centuries. As we reflect on the legacy of Windows 95, one can only ponder how the engineers of that era would perceive the hundreds of millions of devices rendered obsolete with the cessation of support for Windows 10.
