← Back to context

Comment by mike_hearn

4 days ago

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.