[Mono-dev] Multiplatform support with P/Invoke

[Miguel de Icaza]

For something like this, instead of trying to do a high fidelity mapping of
the low level APIs that you would call from C# and then do the abstraction
work from C#, I would instead do the heavy lifting in C, provide the
abstraction there and surface a simple API to C# which you invoke there.

Miguel

On Friday, January 1, 2016, Jason Curl <jcurlnews at arcor.de> wrote:

>
> On 2016-01-01 13:17, Miguel de Icaza wrote:
>
>> Re-reading your original question makes me wonder if you really need
>> something as heavy handed as the approach on Mono.Posix.
>>
>
> Specifically I will port my .NET implementation
> http://serialportstream.codeplex.com to Mono on Linux, but why stop
> there? I would further consider BSD socket networking code which is much
> more complicated (especially obtaining interface names).
>
>>
>> The challenge that Mono.Posix faces is that the structures exposed in
>> each Unix is slightly different (different location for fields, different
>> data types for fields), so Mono.Posix resorts to defining its own
>> interface, say instead of using "struct stat" and trying to have one
>> universal implementation that works across many different Unix systems - it
>> instead defines a "struct MyStat" which has well known fields at well known
>> locations with well known sizes.
>>
>> I've experience in writing portable code with the help of Autotools on
> Solaris, FreeBSD, Linux, Cygwin and QNX, all of which have their own quirks
> as you've needed to solve with Mono.Posix.
>
> Then the C glue maps between those two.
>>
>> But in your case, it is not clear if you are trying to bind libc and
>> their structures, or trying to bind your own C library that already has a
>> stable ABI.  If you are coping with the latter, you do not need a setup as
>> tedious as the one that Mono.Posix does, you merely need to ship your
>> native library for each platform you intend to support and your C# code
>> that calls into it.
>>
>
> I've not started the port of my project to Unix and so have no library
> already. I will write one though, as it seems the solution that Mono.Posix
> has taken. It also appears the only /portable/ way that I can take without
> having to make assumptions about structure layouts.
>
>>
>> Miguel
>>
>
> I took a further look at DllMaps, and while I haven't started/tested yet,
> I believe this can simplify effort by allowing me to having one native lib
> per architecture and a single .NET class that "standardizes" the interfaces
> I need.
>
> I'm still researching the best way. Right now, I'm planning on having a
> Cmake/Autotools project to build my library for the platform, use DllMaps
> to let the Mono runtime pick the appropriate native library when running if
> OSVersion is Unix (etc.)
>
> Do you have time to highlight how the MapAttribute works in Mono.Posix?
>
> Thankyou for your support,
> Jason.
>
>>
>> On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl <jcurlnews at arcor.de <mailto:
>> jcurlnews at arcor.de>> wrote:
>>
>>     Thank you Mr. Icaza.
>>
>>     Is there more information on what uses the MapAttribute than
>>     what's in Syscall.cs? Even though it's internal and I won't use
>>     it, I'd like to understand how you solve the problem of ABI
>>     compatibility.
>>
>>     I'd like to set up a solution where copying the files from one
>>     architecture to another simply works (assuming all dependencies
>>     from the runtime are present), and the runtime/mylib chooses the
>>     most appropriate native library (based on OSVersion and
>>     Syscall.uname) for all supported platforms. Something like:
>>     * MyLib.dll (assembly)
>>     * MyNativeLib.Linux.x86.so <http://MyNativeLib.Linux.x86.so>
>>     * MyNativeLib.Linux.x64.so <http://MyNativeLib.Linux.x64.so>
>>     * MyNativeLib.FreeBSD.x86.so <http://MyNativeLib.FreeBSD.x86.so>
>>     * MyNativeLib.Darwin.x86.so <http://MyNativeLib.Darwin.x86.so>
>>     * MyNativeLib.Win.x86.dll (windows native)
>>     * MyNativeLib.Win.x64.dll (windows native)
>>     * MyNativeLib.[dll|so] (backup for local builds)
>>
>>     Your solution (Mono.Unix.Native) looks different, more compact,
>>     but I'm not sure if/how it supports side-by-side. My solution
>>     requires a lot of work, duplicate code with small changes in
>>     defining the structs/DllImports with different offsets and library
>>     names.
>>
>>     I've yet to look into the Dll mapping mechanism of Mono if that's
>>     also suitable.
>>
>>     Thank you very much and for giving me the opportunity to use Mono.
>>
>>     Regards,
>>     Jason.
>>
>>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20160101/22fa1f25/attachment.html>