[Mono-devel-list] Managed/Unmanaged Code Interop... v2.1

[Bernie Solomon]

It has taken me a little while to get round to looking at this but having
read it I do have a few comments.

Firstly I think this is very useful to try and pin down as much as it can be
and document....

My comments are:

- For library names - you don't have much choice if your libraries have
different names on different platforms but to use mono's mapping mechanism -
but if they are the same bar extension (dll/so/sl) then I find it simpler to
just leave off the extension in the DllImport and it works on all platforms
& .Net without any config changes:

[DllImport("libmine")] extern static int myFunc();

of course the case of the library has to match on Unix and doesn't matter on
Windows.

- You can access C++ if you really want - definitely for calls without
'this' and non-virtual calls would probably work- the problem here is the
name mangling in that you need to use the EntryPoint parameter and put in
the mangled name - and this is platform & compiler dependent which makes
portability hard.

- Your section on StringBuilder should probably mention whatever the
interaction is with CharSet (I am not sure what that is off hand - would
require some experimentation).

- I am kind of interested why you'd use class marshalling not having thought
of needing it myself. struct marshalling is essential for talking to legacy
APIs but what can do you do with the managed class when it is in C/C++ (and
in any form of portable way???)

- The structure marshalling section says structs are typically on the stack
and passed by reference to the unmanaged function. This is only true for
struct which contains blittable types (if so implemented) so any member
which is a string or even a bool causes a copy. However .Net seems to copy
in/and out even if all you have is "ref" as the argumemt type.

- Mentioning that bool is special and if say you want to map it to an
unsigned char needs MarshalAs might make this more complete.

- Also in my .Net experimentation the runtime does seem to allocate space
for arrays in structs for "out" parameters.

- Finally anything which uses FieldOffset is impossible to be portable if
there are any pointers about in it and you need 64 bit platforms.

But it was useful to read and I learnt more about this area from what is
there....

Bernie Solomon

----- Original Message ----- 
From: "Jonathan Pryor" <jonpryor at vt.edu>
To: "Mono List" <mono-list at ximian.com>; "Mono Documentation"
<mono-docs-list at lists.ximian.com>; "Mono Development List"
<mono-devel-list at lists.ximian.com>
Sent: Tuesday, September 09, 2003 7:55 PM
Subject: [Mono-devel-list] Managed/Unmanaged Code Interop... v2.1


> The latest draft for my managed/unmanaged code interop
> documentation is available for perusal at:
>
> http://www.jprl.com/~jon/interop.html
>
> I feel like I'm writing a chapter for a book.  It would be nice,
> actually; I have yet to see all this information in one place.
>
> Please review.  I'd like as many suggestions as possible.  You can
> ignore the TODOs for now; some will be taken care of in the next draft.
>
> Thanks,
>  - Jon
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>