Windows 95 let installers trash its files then fixed the mess behind their backs
- Reference: 1774441806
- News link: https://www.theregister.co.uk/2026/03/25/windows_95_installers_chen/
- Source link:
The [1]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.
Simpler days compared to the pain of creating install sets now and worrying about wholesale registry destruction, or a dependency not being what a developer thought it was.
[2]
"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.
[3]
[4]
In practice, nothing stopped an installer from ignoring that rule entirely. It was not uncommon for setup programs to simply overwrite whatever was in their way, replacing Windows 95 components with their Windows 3.1 counterparts.
"You can imagine how much of a disaster this caused to the rest of the system," said Chen.
[5]
At this point, even though it is many decades since the era of Windows 95, a reader would be forgiven for wondering why the operating system allowed this at all. The answer is backward compatibility: blocking file operations risked breaking the installer itself.
[6]Once upon a time, saving your bits meant punching holes in floppies
[7]How Microsoft's legal eagles wrangled Happy Days for Windows 95
[8]Microsoft veteran explains the one weird trick that made Windows 95 restart faster
[9]How Microsoft gave customers what they wanted: An audience with Bill Gates
"This ended up creating more problems," explained Chen. "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. (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.'"
Microsoft's solution was a hidden directory ( c:\windows\sysbckup ) of commonly overwritten files. After setup finished, Windows quietly checked the file version numbers on the disk. Higher version numbers would be copied into the hidden directory, or the file in the hidden directory would replace a lower version number.
"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."
[10]
The belt-and-braces approach depended on the operating system being aware of a setup program rummaging through its internals.
Today - [11]based on recent performance - users should worry less about installers and more about what Microsoft itself is doing to Windows' system files. ®
Get our [12]Tech Resources
[1] https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=112159
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2acQUtFVWcQUPqOjh0yG4lgAAAJQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44acQUtFVWcQUPqOjh0yG4lgAAAJQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33acQUtFVWcQUPqOjh0yG4lgAAAJQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44acQUtFVWcQUPqOjh0yG4lgAAAJQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2026/03/04/chen_floppy_disks/
[7] https://www.theregister.com/2026/02/11/chen_weezer_happy_days_windows/
[8] https://www.theregister.com/2026/01/20/chen_shift_reboot_windows/
[9] https://www.theregister.com/2026/01/01/microsofts_approach_to_customer_service/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33acQUtFVWcQUPqOjh0yG4lgAAAJQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2026/03/24/windows_boss_promises/
[12] https://whitepapers.theregister.com/
Re: Explains a lot
But at least it shows that there were proper software engineers who came up with a clever solution (or kludge depending on your point of view) to try to keep the system in some form of a functioning state.
Today, the only way to fix things would be for a ground up rewrite from scratch as it's so broken it's beyond any form of reasonable repair. Oh, and some proper testing and QA validation wouldn't go amiss either.
Re: Explains a lot
> But at least it shows that there were proper software engineers who came up with a clever solution (or kludge depending on your point of view) to try to keep the system in some form of a functioning state.
But it didn't keep the system in a functioning state. Windows was plagued with so many things which could break, that it was often faster to wipe and reinstall than try and troubleshoot. Hence, customized installers and post-install scripts: the Windows power user / enterprise IT communities wanted to skip many of the post-install tasks because they did it frequently.
Re: Explains a lot
I thinkaybe you missed the point of the article, Windows was covering up for lazy third party software developers who didn't bother to code checks for version numbers of system files and just overwrote whatever they wanted.
Upgrading Windows 95 be like ..
Running the "Windows 95" upgrade CD would install to the computer as long as it detected the presence of win3.1. Else copy WIN.COM SYSTEM.INI USER.EXE to a fake Windows folder and the install would proceed. The "Windows 95" upgrade CD was identical to the standard "Windows 95" install CD. Except you had to change a "0" to a "92 in an INI file. Also, if you removed the hardware enum entries in the registry then on reboot Windows 95 would re-detect the hardware.
Didn't DOOM or Quake do that?
I distinticly remember someone installing D or Q on a server every Friday and uninstalling it before Monday morning, and said game quietly overwriting a .DLL with a vintage version, and it was never caught because of THAT feature, until it failed on one fateful day.
Either that, or it was a Myth, a part of IT Lore that shall never be forgotten even if untrue.
Can we just sandbox all user mode apps yet?
Explains a lot
This explains a lot about even today's Windows update system.
The amount of time it takes to install a monthly update on modern Windows versions must waste billions of man hours every year.