[Mono-list] Multiplatform DllImport?

[Christian Ratliff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miguel,

  Hmm. It still sounds like there are two possible mechanisms: 
implement wrappers in mono/mono/wrapper/wrapper.c OR implement direct
DLL imports into two different .cs source files. For the
System.Net.Socket.Sockets class the variance between Win32 and Unix
is great enough that the latter seems like the more appropriate
solution.
  If, however, the former were the more appropriate, how would I gain
DllImport access to the wrappers? Say, if I wrote
"mono_wrapper_setsockopt", how would I import that into my class?

  [DllImport("monowrapper", EntryPOint="mono_wrapper_setsockopt")];

  Sorry to be so thick about this!

Thanks again,
christian

+-----+
Christian Ratliff <cratliff@lily.org>
lily Development Group
"This is the very perfection of man, 
  to find out his own imperfections" -  St. Augustine


- -----Original Message-----
From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]
On Behalf Of Miguel de Icaza
Sent: Friday, November 23, 2001 5:25 PM
To: Christian Ratliff; sean@ximian.com
Cc: mono-list@ximian.com
Subject: Re: [Mono-list] Multiplatform DllImport?


>   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.

_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBO/7RE7ZBtyfwMNgGEQK4HQCdGOson3JHTBApisdTSQcmnF6514QAnA1g
Yb2jmWgrjeide6L3XijrrOSE
=mNBR
-----END PGP SIGNATURE-----