[Flame Bait] - Linux as bloatware

[Les Mikesell]

On Tue, 2006-04-11 at 11:29, Gilboa Davara wrote:

> Umm...?
> IMHO DLL hell has nothing to do with OO design and/or classes.
> Problem is very simple:
> Microsoft never considered the option that a machine will have 24 copies
> of msvcrt.dll, 16 copies of mfs40/42/etc.dll, 5 copies of msvb70.dll and
> 999 copies of comctl32.dll with 50% sitting in different positions in
> the search path (system32, VS6/7's bin, etc) and there-fore never did
> anything to prevent it. (Read: RPM/YUM/APT like system to maintain
> libraries)

Note that YUM/APT, etc. only work within a single repository or
ones that are extremely careful to not replace any file that
exists in a compatible repository.  This is a work-around that
sort-of works with Linux distributions that include everything.
It can't work in the general case of getting applications from
many sources.

> The DLL hell problem begins and ends with the following problems:
> A. Windows allows local DLL execution by default. (No need for export
> LD_LIBRARY_PATH)
> B. Windows does not prevent applications from storing *system* DLLs in
> their local directory.
> C. -Even worse-, Windows does not prevent an application from
> upgrading/replacing/deleting the OS (/system32) copy of the said system
> DLL.
> D. Oh, when software N uninstalls, Windows does not stop it from
> deleting OS DLLs. (Beside the stupid _dllcache that never really works)

No, the dll cache is the biggest part of the problem on windows.
Once one version of a dll has been loaded, other programs that
expect their local replacement (which usually existed to fix a
bug in the system version) get whatever is already loaded instead.

-- 
  Les Mikesell
   lesmikesell at gmail.com