Re: Win-GHC with GnuWin32 toolset--Mingw32 replacement

On Jan 8, 2007, at 11:20 AM, Neil Mitchell wrote:
>> For the next step, the move to DLLs produced by NativeGen, GHC uses
>> what Windows calls the __cdecl calling convention (caller performs
>> stack cleanup, underscore '_' prepended to function name), while to
>> my knowledge DLLs require the __stdcall calling convention (callee
>> performs stack cleanup, same '_' prepended and commercial-at '@' and
>> number of bytes stack space appended).
>
> Windows supports __fastdecl, __cdecl and __stdcall equally. All the
> Windows API's are stdcall, apart from one or two functions which are
> cdecl (those which take variable argument lists). VB 6 can only do
> stdcall calls. Delphi by default does fastcall, Visual Studio by
> default does cdecl - both can call any of the 3. Some tools only work
> with stdcall, but most have a reasonably broad support.
>
> I'm not sure changing from cdecl is all that necessary.

To my knowledge a mismatch in calling convention ( __cdecl ->  
__stdcall) is not a problem for static libraries but for dynamic  
bindings it can lead to very bad things since the stack cleanup  
methods (caller, callee) are almost completely the opposite.  Since  
the Windows API's (DLL versions) are __stdcall, NativeGen will need  
to support __stdcall for dynamic bindings to them.

Cheers,
Pete