kumpera at gmail.com
Mon Dec 13 23:14:11 EST 2010
One thing, it's possible to use a binding to libffi with mono, it's just
that mono's p/invoke is not built using it anymore.
On Tue, Dec 14, 2010 at 1:48 AM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> 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
> > 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:
> > 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
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list