I'd like a simple example of exporting a function from a C++ Windows DLL.
I'd like to see the header, the .cpp
file, and the .def
file (if absolutely required).
I'd like the exported name to be undecorated. I'd like to use the most standard calling convention (__stdcall
?). I'd like the use __declspec(dllexport)
and not have to use a .def
file.
For example:
//header
extern "C"
{
__declspec(dllexport) int __stdcall foo(long bar);
}
//cpp
int __stdcall foo(long bar)
{
return 0;
}
I'm trying to avoid the linker added underscores and/or numbers (byte counts?) to the name.
I'm OK with not supporting dllimport
and dllexport
using the same header. I don't want any information about exporting C++ class methods, just c-style global functions.
UPDATE
Not including the calling convention (and using extern "C"
) gives me the export names as I like, but what does that mean? Is whatever default calling convention I'm getting what pinvoke (.NET), declare (vb6), and GetProcAddress
would expect? (I guess for GetProcAddress
it would depend on the function pointer the caller created).
I want this DLL to be used without a header file, so I don't really need the a lot of the fancy #defines
to make the header usable by a caller.
I'm OK with an answer being that I have to use a *.def
file.
This question is related to
winapi
visual-c++
dll
name-decoration
I think _naked might get what you want, but it also prevents the compiler from generating the stack management code for the function. extern "C" causes C style name decoration. Remove that and that should get rid of your _'s. The linker doesn't add the underscores, the compiler does. stdcall causes the argument stack size to be appended.
For more, see: http://en.wikipedia.org/wiki/X86_calling_conventions http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx
The bigger question is why do you want to do that? What's wrong with the mangled names?
For C++ :
I just faced the same issue and I think it is worth mentioning a problem comes up when one use both __stdcall
(or WINAPI
) and extern "C"
:
As you know extern "C"
removes the decoration so that instead of :
__declspec(dllexport) int Test(void) --> dumpbin : ?Test@@YaHXZ
you obtain a symbol name undecorated:
extern "C" __declspec(dllexport) int Test(void) --> dumpbin : Test
However the _stdcall
( = macro WINAPI, that changes the calling convention) also decorates names so that if we use both we obtain :
extern "C" __declspec(dllexport) int WINAPI Test(void) --> dumpbin : _Test@0
and the benefit of extern "C"
is lost because the symbol is decorated (with _ @bytes)
Note that this only occurs for x86 architecture because the
__stdcall
convention is ignored on x64 (msdn : on x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.).
This is particularly tricky if you are targeting both x86 and x64 platforms.
Two solutions
Use a definition file. But this forces you to maintain the state of the def file.
the simplest way : define the macro (see msdn) :
#define EXPORT comment(linker, "/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
and then include the following pragma in the function body:
#pragma EXPORT
Full Example :
int WINAPI Test(void)
{
#pragma EXPORT
return 1;
}
This will export the function undecorated for both x86 and x64 targets while preserving the __stdcall
convention for x86. The __declspec(dllexport)
is not required in this case.
I had exactly the same problem, my solution was to use module definition file (.def) instead of __declspec(dllexport)
to define exports(http://msdn.microsoft.com/en-us/library/d91k01sh.aspx). I have no idea why this works, but it does
Source: Stackoverflow.com