On Tue, 2006-04-11 at 10:24 -0700, Styma, Robert E (Robert) wrote: > 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 The same problem that plagues OO functions may (and will) plague 'normal' non-OO C APIs. Adding/changing a function's parameter size or packing (even when using __stdcall) is just as destructive as changing the class structure. In general, once someone changes the DLL's interface, no matter how minute the change is supposed to be, you're in for compatibility problem. In most cases OSS is free of these problems. Most applications within a certain release are complied against each other and no major ABI changes are allowed within the life span of the said release. Unless you -really- FUBAR'ed your yum/apt repository, you should be safe. Gilboa
