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

31–40 of 103 posts

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

#31

Post by TheAmazingRace »

adrian_b wrote: post #28
akdev1l wrote: post #9

Earlier quoted context omitted.

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…

Windows 95 was not Windows NT and it still used the FAT32 file system, where it was not really possible to enforce access rights. As TFA says: 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.”

Well and the earliest versions of Windows 95 used FAT16 (specifically VFAT for support for LFNs or long file names). So enjoy those ridiculous cluster sizes if your hard disk even approached a gig or so.

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

#32

Post by acuozzo »

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.

Go to Vogons and look at all of the memory tricks people will use to get various games running on MS-DOS. This kind of juggling exactly which drivers to load, etc. is why Microsoft added the boot menu in MS-DOS 6.0 to CONFIG.SYS.

I'm not necessarily saying that this was the case here, but it smells like that to me.

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

#33

Post by badsectoracula »

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…

There was (and still is) VerInstallFile, however this was introduced in Windows 3.1 and it is possible installers wanted to also support Windows 3.0 (since there wasn't much of a time gap between the two many programs tried to support both) so they didn't use it.

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

#34

Post by badsectoracula »

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…

The thing is, Microsoft got its position of dominance exactly because they did that - and that was because by doing this, the users' programs kept working. Remember that users outnumber developers by far and the last thing Microsoft wanted was for people to not upgrade Windows because they broke their previously working programs.

This was even more important at a time when Microsoft had actual competition in the OS space and people weren't able to just go online and download updates.

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

#35

Post by topspin »

badsectoracula wrote: post #27
jjmarr wrote: post #20

Earlier quoted context omitted.

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

TBH i think a more likely explanation is that they needed to somehow identify separate instances of that data structure and they thought to store some ID or something in it so that when they encountered it next they'd be able to do that without keeping copies of all the data in it and then comparing their data with the system's.

^^ The voice of experience, here.

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

#36

Post by topspin »

anonymars wrote: post #30
kstrauser wrote: post #23

Earlier quoted context omitted.

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

Yes, but that doesn't solve the customer's problem And what does the customer do if the vendor has discontinued it? Or charges for an upgrade? Or has gone out of business? https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41... I'm pretty sure another one was "what if you're wrong/have a false positive detection, and slander another company, one with lawyers?"

> And what does the customer do if the vendor has discontinued it? Or charges for an upgrade? Or has gone out of business?

Those can all be filed under Not My Problem (as in, Microsoft's problem,) and safely ignored. On the other hand, when Highly Influential So-And-So upgrades from 3.1 to 95 or whatever, and Very Population Application v4.9.6 starts falling over, Microsoft gets the black eye whether they deserve it or not. The whole equation changes.

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

#37

Post by Krutonium »

topspin wrote: post #18
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.

IIRC Sim City 2000 is one such piece of software.

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

#39

Post by BearOso »

Krutonium wrote: post #37
topspin wrote: post #18

Earlier quoted context omitted.

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.

IIRC Sim City 2000 is one such piece of software.

It was SimCity Classic.

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

#40

Post by ErroneousBosh »

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…

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

Are you going to tell them what "32-bit Clean" meant for Mac developers, or will we let them find out that particular horror movie for themselves?

Post reply on HN