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: <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/side_by_side_assemblies.asp>. 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. Brian
