Brian Dessent brian@dessent.net
Thu Jun 30 22:54:00 GMT 2005

Bas van Gompel wrote:

> I Don't see how this could work. ``Statically'' linked, the wrapper's
> ``exports''-table would be consulted, would it not?
> I can imagine building a custom wrapper-dll for each wrappee, using an
> autoload-like method, but don't intend to investigate further, for now.

Presumably that's what Igor meant, i.e. making a stub DLL with entry
points for every function in the API, and some kind of means of
determining which version of the DLL to use, and a call to LoadLibrary()
that would pick the correct one and pass though all calls.

I don't see how this would be possible in the general sense though.  The
wrapper DLL would have to know all the exports at compile time.

If the application could hook into calls to GetProcAddress(), then it
could essentially proxy a DLL.  The wrapper DLL could choose from one or
more alternative target DLLs, call LoadLibrary() on that DLL, and then
pass-through the GetProcAddress calls.  But this would only work for
run-time dynamic libraries, I see no chance of this being able to proxy
a DLL that a binary was linked against.  I'm sure that's possible too
but it would take some mondo knowledge of win32 API internals.

On a related note... there is a Microsoft Way(tm) of doing this, with
side-by-side assemblies and manifests:
In theory you could attach a manifest to the .exe that would tell the
loader exactly which DLLs to use, instead of having to do it though PATH
manipulation.  And a manifest need not be internal to the .exe, it can
be a seperate file, so I guess there is the potential for using this in
the scenario mentioned above.  But it's an XP-and-later feature anyway,
so not of much use to the project in general.


More information about the Cygwin-apps mailing list