GetProcAddress in Unicode builds

If you have code like this :-

GetProcAddress(hModComCtl,_T("DllGetVersion"));

It won’t compile when UNICODE is defined.

This is so because there are no separate GetProcAddressW/GetProcAddressA functions. The second argument to GetProcAddress is an LPCSTR (const char*), because exported names in Win32 modules are stored as ANSI strings. The right way to write the above line would be :-

GetProcAddress(hModComCtl,"DllGetVersion");

I can’t remember right now if there are other commonly used API functions that depict similar behavior.

7 thoughts on “GetProcAddress in Unicode builds

  1. True for the desktop. On Windows CE there are indeed both GetProcAddressA and GetProcAddressW routines, and GetProcAddressW’s argument is LPWSTR. I’m not sure why, since the executable format is the same – exported names are in a byte-oriented character set.

  2. Now, just wait until you find code that, because of this error, has been written to convert a literal Unicode string back to ASCII before passing it to GetProcAddress()… *groan*

  3. Maybe a performance issue.
    Since Win32 modules are stored as ANSI strings, a GetProcAddressW would have to convert from Unicode to ANSI every time. Some code use GetProcAddress for every call to the exported function.

    1. Actually, according to the documentation they’re ASCII names, so officially the top bit should be clear, although I don’t think Windows actually checks.

Leave a comment