Windows 95 defenses against installers that overwrite a file with an older one

It must have been difficult and frustrating to work as part of the Windows team back in those days.

You see all the wacky software that doesn't follow the rules properly, does whatever it wants, breaks things. And you have to figure out how Windows can accommodate all that software, keep it from breaking, and also prevent it from messing up a computer or undo the damage.

They did not have the option of saying "this app developer wrote shitty software, sucks to be them, not my problem."

I wonder how much of this problem was caused by lack of adequate documentation describing how an installer should behave, and how much was developers not reading that documentation and being content when it works on their machine.

When I was a kid, I released a small GUI program online that I made with either VB6 or VB.NET. The program used the standard open-file dialog. When I created the installer for my program through VB's release wizard, there was a page where it pointed out that my program depended on a certain system library (because of the open-file dialog) and it asked me if I wanted to include that library in the installer. I think the default answer was yes, or maybe it wasn't but it sounded like an obvious thing to enable so I did it. Apparently this screwed over and broke open-file dialogs globally across Windows for everyone who wasn't on the same version of Windows as me. Whoops! It's too bad that VB had such a foot-gun in it, and that the article's workaround didn't save those users.

>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.

This is truly unhinged. I wonder if running an installer under wine in win95 mode will do this.

> Whenever an installer finished, Windows went and checked whether any of these commonly-overwritten files had indeed been overwritten.

> Basically, Windows 95 waited for each installer to finish

How could it tell that a particular process was an installer? Just anything that writes to the PROGRA~1 or WINDOWS folders?

In my 25 years of using Windows I've grown so much disdain towards annoying, broken, slow installers that I started to instead extract them like zip archives, using various tools: 7-Zip, UniExtract, Observer plugin for Far Manager, sometimes even manual carving.

Most things just worked after being extracted like that. Some things needed a few registry entries, or regsvr32 some dll files.

OMG, is this the reason why every other installer would get stuck at 99% forever? :D

I love the naiveté of this approach.

Unlike <arbitrary heuristic>, it's so easy to reason about. I wish this kind of approach was still viable.

And 6-7 years later the `WinSxS` directory was born and these days it is tens of gigabytes.

`Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase`

In an administrator command prompt. You can thank me when it's finished ;-)

The sad lesson is to be both proactive and reactive if you want a clean environment. Trust, verify, and stick around to clean up someone else's mess after the fact.

Windows, especially old versions, were beautifully pragmatic. Think about the things that would need to exist on an open-source OS to match this functionality. You'd need to:

1. Convince people to distribute programs via installers.

2. Provide some way that installers can tell the OS that they're an installer (and not invent 5 different ways to do this!)

3. Convince the creators of installers to actually use that function.

4. Convince library creators to maintain backward compatibility (big ask).

5. Convince people to not fork said libraries, creating ambiguous upgrade paths.

6. If there are multiple distros, convince them all to use the same backup/restore format for libraries (and not treat their own favorite libraries as "special")