DLL Function Pointers Declared With "win32"

Hi,

I've spent the entire afternoon tracking down a problem whereby some of my DLL code worked fine in Debug mode, but not in Release mode. 2 minutes ago, after deciding to call it a day, I noticed that some of the DLL function pointers had "win32" after them, and some didn't. For example,

	Global DrawThemeText( hTheme%, hDC%, iPartID%, iStateID%, pszText$w, iCharCount%, dwTextFlags%, dwTextFlags2%, pRect:Int Ptr ) "win32" = GetProcAddress(libUXTheme, "DrawThemeText")
	Global GetThemeBackgroundContentRect( hTheme%, hdc%, iPartId%, iStateId%, pBoundingRect:Int Ptr, pContentRect:Int Ptr ) "win32" = GetProcAddress(libUXTheme, "GetThemeBackgroundContentRect")
	Global IsThemeBackgroundPartiallyTransparent( hTheme%, iPartId%, iStateId% ) = GetProcAddress(libUXTheme, "IsThemeBackgroundPartiallyTransparent")

As I'm interfacing with the Windows API, I added "win32" to the remaining function pointers, hit compile, and everything worked brilliantly.

What the hell does "win32" actually do? I can't see it documented anywhere, but it's just wasted several hours of my life!!!! (Calm down Seb, take deep breaths)

Anyone any ideas?

Edit: They also seem to have a use after Methods, and Extern blocks.

From what I can tell it makes the function use the stdcall calling convention.

Oh... I've never heard of stdcall before, but I looked it up on Google and it seems to make sense. Thanks.

Not sure why it was working in debug but not release mode, though...

The wrong calling convention usually corrupts memory and causes an error after the actual call itself. So it's possible that there was just a bit more code in debug and it had more chance to throw an error. It can be a real SOB to debug incorrect calling conventions, so you probably got off lightly with several hours. I know I've done worse.

It gives you STD.