Thread: DLL Function Decoration

I have a question based on an experience I recently had over on StackOverflow:

If I declare functions in my win32 dll like this:

Code:

#ifdef __cplusplus
extern "C" {       
#endif

__declspec(dllexport) HWND      gethwnd(void);
__declspec(dllexport) HINSTANCE getinst(void);
__declspec(dllexport) int       getid(void);
__declspec(dllexport) LRESULT CALLBACK dllProc(HWND, UINT, WPARAM, LPARAM );

#ifdef __cplusplus
}
#endif

A session in dumpbin for the DLL shows the exports as:

Code:

gethwnd
getinst
getid
_dllProc@16

Why doesn't the <extern "C"> declarator un-decorate the CALLBACK (__stdcall) function as well as the __cdecl functions (all the 'get' functions are __cdecl)?

It was suggested that a def file may have forced a name change on the __cdecl exports, however, there is no def or lib file involved in any of this, the dll is loaded and it's exports parsed internally by the caller (ala Matt Pietrek) which then gets pointers to the functions of interest.

It was also suggested that the __stdcall convention always lists the argument-bytes (@16) because the callee pops the args off the stack, so this decoration behavior is normal for __stdcall functions.

I'd like to know that the decoration behavior is consistent (one way or the other) since the caller depends on this.
.