Date: | January 12, 2004 / year-entry #14 |
Tags: | code |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040112-00/?p=41083 |
Comments: | 17 |
Summary: | The dllexport attribute tells the linker to generate an export table entry for the specified function. This export entry is decorated. This is necessary to support dllexporting of overloaded functions. But it also means that the string you pass to GetProcAddress needs to be decorated. As we learned earlier, the decoration scheme varies from architecture... |
As we learned earlier, the decoration scheme varies from architecture to architecture and from calling convention to calling convention. So, for example, if the function is exported from a PPC DLL, you would have to do What's more, C++ decoration varies from compiler vendor to compiler vendor. A C++ exported function might require So if you intend people to be able to When a DLL is generated, the linker produces a matching LIB file which translates the decorated names to undecorated names. So, for example, the LIB file has an entry that says, "If somebody asks for the function _GetTickCount@0, send them to kernel32!GetTickCount." Exercise: If |
Comments (17)
Comments are closed. |
Re: Exercise: If dllexport ties you to an architecture, compiler, and language (by exporting decorated names), then why does MSVCRT.DLL use it?
Because a C runtime library is tied to an CPU, compiler and language. You tend to use a CRT for the development setup which it was intended. Doesn’t Borland provide their own CRT?
If you intend for a function to be used as an API, you need to take care of the calling convention.
I had to import a function from a DLL that was exported using an IBM only calling convention, and I was using the Borland compiler. (On OS2.) Was, umm, interesting to work around.
What’s the best way to export a function usings its undecorated name? … maybe .def files?
Yes, in order to export undecorated, you need a DEF file.
I’m usually exporting like this:
extern "C" __declspec(dllexport)
Foo* __cdecl GetFoo()
AFAIR, it has to be both extern "C" and __cdecl to avoid name mangling.
http://www.mingw.org (basically, gcc for windows) can use msvcrt.dll. There are only a handful of C++ decorated stuff exported from it, every function from the C side is nicely named.
Is the decoration themes the only thing that separates the different compilers (when it comes to binary compatibility, otherwise there are tons of differences, I know)? In that case, why not make it possible, to tell from what compiler an imported lib comes from and thus get it to work?
No, different compilers do also use a different format for the virtual function table and put it in different places.
For those who don’t want yet another file to keep current, you can use a #pragma to generate a linker directive:
// Linker directive to export MyExportedFunction, and in its completely
// undecorated form
#if defined(_WIN64)
#pragma comment(linker, "/EXPORT:MyExportedFunction")
#else
#pragma comment(linker, "/EXPORT:MyExportedFunction=_MyExportedFunction@4")
#endif
extern "C"
bool __stdcall MyExportedFunction (int i)
{
:
}
Of course as support for new architectures gets added you’ll have to keep tweaking your #pragma. A DEF file doesn’t have this problem, plus I like having all my exports in one place – makes it obvious where the interop points are for the DLL.
(Note also that you probably should use "BOOL" instead of "bool" since "bool" is a C++-specific type.)
Can you show me an example of a DEF file using an undecorated name?
I have:
>>> BEGIN DEF FILE <<<
LIBRARY engine1
EXPORTS
enginecommand _enginecommand@8
>>> END DEF FILE <<<
LIBRARY engine1
EXPORTS
enginecommand
That is too simple :)
Thanks for the help!
When i use explicit binding, can i still use a .def file? The only alternative but the #pragma workaround seems to be the use of ordinal numbers for the import, correct?
regards, arne
Not sure what you mean by "explicit binding". Do you mean manually using GetProcAddress? In that case, then sure you can use a DEF file. In fact, you probably *want* to use a DEF file in order to avoid the decoration.
Commenting on this entry has been closed.
Two tables.
I found this list of article on Raymond's blog . Raymond's blog is one of the more interesting