RE: [Flame Bait] - Linux as bloatware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2006-04-11 at 08:26 -0700, Styma, Robert E (Robert) wrote:
> > 
> > On Tue, 2006-04-11 at 03:31, Anne Wilson wrote:
> > > > >
> > > > > And while we're thinking about code reuse, why does 
> > 'dll hell' occur?
> > > >
> > > > ----
> > > > save that one for a Windows list please.
> > > >
> > > It wasn't meant as a question, Craig.  Dll hell occurs, 
> > AIUI, precisely 
> > > because there is shared code, badly written and badly controlled.
> > 
> All, right, I resisted but will finally take the flame bait.
> 
> 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)

Gilboa


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux