Peter Tanski wrote:
> 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.
NCG supports stdcall just fine. It must do: we can foreign import stdcall
functions at the moment, the Win32 package is full of them. What problem are
you trying to solve here?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
