I am writing an MFC application that uses two DLLs (both custom built by me). So we have APP, GLOBAL_DLL & GAME_DLL.
APP is the MFC application that will use both DLLs.
GLOBAL_DLL is an implicitly linked extension DLL that contains all of the global data for any game dlls and the app itself. This includes networking, game objects/lists, etc. This dll is used by APP & GAME_DLL.
GAME_DLL is an explicitly linked extension DLL that contains all of the game specific code and is loaded at runtime based on the game the user selects. This DLL uses GLOBAL_DLL as a reference to all of the networking, game objects, etc. that APP uses so that GAME_DLL is compatible with APP.
So then, GLOBAL_DLL is implicitly linked to GAME_DLL & APP and GAME_DLL is explicity linked to APP. This compiles perfectly as 3 seperate projects all in one workspace. However, when I try and Debug (F5) the APP (using MSVC6.0) I receive the error shown as dialog A followed immediately by the error shown as dialog B and then the APP closes out...
(for some reason, my image is not being displayed above this paragraph as is coded in the html, the image is @ http://www.angelfire.com/crazy/schrader/index.html
The APP is "MUGGER.exe". CNetMsg is a class within GLOBAL_DLL, however, I thought the entry point was DllMain(...) I have included a DllMain(...) within GLOBAL_DLL so I don't see why it is looking for the entry point at my CNetMsg class.
I have looked all over for answers to this and have found nothing, if someone has already asked the same question would you simply point me in the right direction
Dll error at debug
RichLeyshon
Entry point in that case does not mean the function where the OS initially passes control to your DLL but rather an exported entry point. Basically, some module has an import of a function with the mangled name " 0CNetMsg@@QAE@I@Z".In C the function/variable name was pretty much good enough for identifying the right entity during linking. C++ requires much more detail, which is compressed into this arcane format. Fortunately, VC ships with the undname command line tool (Name Undecorator).
Undecoration of :- " 0CNetMsg@@QAE@I@Z"
is :- "public: __thiscall CNetMsg::CNetMsg(unsigned int)"
That tells you mugger.exe has an import descriptor from global_dll.dll for that function, but global_dll.dll (at least the one that is loaded) does not provide it. And that means the import library and the DLL selected at runtime are out of sync.
dumpbin /EXPORTS (on both the import library .lib and the DLL) is your friend for finding the differences between DLL & .lib.
Note that, all member functions of __declspec(dll{ex|im}port) class are {ex|im}ported even if there is an inline definition in the header)
-hg
timn_1