dllimport vs dllexport
-
I have a 3rd party library that shipped with only the DLL itelf and a header file with function prototypes and constants. All the procedures inside the DLL are declared using the dllimport keyword. Does this mean that I can't dynamically link into this DLL at runtime because none of the functions were exported? I've already written an app that links to this DLL statically, and that works fine, but I'd rather use dynamic linking. Everything I've read so far points me to the fact that since there isn't a .DEF file, and the functions aren't declared using dllexport, I can't dynamically link to this library. Am I right? Thanks guys... -Mike Zinni email: mzinni@rimail.com AIM: zin9999
-
I have a 3rd party library that shipped with only the DLL itelf and a header file with function prototypes and constants. All the procedures inside the DLL are declared using the dllimport keyword. Does this mean that I can't dynamically link into this DLL at runtime because none of the functions were exported? I've already written an app that links to this DLL statically, and that works fine, but I'd rather use dynamic linking. Everything I've read so far points me to the fact that since there isn't a .DEF file, and the functions aren't declared using dllexport, I can't dynamically link to this library. Am I right? Thanks guys... -Mike Zinni email: mzinni@rimail.com AIM: zin9999
Do you have a lib file? You should be able to link with it. Best regards, Alexandru Savescu
-
Do you have a lib file? You should be able to link with it. Best regards, Alexandru Savescu
Yes. I have the .LIB file and the directory is included in my Tools->Options->Directories->Library files settings. I wrote the following code to link to the DLL.
typedef int (CALLBACK* LPOMNICREATEFUNC)(void);
BOOL COmniDoc::LoadOmniLibrary()
{
m_bOmniLoaded = FALSE;m\_hOmniLibrary = LoadLibrary("SD2.dll"); if(m\_hOmniLibrary) { m\_bOmniLoaded = TRUE; m\_lpfnSD\_Create = (LPOMNICREATEFUNC)GetProcAddress(m\_hOmniLibrary, "SD\_Create"); } return m\_bOmniLoaded;}
m_lpfnSD_Create is of type LPOMNICREATEFUNC. LoadLibrary returns a valid handle, but the m_hlpfnSD_Create variable is set to NULL after the call to GetProcAddress... -Mike Zinni email: mzinni@rimail.com AIM: zin9999
-
I have a 3rd party library that shipped with only the DLL itelf and a header file with function prototypes and constants. All the procedures inside the DLL are declared using the dllimport keyword. Does this mean that I can't dynamically link into this DLL at runtime because none of the functions were exported? I've already written an app that links to this DLL statically, and that works fine, but I'd rather use dynamic linking. Everything I've read so far points me to the fact that since there isn't a .DEF file, and the functions aren't declared using dllexport, I can't dynamically link to this library. Am I right? Thanks guys... -Mike Zinni email: mzinni@rimail.com AIM: zin9999
OK. Made some progress. I used the Depends tool that comes w/ VC++ and found out that the names of the exported functions are all messed up. That "SD_Create" procedure is actually exported as "_SD_Create@0". Now I'm at least returning a valid function pointer. Is there any particular reason that the name is changed like that? And secondly, if I didn't use the Depends tool, how in the HELL was I ever supposed to come up with that? -Mike Zinni email: mzinni@rimail.com AIM: zin9999
-
OK. Made some progress. I used the Depends tool that comes w/ VC++ and found out that the names of the exported functions are all messed up. That "SD_Create" procedure is actually exported as "_SD_Create@0". Now I'm at least returning a valid function pointer. Is there any particular reason that the name is changed like that? And secondly, if I didn't use the Depends tool, how in the HELL was I ever supposed to come up with that? -Mike Zinni email: mzinni@rimail.com AIM: zin9999
mikez99 wrote: found out that the names of the exported functions are all messed up. That "SD_Create" procedure is actually exported as "_SD_Create@0". That's not messed up, that's the usual name mangling taking place for PASCAL (aka __stdcall) calling convention functions.
-
mikez99 wrote: found out that the names of the exported functions are all messed up. That "SD_Create" procedure is actually exported as "_SD_Create@0". That's not messed up, that's the usual name mangling taking place for PASCAL (aka __stdcall) calling convention functions.
No, thats not name mangling for C-style __stdcall calling convention, but is the name mangling of the C++ compiler (so called "decorated names"). The reason for this is that C++ supports overloading, but at link time every function identifier needs to be unique. So the C+++ compiler codes the numer and types of the functions arguments into the name and links against this name. The @0 in you case indicates a function without arguments. Note that decorated names are always used if the functions are exported with __declspec(dllexport). If possible you should link against the .lib file and so implictly load your DLL. You may also use the VC6 and above delay load feature. -- Daniel Lohmann http://www.losoft.de