I have a project that contains a program which links to a DLL. This DLL might call functions from another DLL conditioned on runtime information. This means there are no explict calls to that second DLL in the program, and thus the DLL does not get loaded automatically when the program starts.
This is a problem as since the DLL is never loaded, it prevents static entries in that DLL from performing registration operations that will allow the first DLL to know it can use items in the second DLL.
Loading the second DLL from the program via a call like LoadLibrary would solves the problem. However, it would be nice to avoid this.
What else can be done to allow the second DLL to load automatically when the program starts?
I can't link the libraries like that as the first DLL provides a base class that the second DLL uses to derived additional classes from. Trying to link the second DLL to the first DLL causes errors.
I tried linking only the second DLL to the application. The worked, in that everything built properly. However the second DLL still did not load when the program was run.
Hey Hans, here is what is going on:
The first DLL contains a class library implementation. If the second DLL were to load successfully, it would register certain classes it exports with that class library. When the application processes a configuration file, the file may require created object instances that are provided by the second DLL. The program will defer to the class library in the first DLL to create the instances, and the first DLL will defer to the second DLL when the class library performs the lookup to determine where the function to create the instance is located.T
However, the second DLL is never loading so it doesn't register with the first DLL so the class library can know how to created objects from classes the second DLL exports.
This is disappointing. The class factory is a C++ template class, and I've tested the program and libraries on other platforms besides Windows; it works fine with out the needed to explicitly load any libraries.
Having to use LoadLibrary on Windows means I'll have to perform similar operations on other platforms if I want to handle things in a consistent way.
It's more than disappointing. It's just a very bad idea. Exposing C++ classes through a DLL leads to all sorts of grief. It never ceases to amaze me all the problems that programmers encounter when they try do to this.
If this was properly implemented as a COM DLL, this problem instantly vanishes. Firstly, class factories are burnished right into COM itself, so one hardly needs to think about them (they work so smoothly). Secondly, COM completely disallows (or make it very difficult) to expose a C++ class. Everything has to be accessed through a well-defined interface.
Even if you don't go to the extreme of redesigning this as a COM server, I certainly think you have to go back to the drawing board and think through what crisp interfaces should be exposed in your DLL's. And by "crisp", I mean function calls with simple POD data types as parameters.