Back in the days of 16-bit Windows, many system components were redistributable, meaning that programs that used those components could include a copy of those system components and install them onto the system as part of the program’s installer. The guidance for installing the system components was that if the installer finds a copy of the system component already on the system, then they should compare the version number of the existing file with the version number of the file being installed and then overwrite the file only if the file being installed has a higher version number. if the existing file has a higher version number, then it should be left alone.

This rule relies on the fact that Windows maintains backward compatibility, so the newer version still works even if used by an older program.

This doesn’t mean that installers actually followed this guidance.

It was common for program installers to overwrite any file that was in their way, regardless of the existing file’s version number. When these installers ran on Windows 95, the replaced the Windows 95 versions of the components with the Windows 3.1 versions. You can imagine how much of a disaster this caused to the rest of the system.

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.

Basically, Windows 95 waited for each installer to finish, and then went back and checked its work, fixing any mistakes that the installer made.

An earlier design simply blocked the installer’s attempt to overwrite the file, but this ended up creating more problems. Some installers declared the installation to be a failure and gave up. Otherwise displayed an error message to the user and asked the user what to do next. (Like the user knows what to do next.) You even had installers that took even more extreme measures and said, “Okay, fine, I can’t overwrite the file, so I’m going to reboot the system and then overwrite the file from a batch file, see if you can stop me.”

Redirecting the write to a dummy file didn’t work because some installers had a validation step where they checked that the files on disk have the correct checksum, so they would notice that their attempt to overwrite the file was unsuccessful and error out.

The way that worked best was to let the installer overwrite anything it wanted and then go back and try to clean up the mess.

Bonus chatter: Some components addressed this problem by providing their own installer for the component, and telling installers, “You are not allowed to install these component file directly. Instead, you must run our custom installer. Yes, this disrupts your installer’s UI, but you installer authors have shown that you can’t be trusted to install files on your own. It’s your own fault.”