9 ms·

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

168 points by michelangelo 6mo ago

forkerenok 6mo ago
OMG, is this the reason why every other installer would get stuck at 99% forever? :D
- calgarymicro 6mo ago
  It doesn't say for certain, but assuming the version of this they settled on (restoring components after the installation finished) is what they shipped in the original version of Windows 95, then no, I don't think this could have caused hangs in the installer itself (unless Win95 misjudged whether the installer had completed or not and started the restore process early?).
- elzbardico 6mo ago
  No, most likely bad algorithms for dealing with registry stuff. The kind of thing that worked well on tester machines with small registry sizes and exploded in the real world.
- ElectricalUnion 6mo ago
  Someone thought the "commit all previous operations to persistent storage" step would take just 1% of the time.
akdev1l 6mo ago
>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.
- justsomehnguy 6mo ago
  Then blindly overwriting the shared libraries despite the guidance what the vendor of the OS provides is actually hinged, yes?
- calgarymicro 6mo ago
  > If . . . 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. This as well. I know there are a million ways for a malicious installer to brick Win95, but a particularly funny one is hijacking the OS to perpetually rewrite its own system components back to compromised version number ∞ whenever another installer tries to clean things up.
- bombcar 6mo ago
  > This is truly unhinged. This is bog-standard boring stuff (when presented with a similar problem, Linux invented containers lol) - read some of his other posts to realize the extent Microsoft went to maintain backwards compatibility - some are insane, some no doubt led to security issues, but you have to respect the drive.
  - akdev1l 6mo ago
    It’s not bog-standard. Containers are not equivalent to doing what is described in the article. Containers are in fact redirecting writes so an installer script could not replace system libraries. The equivalent would be a Linux distro having the assumption that installer scripts will overwrite /usr/lib/libopenssl.so.1 with its own version and just keeping a backup somewhere and copying it back after the script executes. No OS that I know of does that because it’s unhinged and well on Linux it would probably break the system due to ABI compatibility. If they had taken essentially the same approach as wine and functionally created a WINEPREFIX per application then it would not be unhinged. edit: also to be clear, I respect their commitment to backwards compatibility which is what leads to these unhinged decisions. I thoroughly enjoy Raymond Chen’s dev blog because of how unhinged early windows was.
    - 6mo ago
Lammy 6mo ago
> 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?
- layer8 6mo ago
  The latter, according to https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=112159&commentid=143977#:~:text=Didn%E2%80%99t. https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=11...
  - Lammy 6mo ago
    Egg on my face for not scrolling down to see the comments after reading the article. Thanks!
chihuahua 6mo ago
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.
- layer8 6mo ago
  > 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. It was mostly the latter. And when Windows broke, people would blame it on Microsoft, not on the software they installed. The same if the software broke. And you didn’t have online updates at the time that could retroactively add fixes. So Microsoft had to do everything they could to ensure broken software would still work, while also keeping Windows working, the best they could.
  - kstrauser 6mo ago
    > So Microsoft had to do everything they could to ensure broken software would still work I think they chose to do everything they could to keep it limping along. An alternative would've been a name-and-shame approach, like "This program crashed because the author made this mistake: [short description or code or whatever]", and leave them out to try until the devs stopped doing those dumb things. After a few years of pain, people would've gotten with the program, so to speak. Instead, they chose the path that put zero pressure on devs to write correctly-behaving software.
    - acuozzo 6mo ago
      > After a few years of pain, people would've gotten with the program, so to speak. Not necessarily. This was still very much the time in which choosing to stick with an old version which worked (e.g. Windows 3.1) wasn't uncommon. Just look at how many people jumped from XP to 7 due to the network effect of "Vista sucks" and then multiply that by the fact that, at the time of 3.1->95, people had far fewer computer security concerns, if any.
1970-01-01 6mo ago
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.
phendrenad2 6mo ago
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")
- marcosdumay 6mo ago
  That's not exactly what Windows installers did. They absolutely created 10 different ways to install software; they didn't really advertised they were an installer; the only backward compatible thing there are the MS libraries; there was no common backup/restore format. Instead, the Unix people made a mechanism for random programs to use their own libraries and not touch the system one. In fact, Windows had one too, but most applications still decided they need to break the system.
  - phendrenad2 6mo ago
    One of the biggest pitfalls in understanding the world is interpreting everything as an absolute. If someone says "dogs have four legs", you might think "well, I saw a dog with three legs, so there's no value in the idea that dogs have four legs, and I'll conclude that if I see tracks from an animal that seems to have four legs, it's impossible to know if it's a dog or a giant centipede". It's a pernicious little quirk of our minds that we fall for this kind of thinking. To wit. The idea that installers on Windows behaved the way I described is an interesting fact. The idea that a few installers did things in unusual ways is a much less interesting fact. Putting them on the same level robs you of the insight, and if this is a pattern then there are a lot of things you simply can't learn, because an exception could be found.
- HeckFeck 6mo ago
iamcalledrob 6mo ago
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.
ruevs 6mo ago
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 ;-)
AgentME 6mo ago
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.
Grom_PE 6mo ago
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.
uxp100 6mo ago
> 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. Aha, that’s why they do that.
Macha 6mo ago
I find articles like this a good counter to the idea that typical software used to be better in the past (usually with an appeal to an idea that people were “real programmers” in those days and anything other than C as used in the 90s is a modern extravagance)
intensifier 6mo ago
This existed until Windows XP but with different name and behavior. Only from Vista, they added permissions to restrict user and third party programs to modify system files easily.
thecaio 6mo ago
wow. this is insane. never new such mechanic was ever remotely considered or possible. pretty neat

168 points by michelangelo 6mo ago

forkerenok 6mo ago

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

calgarymicro 6mo ago
It doesn't say for certain, but assuming the version of this they settled on (restoring components after the installation finished) is what they shipped in the original version of Windows 95, then no, I don't think this could have caused hangs in the installer itself (unless Win95 misjudged whether the installer had completed or not and started the restore process early?).
elzbardico 6mo ago
No, most likely bad algorithms for dealing with registry stuff. The kind of thing that worked well on tester machines with small registry sizes and exploded in the real world.
ElectricalUnion 6mo ago
Someone thought the "commit all previous operations to persistent storage" step would take just 1% of the time.

akdev1l 6mo ago

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

justsomehnguy 6mo ago
Then blindly overwriting the shared libraries despite the guidance what the vendor of the OS provides is actually hinged, yes?
calgarymicro 6mo ago
> If . . . 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. This as well. I know there are a million ways for a malicious installer to brick Win95, but a particularly funny one is hijacking the OS to perpetually rewrite its own system components back to compromised version number ∞ whenever another installer tries to clean things up.
bombcar 6mo ago
> This is truly unhinged. This is bog-standard boring stuff (when presented with a similar problem, Linux invented containers lol) - read some of his other posts to realize the extent Microsoft went to maintain backwards compatibility - some are insane, some no doubt led to security issues, but you have to respect the drive.
- akdev1l 6mo ago
  It’s not bog-standard. Containers are not equivalent to doing what is described in the article. Containers are in fact redirecting writes so an installer script could not replace system libraries. The equivalent would be a Linux distro having the assumption that installer scripts will overwrite /usr/lib/libopenssl.so.1 with its own version and just keeping a backup somewhere and copying it back after the script executes. No OS that I know of does that because it’s unhinged and well on Linux it would probably break the system due to ABI compatibility. If they had taken essentially the same approach as wine and functionally created a WINEPREFIX per application then it would not be unhinged. edit: also to be clear, I respect their commitment to backwards compatibility which is what leads to these unhinged decisions. I thoroughly enjoy Raymond Chen’s dev blog because of how unhinged early windows was.
  - 6mo ago

Lammy 6mo ago

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

layer8 6mo ago
The latter, according to https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=112159&commentid=143977#:~:text=Didn%E2%80%99t. https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=11...
- Lammy 6mo ago
  Egg on my face for not scrolling down to see the comments after reading the article. Thanks!

chihuahua 6mo ago

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.

layer8 6mo ago
> 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. It was mostly the latter. And when Windows broke, people would blame it on Microsoft, not on the software they installed. The same if the software broke. And you didn’t have online updates at the time that could retroactively add fixes. So Microsoft had to do everything they could to ensure broken software would still work, while also keeping Windows working, the best they could.
- kstrauser 6mo ago
  > So Microsoft had to do everything they could to ensure broken software would still work I think they chose to do everything they could to keep it limping along. An alternative would've been a name-and-shame approach, like "This program crashed because the author made this mistake: [short description or code or whatever]", and leave them out to try until the devs stopped doing those dumb things. After a few years of pain, people would've gotten with the program, so to speak. Instead, they chose the path that put zero pressure on devs to write correctly-behaving software.
  - acuozzo 6mo ago
    > After a few years of pain, people would've gotten with the program, so to speak. Not necessarily. This was still very much the time in which choosing to stick with an old version which worked (e.g. Windows 3.1) wasn't uncommon. Just look at how many people jumped from XP to 7 due to the network effect of "Vista sucks" and then multiply that by the fact that, at the time of 3.1->95, people had far fewer computer security concerns, if any.

1970-01-01 6mo ago

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.

phendrenad2 6mo ago

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")

marcosdumay 6mo ago
That's not exactly what Windows installers did. They absolutely created 10 different ways to install software; they didn't really advertised they were an installer; the only backward compatible thing there are the MS libraries; there was no common backup/restore format. Instead, the Unix people made a mechanism for random programs to use their own libraries and not touch the system one. In fact, Windows had one too, but most applications still decided they need to break the system.
- phendrenad2 6mo ago
  One of the biggest pitfalls in understanding the world is interpreting everything as an absolute. If someone says "dogs have four legs", you might think "well, I saw a dog with three legs, so there's no value in the idea that dogs have four legs, and I'll conclude that if I see tracks from an animal that seems to have four legs, it's impossible to know if it's a dog or a giant centipede". It's a pernicious little quirk of our minds that we fall for this kind of thinking. To wit. The idea that installers on Windows behaved the way I described is an interesting fact. The idea that a few installers did things in unusual ways is a much less interesting fact. Putting them on the same level robs you of the insight, and if this is a pattern then there are a lot of things you simply can't learn, because an exception could be found.
HeckFeck 6mo ago

iamcalledrob 6mo ago

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.

ruevs 6mo ago

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 ;-)

AgentME 6mo ago

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.

Grom_PE 6mo ago

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.

uxp100 6mo ago

> 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. Aha, that’s why they do that.

Macha 6mo ago

I find articles like this a good counter to the idea that typical software used to be better in the past (usually with an appeal to an idea that people were “real programmers” in those days and anything other than C as used in the 90s is a modern extravagance)

intensifier 6mo ago

This existed until Windows XP but with different name and behavior. Only from Vista, they added permissions to restrict user and third party programs to modify system files easily.

thecaio 6mo ago

wow. this is insane. never new such mechanic was ever remotely considered or possible. pretty neat