I have the following scenario:
An executable application can be customized by dlls and multiple of these customizations can be started in parallel. For common tasks these dlls can use dynamically linked open source libraries like OpenSSL (libssl.lib, libcrypto.lib which are retrieving the modules libssl-1_1-x64.dll and libcrypto-1_1-x64.dll).
In order to retrieve the desired library modules, they are linked with the /delayload option. However if the libraries have the same name (e.g. since they are different versions of the same library) the first LoadLibrary
will do the binding for all libraries.
In a more abstract description, the following scenario will retrieve lib1\lib.dll and lib2\lib.dll, but it will always call the functionality from lib1\lib.dll, since this module was retrieved first.
prog.exe - loads dll1.dll - linked /delayload lib1\lib.lib - requires lib1\lib.dll - loads dll2.dll - linked /delayload lib2\lib.lib - required lib2\lib.dll
Is there any way to influence the binding for the dll2.dll instead of working with GetProcAddress
for the retrieved dll?
Is there any way to influence the binding for the dll2.dll instead of working with GetProcAddress for the retrieved dll?
Yes, there is. You can use a separate Activation Context for each load, either manually by using the Activation Context API directly, or by using manifests.
A customer had a program that loaded two DLLs, let’s call them
A.DLL
andB.DLL
. Both of those DLLs use a common helper DLL calledC.DLL
. The catch is that the two DLLs want to use different incompatible versions ofC.DLL
. The two DLLsA.DLL
andB.DLL
reside in separate folders, and each folder has a corresponding copy ofC.DLL
....
The customer was hoping there would be some way to get the two DLLs
A.DLL
andB.DLL
to use their respective versions ofC.DLL
. They suspect that some magic with activation contexts and manifests might do the trick, but they didn’t have the expertise to figure out exactly what....