[Mono-list] PInvoke Conventions

[Fergus Henderson]

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.