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

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

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:
    January 12, 2004 at 8:07 am

    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:
    January 12, 2004 at 8:52 am

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

  3. Raymond Chen says:
    January 12, 2004 at 8:54 am

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

  4. KiwiBlue says:
    January 12, 2004 at 11:17 am

    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:
    January 12, 2004 at 2:39 pm

    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:
    January 12, 2004 at 11:33 pm

    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:
    January 13, 2004 at 7:13 am

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

  8. BTannenbaum says:
    January 14, 2004 at 1:29 pm

    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:
    January 14, 2004 at 1:55 pm

    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:
    March 2, 2004 at 5:35 pm

    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:
    March 2, 2004 at 5:49 pm

    LIBRARY engine1

    EXPORTS

    enginecommand

  12. Scott Rogers says:
    March 2, 2004 at 6:05 pm

    That is too simple :)

    Thanks for the help!

  13. agraeper says:
    March 12, 2004 at 4:34 am

    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:
    March 12, 2004 at 7:00 am

    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:
    July 5, 2004 at 8:57 am

    Commenting on this entry has been closed.

  16. The Old New Thing says:
    July 14, 2006 at 10:00 am

    Two tables.

  17. Cluebat-man to the rescue says:
    September 12, 2008 at 6:51 am

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

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index