Jump to content
  • Advertisement
Sign in to follow this  
beebs1

GetProcAddress

This topic is 4036 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hiya, I'm trying to use the C++ GetProcAddress() function in an application, to call functions from a DLL. The problem I'm having is that the function names are mangled when I build the DLL. I can use the Dependancy Walker tool to find the mangled function names, but it would be much easier if this didn't happen in the first place. I've tried wrapping the function declarations in extern "C" {, but they still come out modified - I assume this is because I'm passing pointers to classes as parameters. Can anyone suggest how I can stop this mangling business? Many thanks for any help [smile]

Share this post


Link to post
Share on other sites
Advertisement
:D

Realistically, though. Name-mangling is unavoidable; symbol names must be managled in order to disambiguate them in various situations where the context they existed in in code is longer available or relevant.

Be glad you can use C, which has a standardized ABI. C++ does not. Anyway, it's been a while but I believe the documentation for GetProcAddress on MSDN explains some ways to work around (via ordinals) or alleviate the mangling issues, depending on how exactly your functions are exposed.

Share this post


Link to post
Share on other sites
You can define the exported symbol for functions in a ".def" linker file:

EXPORTS
<exported name 1> = <mangled name 1> PRIVATE
<exported name 2> = <mangled name 2> PRIVATE
<exported name n> = <mangled name n> PRIVATE

and add the name of the file to the module definition parameter of the linker. The 'PRIVATE' part is optional.

Skizz

Share this post


Link to post
Share on other sites
Also, if you're using the MSVC 2005 compiler you can get the managled name of the function like this:

return_type function_name (arguments)
{
#pragma message (__FUNCTION__ " is mangled to " __FUNCDNAME__)
code
}

which will display the mangled (decorated) name in the output window when the source is compiled. Using a makefile you could strip this information from the output and create a ".def" automatically before linking.

Skizz

Share this post


Link to post
Share on other sites
When I'm linking to dll's, I use a variation of the following.

First, create a header file that contains dll exporting support. This would have to be included into any dll that wishes to expose one or more functions.


// Header.h file containing dll exporting support

#define EXPORT extern "C" __declspec (dllexport) // Defines the exporting attribute (non ANSI however!)

template <class CType>
inline CType DllAddress (HMODULE dll, PCSTR EXPORTED_NAME) // Handy template function makes linking a little easier
{
assert (dll && EXPORTED_NAME) // Test arguments before continuing
return reinterpret_cast<CType> (GetProcAddress (dll, EXPORTED_NAME)); // GetProcAddress invoked internally
}



Next, create the header of your dll, in which the functions it wishes to export are declared via the EXPORT macro


// Dll.h file is header of your dll

#include "Header.h"

EXPORT int SomeDllFunction (int); // Exported function declaration declared with EXPORT macro
typedef int (*SOME_DLL_FUNCTION) (int); // Typedef of a pointer to "SomeDllFunction" function (saves using an ugly cast)




Build the dll as usual, then to test it, create the following .cpp file.


// Client.cpp is implementation file that uses the dll

#include "Dll.h"

int main ()
{
HMODULE Dll = LoadLibrary ("Dll.dll"); // Loads the dll (.dll extension not necessary, but makes code a bit clearer)
if (!Dll) return EXIT_FAILURE; // Test dll loaded

SOME_DLL_FUNCTION SomeDllFunction = DllAddress<SOME_DLL_FUNCTION> (Dll, "SomeDllFunction"); // Link to exported function
if (!SomeDllFunction) return EXIT_FAILURE; // Test we got it

int result = SomeDllFunction (5); // Now use it!
FreeLibrary (Dll); // Always good to tidy up after (although you could automate this in a smart wrapper)
return EXIT_SUCCESS;
}



I've used code like this for years, and it hasn't done me any harm. You can even use it to link to types defined in the dll with the EXPORT attribute, but I wouldn't recommend it unless you know what you're doing.

With regards to classes, the best way to link to those is to export a "factory" function that will create the class for you, however, you will need to create an "interface" to the class, which would be declared as an abstract data type from which the class would inherit from...

Yikes! I better stop there. We're heading into COM territory.

Anyway, stick to exporting functions for now. The code I've shown you should enable you to link to any exported function in your dlls.

Hope this helps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!