Hi,
I've been doing loads of work at the moment on my chosen game engine. It uses's interfaces stored in static libraries to load dynamically linked libraries at run time. The reason is to make alot of the engine modular, especially the stuff that deals direct with hardware or a particular OS, or API or whatever. It's very well conceived. It means that if I had to, or wanted to, make changes to the API stuff or even change a model a game uses or use different pixel or vertex shaders then all I have to do is just re-compile the DLL and it's fine. No need to recompile the whole application. It also means once I really understand the entire engine framework I can use it over and over again without ever needing to mess with it, no matter how old I am or what platform it is being used on. I can just develop stuff graphically to keep up to date through the DLL's.
Nice
But.... I know of at present two ways to export a function from a DLL file. Using the _declspec (dllexport) which I have up to now seen used with classes but I also believe works with functions. I'm not using Visual though I'm using Code::Blocks. Important for me as I eventually plan to get stuff to run on Linux too. I want multiplayer servers to be Linux based after having seen how good their performance was at managing the network at my old engineering firm. Not to knock Microsoft though, I like alot of their stuff too. I find windows most helpful with an awful lot of things when programming.
Anyway, the author's original choice for exporting functions from his DLL's was to use the other way not mentioned above. What he does here is he uses a .DEF file. This lists the functions required to be exported from the DLL to prevent errors. So it's included with the project when compiling. The functions return a pointer to an object of type 'interface' which is actually a real object in the DLL inherited from an abstract virtual class definition - 'interface'.
I believe you can also link to a special DLL dedicated static library to run too, kind of defeats the point of DLL's though
All fine and good but when I compile I find that I have the DLL file, the new DEF file and the static library loader (the one specific for the DLL). I'd expect this. WHat I didn't expect was to find the list of items in the .DEF file to be about a few hundred functions and data types long. The two functions which had to be exported with uncorrupted names were there, but then there were a tonne of C++ mangled function and data variable names after that. The DLL is only supposed to export those two functions.
I also found that I could compile the DLL AND run the demo.exe even with the original .DEF file completely absent and deleted. Now this should not be possible!
So it seems to suggest strongly that my IDE is taking it upon itself to export just about every damn thing in the DLL when compiling it, to the point where it doesn't even need the .DEF file. I don't like this at all. All those other functions have no place being there, they're supposed to be encapsulated in the DLL.
So:
1)Does anybody understand what I'm talking about? Maybe this isn't common knowledge everywhere.
2)Can I change the settings somewhere on my IDE to request that it consult the .DEF file and only export the functions requested.
3)Is there an even better way to do this - which is even more true to portable code standards and universally recognised.
I've had issues lately with a _declspec keyword causing an application to blow up when trying to load a DLL at run time. When I removed the _declspec keyword from inside the DLL and recompiled it went fine. I'm going to be having alot to do with DLL's in the future so I need to know as much as I can about loading them safely, and reliably and not in a way which is dependent on anything other than established compiler and IDE independent C++ standards.
Thanks so much for any help offered
Learning about DLL's
Originally Posted by Adak
