none
How to load DLL's when a program starts

    Question

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

    Sunday, January 25, 2009 2:21 AM

All replies

  • The main DLL needs to link to the second DLL.  Add the .lib file that comes with the second DLL to the link settings "Additional Dependencies" of the first DLL.  (And take it out of the exe link settings if the exe does not call it.)

     

    Sunday, January 25, 2009 4:10 AM
  • I don't get it.  If the 1st DLL doesn't contain explicit calls to the 2nd DLL and doesn't use LoadLibrary(), how does it make the calls?
    Hans Passant.
    Sunday, January 25, 2009 1:35 PM
    Moderator
  • 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.

     

    Sunday, January 25, 2009 10:00 PM
  • 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.

     

    Sunday, January 25, 2009 10:06 PM
  • Having to call LoadLibrary() looks inevitable to me.  Nothing wrong with it.  Consider using COM as a standardized way to load DLLs based on a request to create a class instance.
    Hans Passant.
    Sunday, January 25, 2009 11:11 PM
    Moderator
  • 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.

     

    Tuesday, January 27, 2009 4:00 AM
  • 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.

    Brian

     

    Tuesday, January 27, 2009 4:50 AM
  • Given that this is supposed to be a cross platform application, that will run on other systems besides Windows, how practical would it be to redesign this as a COM server?
    Wednesday, January 28, 2009 3:24 AM