Software Upgrades and Shared System Components

Paul Tomblin wrote about the new "Protected System File" concept of Microsoft Windows 2000, which is supposed to elimintate the DLL conflicts common in earlier versions of Windows by having applications install any needed DLLs into their own directory:

The problem I see is this: They make every program install required DLLs into its own directory, and then use this "copy-on-write" paradigm to make sure that it's not too expensive to keep 47 bazillion copies of the same DLL. The only problem is if the DLL is something common like DirectX - if you upgrade the DirectX DLLs for one game, it will make a copy of that DLL for that game, and all your other games will still be running the old version of DirectX. Maybe a plus if the upgrade breaks things, but a minus if the upgrade fixes things!

Yes, but it's the Right Thing (TM). If a system-wide upgrade is a good idea, the vendor (in this case, Micros~1) should release a system update.

Installing some random application program should not install new or modified operating system components in any shared location. At most it should offer to run the vendor-supplied system upgrade.

In this regard, software is only different than hardware in the relative difficulty of screwing things up. If I buy a board from XYZco to stick in my PC, just because the engineers at XYZco think that polypropylene capacitors are better than ceramic capacitors doesn't mean that I want the installation process for the XYZco board to replace all of the old ceramic capacitors in the rest of my system. While it's difficult to imagine how such a hardware upgrade would happen, people running Windows seem to take it for granted that software should work that way. After all, newer is better, right?

Back to Eric's home page

Last updated March 16, 2000

eric@brouhaha.com

check now