[Mono-list] Multiplatform DllImport?

[Miguel de Icaza]

>   How are we supposed to be dealing with classes which offer platform
> services (e.g. System.Net.Sockets.Socket)? This class will need to
> import not only things like socket, bind, listen, connect, but also
> Win32 (Winsock) functions like WSAStartup and WSACleanup. I hate to
> ask before looking so...

At least on the Unix side of things we should be doing that using the
wrapper code in mono/mono/wrapper and maybe also for Windows
compatibility (this makes sure that enumeration constants from the
underlying OS are mapped correctly). 

> I looked for some other example in the code base, and the latest
> snapshot contains mcs/class/System/System.Net/Dns.cs. That file has a
> DllImport which explicitly mentions the cygwin DLL as the source for
> gethostbyaddr and gethostbyname. Is this the right way?

No, that is actually wrong.  

That file probably should be called Dns-posix.cs and we should not try
to bind directly to the cygwin.dll.  Cygwin is only being used to
'build' Mono, but we should not depend on it for the runtime.

That being said, cygwin is useful to test in Windows how things are
going to be in the Unix world.  That is why I think that we should
rename Dns.cs to Dns-posix.cs and later on rename the references to be
to libc instead of cygwin.

> Meanwhile, there is a file called mcs/class/corlib/Windows/Windows.cs
> which implements System.PAL.OpSys. This file contains DllImports for
> many common math library functions. The Linux version
> (mcs/class/corlib/Linux/Linux.cs) contains only stubs, no real
> imports. Is this the right way?

The idea originally was to have an `IOperatingSystem' interface, and
dynamically choose which OS you are running on.  But this seems
overkill, instead what we are going to do is just compile-in different
sources files depending on the target.

So you can still implement the various functions in Unix.cs (it should
be Unix.cs also) and the "target" decides which files are compiled in.


>   Suffice it to say that I am confused about how this is to be
> managed.

Yes, I wish we could clean this up and not leave the old files lying
around.  Also, as soon as we have done some of the core work on the
runtime and the compiler, the team at Ximian will be able to devote more
time to polish those bits of the infrastructure.

Miguel.