[Flame Bait] - Linux as bloatware

Styma, Robert E (Robert) stymar at lucent.com
Tue Apr 11 17:24:39 UTC 2006


> > 
> > Much of DLL hell comes from a flaw in the original DLL design which
> > stems from a flaw in the original object oriented design.  
> Most DLL's
> > implement a OO Class.  The constructor is just an 
> initialization routine.
> > The space for the data structure under the class is allocated by the
> > caller, which is not in the DLL.  (You can get around this by having
> > the object always be a pointer and the constructor 
> allocates the storage
> > and initializes the pointer, but that is not how a lot of 
> classes work.)
> > If the space an object takes was 500 bytes at the time the 
> program was
> > linked and you later swap in a new dll that expects a 512 
> byte space,
> > it will initialize the 12 bytes past what the caller 
> allocated.  Sometimes
> > this will happen to work and sometimes not.
> 
> 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)
> 
> 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)
> 
My comment addressed why the multiple dll's become a problem.  You have a
bunch of copies of the same dll in different locations at different revisions.
One really big problem is that the newer dll's are not necessarily compatible
with programs originally linked against one of the older dll's.  These incompatibilities
often result in storage corruption and memory faults resulting from storage
corruption.  When you have to track this down, you often find that in the application,
when the "new" function gets called invoked which calls the constructor in the DLL,
the size of the storage allocated by new does not match the size expected by the
constructor in the DLL.  The constructor overruns the allocated space and corrupts
whatever comes next or corrupts "free" space which later gets used and trashes
the object.

The statements you made above are all true.  The result of the whole mess is that
the user of the dll may end up (depending upon the order things are loaded, (note
your mention of he dllcache)accessing a dll which is incompatible with the calls
being made.  You actually can get yourself into the same mess with shared objects,
but the UNIX approach helps you avoid getting the a mismatched copy.

Bob Styma




More information about the users mailing list