Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

11–20 of 103 posts

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

#11

Post by chihuahua »

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.

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

#13

Post by phendrenad2 »

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

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

#14

Post by elzbardico »

akdev1l wrote: post #9
bombcar wrote: post #6

Earlier quoted context omitted.

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

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

Man, after looking at the veritable pile of stinking matter that is claude code, compare it with the NT 4 source leak.

Windows may have suffered its share of bad architectural decisions, but unhinged is a word that I wouldn't apply to their work on Windows.

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

#15

Post by elzbardico »

forkerenok wrote: post #2

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

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.

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

#16

Post by layer8 »

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.

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.

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

#17

Post by bigstrat2003 »

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…

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, those applications would crash.

Reasonable people can disagree on a lot of things in programming. But I still do not understand how one can consider writing to memory the OS owns to be ok. It's sheer professional malpractice to do that kind of thing. With stuff like that, I don't think that any amount of documentation would have helped. The issue was that those programmers simply did not care about anything except getting their own program working, and did whatever the most expedient method was to get there.

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

#18

Post by topspin »

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…

One workaround Microsoft has done for use-after-free is detecting when an application is prone to this and using an allocator that doesn't actually free RAM immediately. It believe that lovely bit of fun is a function of "Heap Quarantine".

Yes, the real, can't say no world of system software is not what one might wish.

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

#20

Post by jjmarr »

bigstrat2003 wrote: post #17
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…

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…

> But I still do not understand how one can consider writing to memory the OS owns to be ok.

Your manager tells you to reduce memory usage of the program "or else".

Post reply on HN