Windows 95 defenses against installers that overwrite a file with an older one • Hacker News Board

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

#101

Post by nikau » Tue, Apr 07, 2026, 2:18 AM UTC

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

That's because windows locks the file name vs inode like Unix, so was really the only way to update any file in use like libraries.

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

#102

Post by MarkSweep » Wed, Apr 08, 2026, 2:41 PM UTC

nektro wrote: post #98

ziml77 wrote: post #95

Earlier quoted context omitted.

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

The best statement of whether or not calling functions in ntdll is here: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...

> documentation for the WDK and Windows SDK recommends that application developers avoid calling undocumented Nt entry points

So it's safe to call documented ntdll functions. But calling undocumented functions is more risky.

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

#103

Post by MarkSweep » Wed, Apr 08, 2026, 2:59 PM UTC

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.

I understand the stated reasons and disagree with their conclusions. It seems like a lot of extra work on the part of the Zig developers to have to reverse engineer undocumented interfaces. There is potentially extra work for the Windows developers if they want to change their private implementation details that Zig programs are now relying on. And in the case where the lower level APIs are missing features implemented higher level APIs, Zig has to either reimplment the functionality themselves or not have the same level of support for Windows features that normal Win32 apps have. A concrete example is looks like Zig programs can't open serial devices:

https://codeberg.org/ziglang/zig/src/commit/6193470ceea89a98...

All this to save a little memory CPU and memory usage? The juice does not seem worth the squeeze.