Win-GHC with GnuWin32 toolset--Mingw32 replacement

[Peter Tanski]

On Jan 8, 2007, at 11:56 AM, Simon Marlow wrote:
> Peter Tanski wrote:
>> 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?

There are two issues: explicitly loading DLLs (manually linking them)  
and creating GHC-compiled libraries as relocatable DLLs.  This isn't  
necessary at the moment, of course but would be very useful for a  
fully native version because it would allow you to place the DLLs  
anywhere in the standard MS search path instead of a single location-- 
programs compiled by GHC would want this.   I knew foreign import  
supported stdcall but I did not know the NCG did.  There may be no  
problem at all except ensuring there are no mismatches (or  
converting, if necessary).  At least conversions in foreign calls may  
rely on the C compiler which will handle the convention for you with  
the appropriate declarations.

Cheers,
Pete