You are right that it’s not equivalent, but the article explains why redirecting the writes wasn’t a viable option.

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

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

Well and the earliest versions of Windows 95 used FAT16 (specifically VFAT for support for LFNs or long file names). So enjoy those ridiculous cluster sizes if your hard disk even approached a gig or so.

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.

Two words: proprietary installers.

If an installer expects to be able to overwrite a file and fails to do so, it might crash, leaving the user with a borked installation.

Of course you can blame the installer, but resolution of the problem might take a long time, or might never happen, depending on the willingness of the vendor to fix it.

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

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?

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.