[Mono-list] PInvoke Conventions

[Richard Anthony Hein]

Thanks for the input; sounds like a simple enough explanation for a tricky
problem.  I guess MS doesn't have to worry about this, since they got
Portable.NET and Mono working on it. ;-)

The wrapper would only have to be compiled once, would it not?  Am I right
in thinking it acts as a layer between the .NET PE and the C\Unix APIs, and
therefore only needs to be compiled once on a particular platform?

If so, why is that considered a problem?  From the sounds of it the wrapper
option would make it possible for plenty of other groups to develop wrappers
for their platform, instead of putting all the responsibility on Mono to
have this VM that works well everywhere.  But I am just getting into this
stuff, so what do I know.

Regards,

Richard Anthony Hein


> -----Original Message-----
> From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On
> Behalf Of Fergus Henderson
> Sent: July 29, 2001 11:24 PM
> To: Richard Anthony Hein
> Cc: mono-list@ximian.com
> Subject: Re: [Mono-list] PInvoke Conventions
>
>
> On 29-Jul-2001, Richard Anthony Hein <935551@ican.net> wrote:
> > I have been trying to follow this thread, but could someone
> perhaps give
> > high-level explanation of the conflict?
>
> Sure.
>
> Many of the .NET APIs will need to be implemented using code
> that calls C/Unix
> APIs, such as stat().  The standard way of interfacing with
> native code from
> NET code is to use "PInvoke".  However, there is a difficulty: many of
> these APIs are defined in terms of types such as C's `long'
> or `size_t'
> or the Posix `struct stat' whose representation varies
> depending on the
> platform (architecture/OS/C compiler).  There's no *portable* way of
> accessing those from .NET managed code.
>
> So, there are a couple of different approaches.
> One possibility is to access such routines by writing a
> wrapper, e.g. in C,
> that provides the same functionality without using types with
> a system-dependent
> representation.  The wrapper can then be directly accessed
> from portable
> NET code.  The .NET code remains both source- and binary-portable;
> the wrapper code is source-portable, but needs to be compiled
> seperately for each target platform.  The drawback of this approach is
> that you have to write a lot of cumbersome wrapper code.
>
> Another possibility is to extend the .NET VM with support for an
> additional custom attribute, e.g. "[PosixType]".  The VM would then
> represent types tagged with this attribute in the same way that the
> underlying system represents those types.  With this approach, no
> wrapper code would be needed.  A drawback of this approach is that it
> pushes quite a bit of complexity into the VM; the VM would
> have to know
> the native representation of all types annotated with this attribute.
> Another drawback is that code using this extension might not work on
> different VMs.
>
> There have also been some other suggestions, but those are
> the two that
> I think are the best.
>
> > What is the problem implementing PInvoke
>
> There's no problem implementing PInvoke as specified in the ECMA
> specs and/or MS documentation.  It's just that PInvoke by itself
> doesn't solve all of the problems; in particular it doesn't solve
> the problem of C types whose representation is different on different
> systems.
>
> --
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known
> that the pursuit
> The University of Melbourne         |  of excellence is a
> lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words
> of T. S. Garp.
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>