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
