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