Win-GHC with GnuWin32 toolset--Mingw32 replacement

[Simon Marlow]

Peter Tanski wrote:
> 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.

Creating DLLs from Haskell code is orthogonal to the native Windows port; I 
think you're complicating the issue here.  There's a lot to do in order to get 
DLLs working, but it's not on the critical path.

Explicitly loading DLLs (using LoadLibrary, I presume) is supported, and again I 
think this is orthogonal to the native windows port.

If there were any calling convention mismatches, then they would already be 
affecting us - in fact we did find a couple recently.

Cheers,
	Simon