Win-GHC with GnuWin32 toolset--Mingw32 replacement
simonmarhaskell at gmail.com
Tue Jan 9 04:01:05 EST 2007
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.
More information about the Cvs-ghc