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

51–60 of 103 posts

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

#51

Post by jasonfarnon »

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.

Whats unhinged about a periodic integrity check? Doesn't seem much different than a startup/boot check. If you're talking about security, you've come to the wrong OS.

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

#52

Post by [deleted] »

badsectoracula wrote: post #34
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…

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…

[deleted]

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

#53

Post by akdev1l »

elzbardico wrote: post #14
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…

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.

I think you guys read “unhinged” as way more negative than I meant.

Just because I am saying it’s unhinged doesn’t mean I don’t think it’s cool

I’ve never read any windows source so I can still contribute to wine but I’ve read the NT kernel is really high quality

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

#54

Post by AgentME »

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.

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

#55

Post by mrighele »

RiverCrochet wrote: post #48
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 diffe…

> I think the MS-DOS installer disk put files in C:\DOS by convention but that was just a convention.

That assume that you where going to install the OS, which assumes that you had an hard drive :-). The original IBM PC didn't, and anyway MS-DOS didn't support folders until version 2.0.

On those old PCs you would boot your computer on a floppy drive with all the files on the root of a floppy, and execute your command there. There was not much to work with anyway, check the content of the boot floppy of MSDOS 1.0 [1].

And also, especially if you had a single floppy, you wouldn't even use it: to run your software you would boot a disk with a IO.SYS, MSDOS.SYS, COMMAND.COM and an AUTOEXEC.BAT that would start your favorite word processor (WordStar of course :-D ).

[1] https://www.youtube.com/watch?v=0-X7Thsn0pI

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

#56

Post by anthk »

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.

Not too different to using MS's mimalloc to run zenlisp under OpenBSD because the core malloc will just tell good try, but GTFO to the interpreter.

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

#57

Post by Grom_PE »

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.

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

#58

Post by kelnos »

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…

> If they had taken essentially the same approach as wine and functionally created a WINEPREFIX per application then it would not be unhinged.

Man, wouldn't it have been nice if everyone had enough hard drive space in those days in order to do something like that...

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

#59

Post by wmf »

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…

They could have had file permissions. They could have had a package manager instead of third-party installers.

Also note that Microsoft Office has a long history of not following Windows rules. Microsoft didn't even set a good example.

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

#60

Post by WaterRun »

wmf wrote: post #59
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…

They could have had file permissions. They could have had a package manager instead of third-party installers. Also note that Microsoft Office has a long history of not following Windows rules. Microsoft didn't even set a good example.

In the era of Windows 95, having a network connection was still a rarity. Expecting modern systems to have package management and sandboxing mechanisms would have been 20 years ahead of their time.
Post reply on HN