Почему у меня не получается вызвать GetProcAddress для функции, которую я экспортировал dllexport-ом?

Это перевод Why can't I GetProcAddress a function I dllexport'ed? Автор: Реймонд Чен.
Атрибут dllexport просит линкёр сгенерировать запись в таблице экспорта для указанной функции. Название функции в этой записи декорируется. Это необходимо для поддержки эксорта (dllexporting) перегружаемых (overload) функций. Но это также означает, что имя, которое вы указываете в GetProcAddress, тоже должно быть декорировано.
Как мы узнали ранее, схема декорирования зависит от архитектуры и модели вызова. Так что, например, если функция импортируется из DLL на PPC, вы должны будете написать GetProcAddress(hinst, '..SomeFunction'), но если она импортируется из DLL на 80386 с моделью вызова stdcall, то вам нужно вызывать GetProcAddress(hinst, '_SomeFunction@8'), но если соглашение вызова будет fastcall, то вам придётся использовать GetProcAddress(hinst, '@SomeFunction@8').

Но это ещё не всё. Декорация имён C++ может меняться в зависимости от компилятора. Экспортируемая функция C++ может требовать GetProcAddress(hinst, '?SomeFunction@@YGXHH@Z'), если она была скомпилирована компилятором Microsoft C++, но какую-то другое декорированное имя, если она была скомпилирована Borland C++.

Так что если вы планируете, что вашу функцию будут импортировать через GetProcAddress, и вы хотите сделать свой код портируемым или разрешить использование вашей DLL из языка, отличного от C/C++ или использовать компилятор, отличный от Microsoft Visual Studio, то тогда вы должны экспортировать функцию по её недекорированному имени (да, для этого вам понадобится DEF-файл).

Когда DLL генерируется, компоновщик C/C++ создаёт соответствующий LIB-файл, который переводит декорированные имена в недекорируемые. Так, к примеру, LIB-файл может содержать запись, которая говорит: "если кто-то спросит функцию _GetTickCount@0, то перенаправьте его на kernel32!GetTickCount".

Упражнение: если dllexport привязывает вас к архитектуре, компилятору и языку (экспортом имён в декорированном виде), то почему же тогда MSVCRT.DLL использует его?