Winsock API

[Robert Lunnon]

I have Converted WSAIOCTL to use SIOCGETIFCONF ioctl calls rather than parse 
/proc which is to linux-centric but I was asked by  Francois Gouget to look 
at trying to make WsControl unix independent by implementing it using other 
windows APIs rather than by using unix calls directly.

Unfortunately this API is a bit of a mess because WsControl can return the 
MAC Adress but WSAIoctl doesn't appear to implement that functionality. To 
get The MAC Address we then need to make an appropriate UNIX IOCTL call for 
which we need the interface name, which isn't available from WSAIoctl either. 
There are other ways in windows to getthe MAC address via an SNMP call but 
I'm not sure how that is implemented (Possibly with a call back to WSControl)

I don't see then how WSControl can be implemented without the present hacks 
and duplicated code between WSAIoclt and WSControl helper functions.

My proposal then would be...

1.)
Separate out all the unix centric helper functions for WSControl and WSAIoctl 
into a common ancestor source file with no windows dependencies. This should 
remove the ugly socket hack in WSControl, both libraries still end up with 
private copies of the common helper functions but since they are all derived 
from the same common source file it will at least be encapsulated and easier 
to maintain.

2.)
The doco for WSIoctl indicate the encoding for  the Ioctl op-code allows for 
a "Standard" unix IOCTL to be passed to WSIoctl ostensibly for 
FIONREAD,FIONBIO et al, with predictable results. If I were to implement 
SIOCGETIFCONF in WsIoctl then this would allow a pass-through so I could get 
what I need from the host OS without disturbing current windows programs. 
Because windows doesn't define SIOCGETIFCONF whatever we choose for the value 
of the op-code might end up being used by Microsoft later, breaking Wine. 
(Possible but not very likely)

 
Opinions ?