Why can’t I GetProcAddress a function I dllexport’ed?


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 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 GetProcAddress(hinst, "..SomeFunction"), but if it is exported from an 80386 DLL as extern "C" __stdcall, you would need GetProcAddress(hinst, "_SomeFunction@8"), but if it's __fastcall you would need GetProcAddress(hinst, "@SomeFunction@8").

What's more, C++ decoration varies from compiler vendor to compiler vendor. A C++ exported function might require GetProcAddress(hinst, "?SomeFunction@@YGXHH@Z") if compiled with the Microsoft C++ compiler, but some other decorated string if compiled with the Borland C++ compiler.

So if you intend people to be able to GetProcAddress for functions and you intend your code to be portable to multiple platforms, or if you intend them to be able to use your DLL from a language other than C/C++ or use a C++ compiler different from Microsoft Visual Studio, then you must export the function by its undecorated name.

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 dllexport ties you to an architecture, compiler, and language (by exporting decorated names), then why does MSVCRT.DLL use it?

Comments (17)
  1. Doug says:

    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.

  2. anon says:

    What’s the best way to export a function usings its undecorated name? … maybe .def files?

  3. Raymond Chen says:

    Yes, in order to export undecorated, you need a DEF file.

  4. KiwiBlue says:

    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.

  5. asdf says:

    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.

  6. e8johan says:

    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?

  7. Florian says:

    No, different compilers do also use a different format for the virtual function table and put it in different places.

  8. BTannenbaum says:

    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)

    {

    :

    }

  9. Raymond Chen says:

    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.)

  10. Scott Rogers says:

    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 <<<

  11. Raymond Chen says:

    LIBRARY engine1

    EXPORTS

    enginecommand

  12. Scott Rogers says:

    That is too simple :)

    Thanks for the help!

  13. agraeper says:

    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

  14. Raymond Chen says:

    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.

  15. Raymond Chen says:

    Commenting on this entry has been closed.

  16. I found this list of article on Raymond&#39;s blog . Raymond&#39;s blog is one of the more interesting

Comments are closed.