[Mono-list] PInvoke Conventions

[Richard Anthony Hein]

I have been trying to follow this thread, but could someone perhaps give
high-level explanation of the conflict?  What is the problem implementing
PInvoke and how does the implementation pose a possible problem with the use
of the Mono API with other CLIs?

If you don't have time, point me to some docs that will fill me in.

This sounds related to some questions about native code mixed with code
running on the CLR that were answered by the MC++ project manager on another
list, but I am not totally sure unless I have a better idea about the
problem.

Thanks,

Richard Anthony Hein

> -----Original Message-----
> From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On
> Behalf Of Miguel de Icaza
> Sent: July 29, 2001 6:45 PM
> To: Rhys Weatherley
> Cc: mono-list@ximian.com
> Subject: Re: [Mono-list] PInvoke Conventions
>
>
>
> Rhys,
>
> > And which will no doubt be hard-wired to Mono API
> > and autoconf conventions, and hence useless to anyone
> > else who may be interested in running applications built
> > to work with the Mono C# library.  Hence, the rest of
> > us will have to start from scratch.
>
> As I said in an earlier message, I am willing to accomodate the needs
> of other CLI runtime implementations (it is on a separate thread).
>
> Now, even if we took radically different approaches (PInvoke
> annotations vs generated support libraries), the changes are going to
> be isolated in one, maybe two "private" classes at most.
>
> No matter what direction we take with the Mono class libraries, in the
> worst possible case, you would have to write a single class that would
> work for Portable.NET.
>
> And my offer is to have those changes integrated directly into the
> class distribution of Mono.  Hey, I can even give you CVS access to
> the tree to make those changes yourself and make sure the makefiles
> can work with both setups.
>
> > The proposal to use type diversion, where "stat" can be
> > diverted to a "NativeStat" in a platform-specific assembly
> > is much better than this.  The platform-specific parts are
> > completely in a C#-based "native.dll" which is portable
> > from one VM to another.  Any approach that uses C to
> > make the glue will bind the C# library to one VM only.
>
> The problem is -As Ferguson- pointed out that this is just a lot of
> bloat for the runtime when there is a simpler solution available.
>
> What if Mono has mononat.dll and you have portnat.dll?  Big deal, a
> tiny library that does not really make a difference.
>
> Miguel.
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>