Hello Gisle,

> I've tried libcurl.NET and it works fine! Then I
> tried to build the
> LibCurlShim.dll with MingW, but failed due to
> missing <dlfcn.h>
> etc. Aren't the shim sources used for Mono and .NET?

No, one major difference is that the .NET shim has
more functions because .NET delegates are implemented
as __stdcall (callee cleans up stack) while mono
delegates are implemented as __cdecl (caller cleans up
stack) functions. This means that, for .NET, libcurl's
callbacks, which are __cdecl, must be intercepted in
the shim and forwarded to the __stdcall delegate.

> What is purpose of this shim anyway? I thought the
> integration
> of unmanaged code in .NET should be easier than
> this.

In addition to the .NET delegate issue, another
purpose of the shim is to call curl_formadd() with
variable arguments. In this case, we have to set up
the stack, make the function call, and clean up the
stack. See formadd.c in mono.

Another thing that the shim is used for, in mono, is
to call select(), which, being a system call rather
than a library function, cannot be called via
P/Invoke.

Some of the other code in the shim, I suspect, could
be moved to the C# codebase (especially the
curl_version handling stuff), but it seemed much
easier to write this code in C and leave it in the
shim, since I needed it anyway.

All of that said, in general, the .NET/mono P/Invoke
interface is pretty good, but libcurl threw in a few
wrinkles.

Finally, I'm contemplating open-sourcing the .NET
code, but I'm not sure yet. I've never worked with
MingW, but you may be able to replace the <dlfcn.h>
defined-stuff (dlopen, dlclose, dlsym) with
LoadLibrary, FreeLibrary and GetProcAddress and see if
that helps.

Hope this note helps.

Take care,
Jeff
Received on 2004-12-10