dynamic linking and load time linking .DLL

Question

Let's say I produce a new standard API. This API consists of a bunch of C header files, but no implementation. Specific vendors are responsible for implementing my interfaces so that application developers can interact with their products. The reason for having the interface to begin with is simple: the application developer should be able to interact with different products without trouble, since all of the products implement my interface.

Ok. Now onto the hard stuff. How would a vendor who is implementing my API implement the C code? My assumption for this question is that the vendor would simply include my header files in their project and create a .DLL that "exports" their implementation functions. More importantly, how would an application developer who wants to interact with my API (but wants it to work with any implementation from any vendor) write their code to take advantage of this?

I read this SO post about dynamic vs. load time linking. It seems like load time linking is useful if you know the name of the .dll you want to link to and you know the functions you want to call in that .dll. However, in my scenario, wouldn't the application developer have to dynamically link to a .dll that implements the functions from my API? How would this application developer know what the name of the .dll is that implements the functions from my API?

I hope my confusion makes sense. I come from a background where I learned how to program in C, but we did not do much with this stuff. From my recollection, we wrote a bunch of header files and C files, then we compiled it and linked it... and it resulted in an executable with all the code in that one executable. Please help clarify my misconceptions.

Answer 1

How would this application developer know what the name of the .dll is that implements the functions from my API?

The easiest solution is to pick a fixed name (e.g. MyInterface.dll) and require all implementers of your interface to name their DLL with that name. Then, the program can just try to load up a DLL with that name.

If you want more flexibility, then the application needs to be more complicated. For example, you could specify the DLL name in a configuration file. The application would then read in your configuration file, get the name of the DLL, load it with LoadLibrary(), and load up any needed functions with GetProcAddress().

If you want to be able to load multiple implementations of the same interface at the same time, then obviously they have to have separate filenames. This is often done by programs which load up DLL plugins. The usual way of doing this is to enumerate all of the DLLs in a given directory matching a given filename pattern, e.g. with FindFirstFile()/FindNextFile(). For each DLL found, again call LoadLibrary() and GetProcAddress() to access the functions within each.

Answer 2

You define the API and distribute it as one or more header files, as you say.

Your host app must support some sort of plug-ins file, which can be a plain text file, xml, json, whatever, that the user can add the name of the third party dll to.

The third parties include your header, implement and export the required functions.

Your app loads each third-party dll listed in the plug-ins file dynamically using LoadLibrary and does GetProcAddress calls to discover the entry points.

You might consider writing a reference plug-in dll that you distribute to the third parties with source code so that they can use that as a boilerplate for a hopefully working implementation.