Skip to main content

dll's

  • October 1, 2015
  • 1 reply
  • 0 views
A
  • Anonymous

We have a bit of a problem with 2 different dll's using a common dll at different versions, and neither work properly with each other's common X.dll. they need to have access to their own version of the common X.dll...  

Here's the scenario:

  1. first.dll and X.dll (version 1) are in the folder C:\\first\\
  2. second.dll and X.dll (version 2) are in the folder C:\\second\\

wrun32.exe

Program.acu

  • calls first.dll
    • which calls X.dll (version 1)
  • later calls second.dll
    • which calls X.dll (version 2) and blows up with an error because X.dll is already loaded into memory by first.dll so it appears to be trying to call the methods in the wrong X.dll.

If we don't have access to modify either one of these dll's is there anything we can do to force both first.dll and second.dll to load and use their own proper X.dll?

Thanks

    1 reply

    D

    We have a bit of a problem with 2 different dll's using a common dll at different versions, and neither work properly with each other's common X.dll. they need to have access to their own version of the common X.dll...  

    Here's the scenario:

    1. first.dll and X.dll (version 1) are in the folder C:\\first\\
    2. second.dll and X.dll (version 2) are in the folder C:\\second\\

    wrun32.exe

    Program.acu

    • calls first.dll
      • which calls X.dll (version 1)
    • later calls second.dll
      • which calls X.dll (version 2) and blows up with an error because X.dll is already loaded into memory by first.dll so it appears to be trying to call the methods in the wrong X.dll.

    If we don't have access to modify either one of these dll's is there anything we can do to force both first.dll and second.dll to load and use their own proper X.dll?

    Thanks

    Please note that this is a Windows issue - it's not specific to COBOL or Micro Focus products.

    There are three ways to coax Windows into loading two versions of a DLL (or, more generally, two different DLLs that have the same name) into a single process. One is fibers, or for managed (.NET) processes, AppDomains; I'm not going to discuss that further because for native code it requires fairly extensive understanding of some obscure Windows features.

    The second method is to load at least one of the DLLs explicitly in the program using the Windows LoadLibrary API, and then resolve the necessary entry points explicitly using the handle returned by LoadLibrary and the GetProcAddress API. This is by far the safer approach, since the program can ensure that it's calling the entry points it expects to call. However, it requires changes to program code.

    The third method is to override the default behavior of Windows when implicitly loading DLLs by using a manifest file or resource. There's a description of that technique here:

    http://blogs.msdn.com/b/dsvc/archive/2013/03/21/how-to-load-2-dlls-with-same-name-but-different-versions.aspx

    Beware. This is potentially difficult to get correct, fragile (particularly if DLLs are not versioned correctly or if their paths change), and dangerous (because failures can result in undefined behavior). I don't recommend it. It may, however, be the only way to get two different versions of the DLL in a single process without changing application code.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement