[snip]
>
>Yes. Under Win2K you're not supposed to put DLLs in the Windows folders.
>
And that one decision makes for a tremendous improvement in stability! It will allow stability issues to be resolved by pointing to the directory where the bad dll resides. My feeling about Win95's stability issues were that drivers made by peripheral vendors were most of the problem, but it was not easy, as a mere consumer, to separate them out except by experiementing to determine the most stable peripherals, an expensive thing to do.

With this policy, you can almost kiss DLL hell goodbye. It will also make for friendlier relations with 3rd party vendors. When I was running Win95 Microsoft released an upgrade to fix some bugs. One of the dlls, mscntl32.dll, IIRC, was upgraded. Immediately I noticed that my Delorem Street Atlas 5.0 program wouldn't work. MS support said "get an SA upgrade". The SA website was livid with anger. It seems that the upgrade included support for Microsoft's version of Street Atlas, and Delorem felt the incompatibility was no accident, but a deliberate attempt to disable. It took them a while to reverse engineer the problem and put out an 'upgrade' dll. (BTW, would that reverse engineering be possible today under the DMCA? I don't think so!)

With the advent of gigantic size HDs, it is becoming possible for 3rd party vendors to include their own dlls, in their own installation directories, and not be concerned with the number or or size of MS OS or 3rd party dlls.

Linux has /lib for system libraries and /usr/lib for app libraries as the common places to store shared libraries (*.so.x.y.z), it is not uncommon for so's to be placed in app subdirs and links to the so's put in /usr/lib. When the system so's changed from libc2 to libc6, a couple of years ago, a lot of distros kept both simultaneously. SuSE's distro was well engineered and gave no problems, but RH had a boat load of problems with 6.0 and 6.1 and took it on the chin. Some anti-Linux folks used RH's problems as an avenue to attack Linux stability, although the kernel stability wasn't the issue.

Another way that Linux apps bypass potential *so.x.y.z compatibilities is to release static binaries of their apps (which contain the so's). These static apps are distro independent, and under todays HD sizes, no one is concerned about apps having 250KB dynamic and 4MB static releases. Six months ago I installed SuSE on my new Athlon with 60GB of HD. SuSE took 6GB (I installed all 2,000+ of the applications on the application CDs, just to poke around in them and play with them) and in the last 6 months I have been saving source trees, docs, graphics and other things with wild abandon... I currently have 43GB free. Having a big barn is nice!
JLK