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

71–80 of 103 posts

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

#71

Post by gzread »

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

I agree. Why should the person who bought a computer be allowed to own it? Phone ecosystems got this the right way - the company that made the device owns it, and the person who bought it does not!

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

#72

Post by eviks »

gzread wrote: post #71
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

I agree. Why should the person who bought a computer be allowed to own it? Phone ecosystems got this the right way - the company that made the device owns it, and the person who bought it does not!

Don't speak in empty slogans, connect it to the article/comment!

Some app does some thing, then the OS reverts it! Where is "you" and "own" in this process? Do you own the "C:\Windows\SYSBCKUP" folder? Do you own the undo process?

Would your "ownership" rights increase if instead the OS didn't waste any space, but simply blocked downgrades of system components without user warning/intervention? Or had an even better process?

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

#73

Post by kaashif »

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…

This comment is pretty wild:

> In addition to what @The-King-of-Toasters said, the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users.

Uh so what if the application developer isn't around any more?

The fact that they consider the worst case to be one where the application is still actively supported and the developer is willing to put up with this nonsense is pretty surprising. Not sure how anyone could believe that.

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

#74

Post by hulitu »

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…

>back in those days.

> You see all the wacky software that doesn't follow the rules properly, does whatever it wants, breaks things.

Just like today. Software is hard, software engineering even harder.

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

#75

Post by hulitu »

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…

> The thing is, Microsoft got its position of dominance exactly because they did that

Yeah, right. No bribes, no preinstalled software...

They dominated by ... accident.

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

#76

Post by hulitu »

toast0 wrote: post #41
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…

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.

But your computer will be secure and then pedophiles and terrorirst wouldn't stand a chance.

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

#77

Post by gzread »

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…

Ask the Zig people, who just started relying on undocumented unstable Windows behaviour intentionally due to some kind of religious belief: https://codeberg.org/ziglang/zig/issues/31131

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

#78

Post by guenthert »

throwA29B wrote: post #66
MarkSweep wrote: post #43

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

"As Zig has evolved, it has become a target to avoid calling Win32 APIs from kernel32.dll etc., instead using lower-level ones in ntdll.dll."

If we needed an example of why we should avoid using passive voice, this is it.

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

#79

Post by mike_hearn »

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…

It's easy to forget in these discussions that Microsoft didn't have infinity resources available when writing Windows, and often the dodgy things apps were doing only became clear quite late in the project as app compatibility testing ramped up. Additionally, they had to work with the apps and history they had, they couldn't make apps work differently.

You say, oh, obviously you just should redirect writes to a shadow layer or something (and later Windows can do that), but at the time they faced the rather large problem that there is no formal concept of an installer or package in Windows. An installer is just an ordinary program and the OS has no app identity available. So, how do you know when to activate this redirection, and what is the key identifying the layer to which redirects happen, and how do you handle the case where some writes are upgrades and others are downgrades, etc, and how do you do all that in a short amount of time when shipping (meant literally in those days) will start in just a few months?

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

#80

Post by loevborg »

guenthert wrote: post #78
throwA29B wrote: post #66

Earlier quoted context omitted.

>ignore them for some reason The reasons are clearly stated in the issue you have linked.

"As Zig has evolved, it has become a target to avoid calling Win32 APIs from kernel32.dll etc., instead using lower-level ones in ntdll.dll." If we needed an example of why we should avoid using passive voice, this is it.

This sentence doesn't include examples of the passive voice.
Post reply on HN