[Mono-list] Why InternalCall rather than DllImport?
Wed, 09 Jan 2002 10:42:28 -0800 (PST)
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
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.