On Dec 13, 2010, at 7:08 PM, Charles Strahan wrote:
> If I understand correctly, we'd have two options for using DLLImport:
I am missing some important context, so I don't understand what you want to
accomplish, what the problems are, and thus what the "best" way to do it is.
As per my original response, libffi was removed from mono for performance
reasons, and it is thus unlikely to return.
I do not know or understand the semantics of RubyFFI, how it's similar to
libffi & P/Invoke, and how it differs from P/Invoke, much less how to map
RubyFFI use to P/Invoke use (if that's even desirable; again, I have no idea).
> 1.) Emit classes at runtime, containing the necessary native
> function adorned with the DLLImport attribute.
I can't say if this would work for _you_, but I can say that this can work in
general; see:
https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/CdeclFunction.cs
> 2.) Use DLLImport/PInvoke to provide access to
> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
> load DLLs and invoke their functions.
This seems silly, given that [DllImport] & P/Invoke are built upon
dlopen+dlsym/LoadLibrary+GetProcAddress; I do not see the point.
- Jon
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
