Solaris winsock support

[Francois Gouget]

On Sat, 8 Sep 2001, Robert Lunnon wrote:
[...]
> need. Studying the ifconfig source gives another possibility instead which 
> look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP 
> socket
[...]
> Questions
> Anyone know if this is Is this workable ?
> Is this workable on linux, (I ask because I don't have linux and don't know 
> linux ioctl implementation details)?

   It's probably workable. Especially since WsControl already uses a
number of similar ioctls (SIOCGIFHWADDR, SIOCGIFADDR, ...). But I think
we should keep the /proc code around on Linux (though in the worst case
we could still get it from CVS). I believe that Linus does not like
ioctl's so I would not be surprised if they were to disappear one day...

   Anyway, there is something else that would be great.
   I see very similar code in WsControl in dlls/wsock32 and in WSAIoctl
in dlls/winsock:
 * WSCNTL_GetInterfaceName and WSAIOCTL_GetInterfaceName are very
copy/paste alike
 * same for WSCNTL_GetEntryCount and WSAIOCTL_GetInterfaceCount
 * WsControl's IP_MIB_ADDRTABLE_ENTRY_ID and WSAIoctl's
SIO_GET_INTERFACE_LIST seem to do very similar things

   So the idea would be to try to implement WsControl by making
appropriate calls to WSAIoctl. This would have the following benefits:
 * reduced code duplication (especially such non portable code)
 * it would greatly help me in my winsock header rewrite
 * which would lead to much cleaner code (removal of the socket hack)

   More about this header rewrite. The problem I have is that wsock32
uses both the Unix socket calls (in WsControl for SIOCGIFHWADDR and
friends), which means I must include the Unix socket headers, and
Winsock specific macros and types, which means I must include the
winsock headers. Now, since the new winsock headers don't simply
#include the Unix ones to get their stuff this generates conflicts. For
instance the Unix bind is cdecl while the one in winsock is stdcall. The
current trick is to force the prefixing of all things Winsock with WS_
to avoid conflicts. But then calling from wsock32 to ws2_32 becomes not
very practical.
   I solved it for now using very ugly hacks. But the clean solution is
to not use the Unix stuff at all in wsock32. And I believe the only
obstacle to that is the current implementation of WsControl.




--
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
                           La terre est une bêta...