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