wow. this is insane. never new such mechanic was ever remotely considered or possible. pretty neat
Windows 95 defenses against installers that overwrite a file with an older one
91–100 of 103 posts
Re: Windows 95 defenses against installers that overwrite a file with an older one
#92Earlier 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…
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 shado…
I mean it looks like they did try to redirect writes somehow. They probably tried more sane options until they arrived here.
>there is no formal concept of an installer or package in Windows.
this one is on them, I think package managers already existed - doesn’t seem like there was ever a blocker for windows to have a package manager but Microsoft never bothered until very recently
Re: Windows 95 defenses against installers that overwrite a file with an older one
#93>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.
I agree, it's unhinged for applications to overwrite newer versions of system files with older ones.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#94Earlier quoted context omitted.
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 shado…
I mean it looks like they did try to redirect writes somehow. They probably tried more sane options until they arrived here. >there is no formal concept of an installer or package in Windows. this one is on them, I think package managers already existed - doesn’t seem like there was ever a blocker for windows to have a package manager but Microsoft never bothered until very recently
With hindsight sure, but I don't think any desktop operating systems had package managers in that era. macOS certainly didn't. NeXTStep had their .app bundle concept, but no legacy. And UNIX package managers were of no use - few of them properly supported third party packages distributed independently of the OS vendor, especially not ones that could upgrade the OS itself.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#95Earlier 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…
Wow! What a mind-bogglingly stupid idea. I will cancel my plans to learn Zig.
My excitement for Zig dropped the longer they stayed at 0.x (and they really have meant 0.x with the breaking changes they were making). This decision from them completely killed it for me.
I understood not using the C Runtime and instead creating direct wrappers over the Win32 API, but going a level lower to APIs that are not guaranteed to be stable is nutty.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#96Windows, 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…
That's not exactly what Windows installers did. They absolutely created 10 different ways to install software; they didn't really advertised they were an installer; the only backward compatible thing there are the MS libraries; there was no common backup/restore format. Instead, the Unix people made a mechanism for random programs to use their own libraries and not touch the system one. In fact, Windows had one too,…
One of the biggest pitfalls in understanding the world is interpreting everything as an absolute. If someone says "dogs have four legs", you might think "well, I saw a dog with three legs, so there's no value in the idea that dogs have four legs, and I'll conclude that if I see tracks from an animal that seems to have four legs, it's impossible to know if it's a dog or a giant centipede". It's a pernicious little quirk of our minds that we fall for this kind of thinking.
To wit. The idea that installers on Windows behaved the way I described is an interesting fact. The idea that a few installers did things in unusual ways is a much less interesting fact. Putting them on the same level robs you of the insight, and if this is a pattern then there are a lot of things you simply can't learn, because an exception could be found.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#97Windows, 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…
1-3 are covered by package managers in pretty much every Linux distro and BSD.
I think you misunderstand. 1-3 are not goals, they're steps to the goal. Linux and BSD have different goals from Windows.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#98Earlier quoted context omitted.
Wow! What a mind-bogglingly stupid idea. I will cancel my plans to learn Zig.
My excitement for Zig dropped the longer they stayed at 0.x (and they really have meant 0.x with the breaking changes they were making). This decision from them completely killed it for me. I understood not using the C Runtime and instead creating direct wrappers over the Win32 API, but going a level lower to APIs that are not guaranteed to be stable is nutty.
ntdll.dll APIs are guaranteed to be stable though
Re: Windows 95 defenses against installers that overwrite a file with an older one
#99Earlier quoted context omitted.
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…
Yep I don't think the Microsoft installer was there until version 4 or 5. Around the time MS was making DOS more "user-friendly" with things like /LONGDESCRIPTIVESWITCHES, DOSKEY, MIRROR, UNDELETE and UNFORMAT. It looked like the blue text-mode Windows XP installer.
Re: Windows 95 defenses against installers that overwrite a file with an older one
#100Earlier quoted context omitted.
Wow! What a mind-bogglingly stupid idea. I will cancel my plans to learn Zig.
My excitement for Zig dropped the longer they stayed at 0.x (and they really have meant 0.x with the breaking changes they were making). This decision from them completely killed it for me. I understood not using the C Runtime and instead creating direct wrappers over the Win32 API, but going a level lower to APIs that are not guaranteed to be stable is nutty.
Part of this was the allowed or special treatment given to Zig at certain sites. It then allowed the false impression to be created of it being production ready and/or far more stable than it actually is. Often intentionally overlooking or glossing over that it's still in beta, making breaking changes, and has thousands of issues (over 3,000 on GitHub).
They were allowed to have it both ways, pre-1.0 and yet somehow (near, like, just about) production-ready. Almost there, for years. Strangely given a free pass to get away with this, for what looked to be undisclosed financial and other fuzzy reasons.