Question

I have two C DLLs that I need to access in the same executable. I have header files and .LIB files for both libraries. Unfortunately a subset of the functions that I need to access have the exact same names. The best solution I have been able to come up with so far is to use LoadLibrary to load one of the DLLs and explicitly call its methods using GetProcAddress. Is there a way for me to implicitly load both libraries and somehow give the compiler a hint that in one case I want to call OpenApi in DLL A and in the other case I want to call OpenApi in DLL B?

I’m developing my executable in C++ using Visual Studio 2008 and the corresponding C runtime library (msvcr90.dll).

[Edit]

Commenter Ilya asks below what I don’t like about the GetProcAddress solution. I don’t like it for two reasons:

1. It makes the code more complex. One line of code to call a function is replaced with three lines of code, one to define the function signature, one to call GetProcAddress, and one to actually call the function.
2. It’s more prone to run-time errors. If I misspell the function name or mess up the signature I don’t see the error until run-time. Say I decide to integrate a new version of the dll and one of the method names has changed, it will compile just fine and won’t have a problem until the actual call to GetProcAddress, which could possibly even be missed in a test pass.

Answer 1

It used to be you could ‘rename’ an imported symbol using a linker .def file. You probably still can, but it’s been so long since .def files have been widely used, it’s difficult to locate documentation.

The current MSDN documentation lists the IMPORTS directive as a ‘reserved keyword’. I’m not sure if this means they removed the functionality, or if they just don’t want to support it anymore.

Here’s on page that describes the IMPORTS directive:

http://www.digitalmars.com/ctg/ctgDefFiles.html#imports

Other kludgy alternatives are:

1. create wrapper functions for the conflicting APIs. Those functions can do the LoadLibrary()/GetProcAddress() dance. All other non-conflicting functions can be implicitly linked as normal. Actually, this solution is probably the least kludgy of the 3 in this answer.

2. create 2 wrapper DLLs such that each links only to one or the other library with the conflicting names. Use differing names in the wrapper DLLs that simply thunk over to the real librarys. Note the wrapper libraries do not need to wrap all the API’s – they just need to wrap the conflicting ones.