Linking DLLs together
Author
Hi, i have a number of DLL's linked in runtime (LoadLibrary) to my EXE, one of them contains functions and data that every other DLL must be able to call / access. What is an easy way to make functions and data from that one instance of the DLL available to the other DLLs?
The only things i could think of are just giving all the (function)pointers to the DLLs, or maybe putting these pointers in an object which is known to all of them.
Are there any official, better or easier ways to do this? I'm working with MSVC++ 2005.
A little overhead is not really a problem, as long as it's fast to code.
Thanks
Just because your program late-binds to the DLLs, it doesn't go to say that they can't early-bind to one-another. If you build the two DLLs to dynamically link against each other, it will be impossible to call Loadlibrary on one without the other getting loaded. That way you don't have to bother yourself with manual declaration and resolution of function signatures.
Admiral
Admiral
Author
Thanks for the reply. The problem is that the DLL which shares the functions and data is not always the same one. It's like this:
Our game has different modes (deathmatch, capture the flag, etc.), to make development easier they're put into separate DLL's with the same entries. When a game is started one of these DLL's is loaded and the function pointers etc. in the exe and the other libraries will be updated to use that DLL's code and data.
What i wanted to know is if there's any way to automatically bind these or if it has to be done 'manually' every time a different game mode is loaded.
Also, the other libraries (for graphics, sound, networking, etc.) are already loaded because the executable needs them.
Our game has different modes (deathmatch, capture the flag, etc.), to make development easier they're put into separate DLL's with the same entries. When a game is started one of these DLL's is loaded and the function pointers etc. in the exe and the other libraries will be updated to use that DLL's code and data.
What i wanted to know is if there's any way to automatically bind these or if it has to be done 'manually' every time a different game mode is loaded.
Also, the other libraries (for graphics, sound, networking, etc.) are already loaded because the executable needs them.
I'm not certain this is the right way to go (not being a code guru), but it should work...
Provide an interface class within your program code that binds its methods and attributes at run time to functions and data objects provided in the DLL. You could presumably permit rebinding as well when you load a different DLL (because they change game mode without restarting the game). Then, other DLLs call only the appropriate methods of the interface class to gain access to the other DLLs data objects and functions.
Cheers,
Timkin
Provide an interface class within your program code that binds its methods and attributes at run time to functions and data objects provided in the DLL. You could presumably permit rebinding as well when you load a different DLL (because they change game mode without restarting the game). Then, other DLLs call only the appropriate methods of the interface class to gain access to the other DLLs data objects and functions.
Cheers,
Timkin
Author
That's what i meant by 'or maybe putting these pointers in an object which is known to all of them.', i think. But it's good to have a second opinion, thanks.
Exposing an API is a common way to do so. For example, all games based on the Quake-series engine do this, if you want a third opinion. And I bet there are others as well.
In fact, the following example shows a practical solution:
In fact, the following example shows a practical solution:
Shared Libraryinterface SharedAPI{public: Entity * SpawnEntity(); PlayTrack( int );};Host ApplicationRun(){ SharedLibrary sl; Library l1, l2; SharedAPI * api; // load the shared lib and get a pointer to its exposed API // (sl implements the SharedAPI interface) api = sl.GetAPI(); // allow other libraries to use that API too l1.SharedAPI = api; l2.SharedAPI = api;}
Author
Thanks, that's good to hear.
I got another question about DLL's though, pretty basic but can't really find a definitive answer anywhere:
Let's say i have a few DLL's: A, B, C, D and a .exe E.
What happens by default (for MSVC++ 2005) when A, B, C and E are all using data and functions from the DLL D. Are there multiple instances of D loaded or will there just be one for the entire process? So will they share the DLL and it's data?
I got another question about DLL's though, pretty basic but can't really find a definitive answer anywhere:
Let's say i have a few DLL's: A, B, C, D and a .exe E.
What happens by default (for MSVC++ 2005) when A, B, C and E are all using data and functions from the DLL D. Are there multiple instances of D loaded or will there just be one for the entire process? So will they share the DLL and it's data?
Quote:Original post by Tree Penguin
Thanks, that's good to hear.
I got another question about DLL's though, pretty basic but can't really find a definitive answer anywhere:
Let's say i have a few DLL's: A, B, C, D and a .exe E.
What happens by default (for MSVC++ 2005) when A, B, C and E are all using data and functions from the DLL D. Are there multiple instances of D loaded or will there just be one for the entire process? So will they share the DLL and it's data?
Not 100% certain but:
there should only be one version of the dll loaded, shared by all others.
HOWEVER the data will not be shared unless you specifically declare the data as shared.
The others will confirm my answer.
Yours Truly
K
Bare in mind that you don't HAVE to load the DLL multiple times! The simple answer is to load the shared DLL once in the executable, and pass its API along to other modules. Those modules don't need to know where it came from, and the API can consequently shield its data (and implementation).
The shared data segment is most often used when injecting a module into multiple processes (for example: a system-wide hook). You generally don't need it for single-process applications.
The shared data segment is most often used when injecting a module into multiple processes (for example: a system-wide hook). You generally don't need it for single-process applications.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
