[Mono-list] Why InternalCall rather than DllImport?

[Matt Kimball]

Dick Porter wrote
> The file IO routines need to emulate w32 handles somehow.  Currently, we're
> emulating w32 IO in the io-layer library and accessing it with internal calls.
> This gives us simpler C# classes (because they tend to match w32 calls) and
> cross-platform compatibility (in theory, i dont think anyone has tried it
> out yet.)

> DllImport sucks badly if you care about compatibility.  For example, Ive
> just been cleaning up the System.Net.Dns class which tried to DllImport
> from the cygwin1 library.  It also gives you large amounts of pain coping
> with unicode conversions.

It seems to me that you're going to have the complexity either in C functions or
in C# classes, and if it's in C# classes, you can isolate those in a
platform-specific section, if necessary.  (ala IOperatingSystem).  It's not
clear to me why implementing the complexity in the runtime is a better decision
than in C# classes which call the native functions more directly, but that's
okay.

More importantly, are there any objections to me filling in some of the missing
IOperatingSystem methods in Linux.cs -- methods which aren't using file handles
as part of their public interface -- taking the approach that I did in the patch
sent with the last message?  (i.e. Using the Unix wrapper, with any necessary
semantic massaging happening at the C# level).

If not, I'll go ahead and check in that patch.

-- 
Matt Kimball
matt@kimball.net