In a recent revelation shared on his blog, Raymond Chen, a Microsoft engineer and noted historian of Windows, provided intriguing insights into the inner workings of Windows 95’s installation process. The operating system employed a straightforward yet effective method to determine whether a setup program had been executed. This was achieved by analyzing the executable’s name and cross-referencing it against a carefully curated list of keywords.
How Windows 95 Identified Installers
The criteria for identifying an installer were remarkably simple. If the filename included terms such as “setup,” “install,” or “inst,” the system would recognize it as an installer. This recognition would then prompt Windows 95 to initiate a routine designed to repair any system files that might have been compromised during the installation process. Interestingly, Chen noted that the list of identifiers included three non-English entries, which he humorously attributed to his own guesses for Italian, Turkish, and Hungarian translations. The complete list of terms consisted of six entries: setup, install, inst, imposta, ayarla, and felrak.
Chen pointed out a redundancy in the list, suggesting that the term “install” was unnecessary since any filename containing it would inherently include “inst.” He speculated that the shorter version may have been added later to capture installers with unconventional names, such as “blahinst,” without removing the original entry.
For executables that did not match any of the predefined terms, Windows 95 conducted a secondary check. This involved scanning the path to the executable for the presence of the word “Setup.” Additionally, a live verification process was implemented following the installation of multimedia drivers via an INF file, a precautionary measure taken due to the tendency of these drivers to overwrite critical system DLLs.
Reflecting on the installation practices of that era, Chen noted that many installers would replace system files without verifying their versions, in direct violation of Microsoft’s guidelines that stipulated a file should only be replaced by a newer version. For instance, an installer using Windows 3.1 versions of shared DLLs could inadvertently obscure the newer Windows 95 files, leading to failures in programs reliant on those updated files.
To mitigate these risks, Windows 95 maintained backup copies of frequently overwritten files in a hidden directory located at C:WindowsSYSBCKUP. After allowing each installer to complete its process, the operating system would review the changes made and restore the correct versions of any files that had been downgraded. This safety mechanism relied heavily on the system’s ability to accurately detect when an installer was in operation. Consequently, a setup routine with an unconventional name might evade detection, while a standard program named something like instant.exe could trigger the repair process unnecessarily.
Furthermore, the file verification was often postponed until the next system boot. Chen explained that certain installers, unable to replace files currently in use, would revert to MS-DOS to execute a batch file for file replacement, necessitating a restart of Windows. Therefore, the cleanup process had to wait for the reboot to address any alterations made by the batch file.
Remarkably, the legacy of this file repair mechanism continues to influence modern operating systems, with Windows 11 users still relying on a system that traces its roots back to the filename scanning methods established in 1995.
