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

61–70 of 103 posts

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

#61

Post by eviks »

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…

The biggest cause for this problem isn't lack of docs, but poor OS design. Like, why would you let apps change anything without restrictions to begin with? Of course, then you have to have some dumb hidden folder wasting space to restore the changes, and this "waste space for no good reason because we can't architect properly" is still a common issue

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

#62

Post by justsomehnguy »

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.

Then blindly overwriting the shared libraries despite the guidance what the vendor of the OS provides is actually hinged, yes?

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

#63

Post by justsomehnguy »

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…

> 2. Provide some way that installers can tell the OS that they're an installer (and not invent 5 different ways to do this!)

It is still blows my mind what to tell the distro flavour and version I still need to rely on the shell globbing.

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

#64

Post by justsomehnguy »

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.

Yes. For whatever reason my father used C:\SYS and I inherited it, along with C:\WIN for Windows.

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

#65

Post by iknowstuff »

MarkSweep wrote: post #43
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 undocu…

Kinda wild

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

#66

Post by throwA29B »

MarkSweep wrote: post #43
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 undocu…

>ignore them for some reason

The reasons are clearly stated in the issue you have linked.

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

#67

Post by jasomill »

eviks wrote: post #61
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…

The biggest cause for this problem isn't lack of docs, but poor OS design. Like, why would you let apps change anything without restrictions to begin with? Of course, then you have to have some dumb hidden folder wasting space to restore the changes, and this "waste space for no good reason because we can't architect properly" is still a common issue

You're not wrong, but largely as a result of dubious architectural decisions made in the name of backwards compatibility and minimal hardware requirements, Microsoft sold 40 million copies of Windows 95 in its first year, compared to 300,000 copies of Windows NT 3.1.

Consider:

Windows 95 ran the vast majority of MS-DOS and Windows 3.1 applications with minimal performance loss, supported MS-DOS and Windows 3.x drivers for hardware that lacked 32-bit driver support, and ran acceptably on a 386 with as little as 4 MB RAM.

The properly architected Windows NT 3.1, released two years before Windows 95, had limited MS-DOS and Windows 3.1 application support, required NT-specific drivers for all hardware, and required 12 MB RAM to boot, 16 MB to do anything useful, and you really wanted a 486 for decent performance.

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

#68

Post by [deleted] »

eviks wrote: post #61
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…

The biggest cause for this problem isn't lack of docs, but poor OS design. Like, why would you let apps change anything without restrictions to begin with? Of course, then you have to have some dumb hidden folder wasting space to restore the changes, and this "waste space for no good reason because we can't architect properly" is still a common issue

[deleted]

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

#69

Post by gzread »

MarkSweep wrote: post #43
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 undocu…

Wow! What a mind-bogglingly stupid idea. I will cancel my plans to learn Zig.

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

#70

Post by eviks »

jasomill wrote: post #67
eviks wrote: post #61

Earlier quoted context omitted.

The biggest cause for this problem isn't lack of docs, but poor OS design. Like, why would you let apps change anything without restrictions to begin with? Of course, then you have to have some dumb hidden folder wasting space to restore the changes, and this "waste space for no good reason because we can't architect properly" is still a common issue

You're not wrong, but largely as a result of dubious architectural decisions made in the name of backwards compatibility and minimal hardware requirements, Microsoft sold 40 million copies of Windows 95 in its first year, compared to 300,000 copies of Windows NT 3.1. Consider: Windows 95 ran the vast majority of MS-DOS and Windows 3.1 applications with minimal performance loss, supported MS-DOS and Windows 3.x driver…

Now try a 3rd comment that actually connects to the design deficiency described in the article instead of a generic grievance about rearchitectrue that included a gazillion of changes
Post reply on HN