coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

On 15 April 2010 05:25, Gordon Schumacher <whiplash@xxxxxxxxx> wrote:
> Now let's pretend that a user has installed my WhizBangShellExt, but
> unbeknownst to me he's previously loaded CrustyExplorer, another shell
> extension.  It also depends on libFoo.dll, but it's a much older
> application and is no longer supported, so it's installed libFoo 2.718 -
> and it's even a different major revision, and therefore has a different API.
>
> My understanding is that for a given process, there can only be one
> "libFoo.dll" loaded at a time; if Explorer loads CrustyExplorer.dll
> first, it'll get libFoo 2.718, and if it loads WhizBangShellExt.dll
> first, it'll get libFoo 3.141 - which needless to say is rather less
> than ideal!

I do believe this is a problem, but I too am not 100% sure how it
plays out in reality.  What it all boils down to is what symbols the
DLLs export, and how the dynamic linker on Windows performs symbol
resolution.  I know that on Linux, if a binary needs to call function
"foo", and there is something already loaded which exports symbol
"foo", that will be used - which is precisely why things like
LD_PRELOAD work for intercepting library calls.  My gut feeling would
be that the Windows linker isn't entirely dissimilar, since there are
only a handful of sensible ways to solve the problem.

If CrustyExplorer is open-source, the correct solution is to either
port it to the newer libFoo API, or - worst solution, least effort -
statically link it against the old libFoo, ensuring that the resulting
DLL doesn't export any libFoo symbols.  If it's closed-source you may
be out of luck, unless tools exist for somehow re-linking existing
binaries, allowing static linking to be performed after the fact.

Note that if libFoo is a well-designed library, it may have some
initialisation/version-checking functions that WhizBangShellExt can
use to detect the problem at run-time.

Corrections (and explanations of the symbol resolution strategy on
Windows) much appreciated. :)

Regards,
Phil