> >	// load function as well
> >}
> >
> >and then replace select() with select_func().
>  Why select()?  I thought the problem was with socket().
Oh, i missed "e.g." before "select()". I meant all winsock functions 
should be replaced with indirection and call.

>  Anyway, if we had code like the above, what does it do on a Win95 system 
>  without Winsock2?  I see that it loads Winsock1 instead, but then what?  
>  Is it able to locate an IFS-compatible provider like your Winsock2 code 
>  does, or does this Winsock1 fallback case still suffer the problem 
>  described in your original bug report?
Winsock1 does not support LSPs and thus it's safe to simply call 
socket() when Winsock2 is unavailable.

>  If the Winsock1 fallback code can locate an IFS-compatible provider, and 
>  thus fix the original bug, then what I was suggesting is that such 
>  Winsock 1 code should be used for all systems.  There would be no need 
>  to try loading Winsock2 first.
The problem is - even if one uses Winsock1 on Winsock2-capable system, 
Winsock1 will be simply routed into Winsock2. E.g. socket() may end up 
in non-IFS provider, triggering the bug. Therefore, only two approaches 
are available:
- provide fix for winsock2 and fallback code for winsock1;
- provide fix for winsock2 and require winsock2 (current patch does that).

>  If, however, the Winsock1 fallback code still suffers the original 
>  problem (i.e. only Winsock2 can fix it, and the fallback is just there 
>  so as not to completely break Win95) then I think that just switching to 
>  a Winsock2 requirement would be better.  It's free and easy to install, 
>  so shouldn't be a problem for the (hopefully few) users that would be 
>  affected.
Yes, switching to Winsock2 completely is much simplier. I will modify 
patch taking your notes from below into account and then attach it to 
bugreport. Tomorrow, probably. It's Friday evening already ;-)

>  1.  The loading of <ws2spi.h> in win32sck.c should probably be moved to 
>  win32/include/sys/socket.h, where it can replace the now redundant 
>  loading of <winsock.h>.
>  
>  2.  win32/makefile.mk needs patching too -- the same DELAYLOAD and 
>  LIBBASEFILES macros as were edited in win32/Makefile, and also a 
>  LIBFILES macro used by MinGW/GCC.  I don't know what (if anything) needs 
>  changing for BCC, though.

Regards,
Artiom