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. Anonymous 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. Anonymous says:

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

  3. Anonymous says:

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

  4. Anonymous 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. Anonymous 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. Anonymous 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. Anonymous says:

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

  8. Anonymous 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. Anonymous 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. Anonymous 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. Anonymous says:

    LIBRARY engine1

    EXPORTS

    enginecommand

  12. Anonymous says:

    That is too simple :)

    Thanks for the help!

  13. Anonymous 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. Anonymous 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. Anonymous says:

    Commenting on this entry has been closed.

  16. Anonymous says:

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

Comments are closed.