GetProcAddress issues
v4vijayakumar
to get the adderss of a specific function, "fnTestFun". It returned
NULL, and "dependancy walker" (%microsoft-visual-studio-home%\Common
\Tools\depends.exe) showed that the currupted function name (?
fnTestFun@@YAHPAD000000000000PAVTestClass2@@@Z). Tried to use this, "?
fnTestFun@@YAHPAD000000000000PAVTestClass2@@@Z" as function name it
worked fine.
what could be possible causes for this issue? Thanks in advance.
MrAsm
<vijayakuma...@gmail.com> wrote:
The function name is *not* corrupted, it's just mangled basing on
Microsoft C++ compiler rules.
Name mangling occurrs in C++, because C++ allows things like function
overloading, so there must be a way to distinguish between e.g.
void MyFunction( int );
void MyFunction( char *, void *, long );
etc.
If you want to avoid this name mangling, you can use the .DEF files
when building your DLL. A .DEF file is just a text file, with
information for DLL function exports.
Something like this:
LIBRARY MyTestLibrary
EXPORTS
fnTestFun @1
AnotherFunction @2
HelloWorld @3
MrAsm
David Ching
"MrAsm" <mr...@usa.com> wrote in message
news:mb2iv29d1obafqb9o...@4ax.com...
> Name mangling occurrs in C++, because C++ allows things like function
> overloading, so there must be a way to distinguish between e.g.
>
> void MyFunction( int );
> void MyFunction( char *, void *, long );
>
> etc.
>
> If you want to avoid this name mangling, you can use the .DEF files
> when building your DLL. A .DEF file is just a text file, with
> information for DLL function exports.
A simpler and more automatic approach to .DEF files is to declare the
function as:
extern "C"
{
void MyFunction( int );
void MyFunction( char *, void *, long );
}
The "extern C" removes the name mangling.
You can also use __declspec(dllexport) to export the function so that you
can link with the import library and not have to use
LoadLibrary()/GetProcAddress().
-- David
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>A simpler and more automatic approach to .DEF files is to declare the
>function as:
>
>extern "C"
>{
> void MyFunction( int );
> void MyFunction( char *, void *, long );
>}
>
>The "extern C" removes the name mangling.
>
David: I'm not sure about this... at least there is a leading
underscore, and maybe also @<num bytes> at the end of function name
(if you use __stdcall calling convention):
http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx
MrAsm
David Ching
> David: I'm not sure about this... at least there is a leading
> underscore, and maybe also @<num bytes> at the end of function name
> (if you use __stdcall calling convention):
I do this all the time, declare functions extern "C" __declspec(dllexport),
and this allows the module calling these functions to just #includes the .h
file and link with the import lib.
-- David
MrAsm
OK, but the name does get decorated.
David Ching
> OK, but the name does get decorated.
The leading "_" is inserted into the function definition, but that's great
because it also gets inserted at the call too, so they match up! :-)
-- David
MrAsm
Sure :)
But the match is OK also for the complex C++ decoration from the OP.
I was just answering about how to get no decoration at all.
David Ching
> But the match is OK also for the complex C++ decoration from the OP.
> I was just answering about how to get no decoration at all.
To sum up how to export functions from a DLL so that they are easily
callable from another module:
In the .h file:
#ifdef BUILDING_DLL
#define MYDLLFUNC __declspec (dllexport)
#else
#define MYDLLFUNC __declspec (dllimport)
#endif
extern "C"
{
int MYDLLFUNC func1();
int MYDLLFUNC func2();
};
The DLL project has BUILDING_DLL defined so that the functions are exported,
and the project that calls these functions does not have it defined so that
the functions are imported.
The DLL exports functions called "func1" and "func2". The names don't have
a leading "_".
Cheers,
David
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>To sum up how to export functions from a DLL so that they are easily
>callable from another module:
>
>In the .h file:
>
>#ifdef BUILDING_DLL
> #define MYDLLFUNC __declspec (dllexport)
>#else
> #define MYDLLFUNC __declspec (dllimport)
>#endif
>
>extern "C"
>{
> int MYDLLFUNC func1();
> int MYDLLFUNC func2();
>};
>
>
>The DLL project has BUILDING_DLL defined so that the functions are exported,
>and the project that calls these functions does not have it defined so that
>the functions are imported.
>
>The DLL exports functions called "func1" and "func2". The names don't have
>a leading "_".
Hi David,
I used the technique you listed in your post, too. (Of course, this is
a standard technique.)
But when the functions you export use __stdcall, the names *do* get
decorated with _ and @ suffix and byte count.
I only use the .def files when I need to export __stdcall functions
without name decoration.
I use the #ifdef/.../__declspec technique when I don't care about
decoration or __stdcall.
MrAsm
David Ching
> But when the functions you export use __stdcall, the names *do* get
> decorated with _ and @ suffix and byte count.
>
Hmm, I just checked in one of my projects, and I get the opposite. When
declaring the functions as in the previous post, I built the DLL and then
ran on the command-line:
DUMPBIN /exports "mydll.dll"
to list the exports.
It listed them without any decoration whatsoever. Furthermore, I do a
LoadLibrary/GetProcAddress to use these functions, and the sting I pass to
GetProcAddress() doesn't have any decoration either.
-- David
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>"MrAsm" <mr...@usa.com> wrote in message
>news:qn3ov29rb2kv2b33r...@4ax.com...
>> But when the functions you export use __stdcall, the names *do* get
>> decorated with _ and @ suffix and byte count.
>>
>
>Hmm, I just checked in one of my projects, and I get the opposite. When
>declaring the functions as in the previous post, I built the DLL and then
>ran on the command-line:
>
> DUMPBIN /exports "mydll.dll"
>
>to list the exports.
>
>It listed them without any decoration whatsoever.
But I believe this is because your functions are *not* __stdcall (they
are __cdecl).
I've just built this demo DLL:
<CODE src="MyDll.cpp">
extern "C" int __declspec(dllexport) TestFunction(int x)
{
return 2*x;
}
extern "C" float __declspec(dllexport) __stdcall TestFunctionStdCall(
float x )
{
return x*x;
}
</CODE>
The function 'TestFunction' (which is __cdecl - as default, as your
function) does not get decorated (OK), *but* the function
'TestFunctionStdCall' (which is __stdcall) does get decorated, as I
wrote above.
You need a .def file in this case to remove decoration. (Or, at least,
I do not know other methods to remove a decoration for __stdcall
functions, different from using a .def file - this is the only case I
use .def files).
MrAsm
David Ching
> You need a .def file in this case to remove decoration. (Or, at least,
> I do not know other methods to remove a decoration for __stdcall
> functions, different from using a .def file - this is the only case I
> use .def files).
>
Ah, yes, that makes sense. Thanks, I had thought __stdcall and _cdecl both
got the decorations (if there were going to be any decorations), but now i
seem to recall __stdcall is really PASCAL calling convention. This explains
why all the Windows exports, say like for _lclose() have the underscore.
Thanks,
David
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>Thanks,
>David
Thank you for your time and your posts.
MrAsm