> > > > 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
