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 <[email protected]> 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 > 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 >
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
