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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
