Software installers have been troublemakers from the beginning. But back in the Windows 95 era, they were not just buggy; they were reckless. According to Raymond Chen, a Microsoft engineer who worked on Windows 95, installers would routinely overwrite the operating system's own system files without bothering to check version numbers.
The problem traces back to the days of 16-bit Windows, when many system components were redistributable. Installers could include copies of those components and place them on a target computer. The setup program was expected to compare the version numbers of what was on the system and what was being copied, only overwriting if the file being installed had a higher version number.
In theory, this made sense. "This rule relies on the fact that Windows maintains backward compatibility, so the newer version still works even if used by an older program," Chen wrote. But in practice, installers simply ignored this rule. They would delete whatever stood in their way, often replacing Windows 95 components with Windows 3.1 counterparts instead. The damage was immediate and severe, breaking the system for other applications that depended on the newer files.
Microsoft faced a dilemma. Blocking file operations risked breaking the installer itself, since many developers had never tested what happened when their setup programs couldn't overwrite files. Some installers declared the installation to be a failure and gave up. Others displayed an error message to the user and asked the user what to do next. Some took even more extreme action: they would reboot the system and attempt the overwrite again from a batch file, betting that Windows couldn't stop them a second time.
Rather than wage war with installers, Microsoft adopted a more pragmatic strategy. Windows 95 worked around this by keeping a backup copy of commonly-overwritten files in a hidden C:\Windows\SYSBCKUP directory. Whenever an installer finished, Windows went and checked whether any of these commonly-overwritten files had indeed been overwritten. If so, and the replacement has a higher version number than the one in the SYSBCKUP directory, then the replacement was copied into the SYSBCKUP directory for safekeeping. Conversely, if the replacement has a lower version number than the one in the SYSBCKUP directory, then the copy from SYSBCKUP was copied on top of the rogue replacement.
This silent correction process happened behind the scenes, invisible to users. "Basically," wrote Chen, "Windows 95 waited for each installer to finish, and then went back and checked its work, fixing any mistakes that the installer made." It was a graceful workaround to a stubborn problem: you couldn't fix bad installers directly, but you could let them run and then clean up after them.
For modern Windows users, there's an ironic coda. Today's installers are far more disciplined, thanks to better tools and practices. But users should worry less about installers and more about what Microsoft itself is doing to Windows' system files. The compatibility challenges of 1995 may feel quaint in retrospect, but they reveal something fundamental about software design: defending against chaos sometimes requires tolerance and repair rather than prevention alone.
For more details on how Windows 95 handled these compatibility challenges, see Raymond Chen's post on The Old New Thing, where he regularly shares insights from Windows development history.