Windows 95 defenses against installers that overwrite a file with an older one • Hacker News Board

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

#41

Post by toast0 » Wed, Apr 01, 2026, 10:24 PM UTC

kstrauser wrote: post #23

layer8 wrote: post #16

Earlier quoted context omitted.

> 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 update…

> 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 o…

Why would I buy a new version of Windows, if none of my existing software will work on it, so I have to buy new versions of everything? Sounds expensive.

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

#42

Post by HeckFeck » Wed, Apr 01, 2026, 10:32 PM UTC

phendrenad2 wrote: post #13

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 fun…

1-3 are covered by package managers in pretty much every Linux distro and BSD.

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

#43

Post by MarkSweep » Wed, Apr 01, 2026, 10:36 PM UTC

chihuahua wrote: post #11

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 a…

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

There is a third option: the developers knew the rules and chose to ignore them for some reason. A modern example of this is the Zig language’s decision to reverse engineer and use undocumented APIs in Windows in preference of using documented APIs.

https://codeberg.org/ziglang/zig/issues/31131

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

#44

Post by Lammy » Wed, Apr 01, 2026, 10:37 PM UTC

layer8 wrote: post #8

Lammy wrote: post #7

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

The latter, according to https://devblogs.microsoft.com/oldnewthing/20260324-00/?p=11...

Egg on my face for not scrolling down to see the comments after reading the article. Thanks!

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

#45

Post by canucker2016 » Wed, Apr 01, 2026, 10:48 PM UTC

akdev1l wrote: post #4

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

You'd have to track down some 16bit Win3.x software to install. Probably on floppy disks since CD-ROMs weren't common.

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

#46

Post by wvenable » Wed, Apr 01, 2026, 10:49 PM UTC

kstrauser wrote: post #23

layer8 wrote: post #16

Earlier quoted context omitted.

> 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 update…

> 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 o…

Raymond Chen already discussed this. Microsoft wants to sell Windows. Windows exists to run software. If Windows doesn't run software, Microsoft doesn't make that sale.

If your business runs on some obscure piece of software for which updates are neither cheap or easy, you're not going to buy Windows if it doesn't run that software.

Name and shame doesn't work because the developer isn't part of the transaction.

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

#47

Post by ElectricalUnion » Wed, Apr 01, 2026, 11:04 PM UTC

forkerenok wrote: post #2

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

Someone thought the "commit all previous operations to persistent storage" step would take just 1% of the time.

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

#48

Post by RiverCrochet » Wed, Apr 01, 2026, 11:12 PM UTC

chihuahua wrote: post #11

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 a…

Before Windows 95/3.x, there was DOS.

There were no rules in DOS, or r_x permissions like Unix.

The DOS kernel itself didn't really impose any structure on the filesystem. All that mattered was:

- The two files that comprised DOS itself (MSDOS.SYS, IO.SYS) had to be "inode" 0 and 1 on the disk in early versions,

- the kernel parsed \CONFIG.SYS on boot, and I think looked for \COMMAND.COM if you didn't specify a different shell with COMSPEC= in CONFIG.SYS. There were defaults if \CONFIG.SYS didn't exist, but of course all your DEVICE= stuff won't load and you'll probably not have a working mouse, CD-ROM, etc.

\AUTOEXEC.BAT was optional. That's it. Any other files could be anywhere else. I think the MS-DOS installer disk put files in C:\DOS by convention but that was just a convention. As long as COMMAND.COM was findable DOS would boot and be useable-and if you mucked something up you just grab your DOS boot floppy with A:\COMMAND.COM on it and fix it.

From what I recall most installers-if provided-made a directory in \ and put all their files there, mixing executables with read-write data. There was no central registry of programs or anything unless you were using a third party front-end.

Windows 3.x and 95 inherited the DOS legacy there.

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

#49

Post by xenadu02 » Wed, Apr 01, 2026, 11:22 PM UTC

rkagerer wrote: post #22

akdev1l wrote: post #4

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

This is truly unhinged Granted, but at the same time it's also resolutely pragmatic. Apparently there was already lots of software out there which expected to be able to write new versions of system components. As well as buggy software that incidentally expected to be able to write old versions, because its developers ignored Microsoft's published best practices (not to mention common sense) and and didn't bother to…

It is important to remember that Microsoft created some of this chaos to begin with. Other aspects can be attributed to "the industry didn't understand the value of $x or the right way to do $y at the time". And some of this is "nonsense you deal with when the internet and automatic updates is not yet a thing".

Why did programs overwrite system components? Because Microsoft regularly pushed updates with VC++ or Visual Studio and if you built your program with Microsoft's tools you often had to distribute the updated components for your program to work - especially the Visual C runtime and the Common Controls. This even started in the Win3.11 days when you had to update common controls to get the fancy new "3d" look. And sometimes a newer update broke older programs so installers would try to force the "correct" version to be installed... but there's no better option here. Don't do that and the program the user just installed is busted. Do it and you break something else. There was no auto-update or internet access so you had to make a guess at what the best option was and hope. Mix in general lack of knowledge, no forums or Stack Overflow to ask for help, and general incompetence and you end up with a lot of badly made installers doing absolute nonsense.

Why force everyone to share everything? Early on primarily for disk space and memory reasons. Early PCs could barely run a GUI so few hundred kilobytes to let programs have their own copy of common controls was a non-starter. There was no such thing as "just wait for everyone to upgrade" or "wait for WindowsUpdate to roll this feature out to everyone". By the early 2000s the biggest reason was because we hadn't realized that sharing is great in theory but often terrible in practice and a system to manage who gets what version of each library is critical. And we also later had the disk space and RAM to allow it.

But the biggest issue was probably Microsoft's refusal to provide a system installer. Later I assume antitrust concerns prevented them from doing more in this area. Installers did whatever because there were a bunch of little companies making installers and every developer just picked one and built all their packages with it. Often not updating their installer for years (possibly because it cost a lot of money).

Note: When I say "we" here that's doing a lot of heavy lifting. I think the Unix world understood the need for package managers and control of library versions earlier but even then the list of problems and the solutions to them in these areas varied a lot. Dependency management was far from a solved problem.

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

#50

Post by jasonfarnon » Wed, Apr 01, 2026, 11:26 PM UTC

Legend2440 wrote: post #21

bigstrat2003 wrote: post #17

Earlier quoted context omitted.

One of the craziest Raymond Chen stories is one where a Windows API call would return a pointer to a data structure the OS had allocated for the operation. The programmers at Microsoft made the data structure bigger than they needed, for future expansion. But some third party devs noticed the extra space, and started to use it to store data for their program. Then when Windows tried to start using the extra space, th…

>I still do not understand how one can consider writing to memory the OS owns to be ok. Things were different back then. People did a lot of hacky stuff to fit their programs into memory, because you were genuinely constrained by hardware limitations. Not to mention, the idea of the OS owning the machine was not as well developed as it is today. Windows 3.11 was just another program, it didn't have special permission…

"Not to mention, the idea of the OS owning the machine "

I agree--back then when computers had <=4MB or RAM I would've called hogging unused memory for some selfish speculative future use "professional malpractice".