c++dlldynamic-linkingdelay-load

DelayLoad different libraries with identical names


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?


Solution

  • 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.

    See How can I specify that my DLL should resolve a DLL dependency from the same directory that the DLL is in?:

    A customer had a program that loaded two DLLs, let’s call them A.DLL and B.DLL. Both of those DLLs use a common helper DLL called C.DLL. The catch is that the two DLLs want to use different incompatible versions of C.DLL. The two DLLs A.DLL and B.DLL reside in separate folders, and each folder has a corresponding copy of C.DLL.

    ...

    The customer was hoping there would be some way to get the two DLLs A.DLL and B.DLL to use their respective versions of C.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.

    ...