7) Devise a way of telling GHC that a foreign import is imported from a
DLL (for Windows); something like __declspec(dllimport) in Windows C
compilers. We should have thought of this before the FFI spec was
finalized...
[...]
Can you explain point 7?
How is a foreign import from DLL different from a foreign import from
statically linked files or from foreign import of a function pointer?
Do you have to do something different to cause the DLL to be loaded or do you
have to invoke the function using a different calling convention or both?
Hmmm... while trying to explain it I found out that I was wrong. Linkers for Win32 do just enough to work around the basic problem with Win32 DLLs for foreign calls to work without problems. The problem still exists with variables imported from DLLs, and if you take the address of an imported function, the pointer will actually point to some stub code instead of the real thing. We can probably ignore this problem...
Dynamically imported things must be accessed via an indirection, and statically imported things *must not* be. A thing from a statically-linked file is just a label; However, if we import that thing from a DLL, this label is not defined. Instead, we get a label __imp__foo, which points to *the address of* the imported thing. We have to dereference it when we use it.
For imported functions, the import library contains a piece of stub code:
_foo: jmp *__imp__foo
... and that's what (mostly) solves the problem, because we can still just call _foo. It doesn't work for imported data, but who imports data anyway?.
Sorry for the confusion,
Wolfgang
_______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
