>> Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
>> was to target all NT versions [note that 0x333 actually covers even for
>> Windows 9x, which has at least all 0x333 stubs, so that application can
>> actually start]. As for winsock versioning. Upon latest modifications to
>> b_sock.c I considered linking with wsock32 to be sufficient/appropriate
>> for following reason. Systems equipped with ws2_32.dll do have wsock32
>> too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning
>> that [legacy] application linked with wsock32 alone will actually bring
>> even ws2_32.dll into address space. Now note that b_sock.c makes
>> *global* lookups for getaddrinfo, meaning that application linked with
>> wsock32 alone will actually find getaddrinfo even if it resides in
>> ws2_32! So that the fact that latest headers [those defining struct

>
> This is a very thin ice approach. When you use wsock32, it's using
> Winsock 1.1. There are incompatibilities between Winsock 1.1 and
> Winsock 2, which are solved by using different header files. Including
> winsock.h and winsock2.h concurrently is wrong. It's also wrong to
> include winsock.h when linking against ws2_32.dll and it's wrong to
> include winsock2.h when linking against wsock32.dll.
>
> For instance, several socket options have different values. As an
> example, IP_TOS is defined as the value 3 under Winsock 2, but it was
> defined as the value 8 under Winsock 1.1.


Yes, it *is* thin ice approach, which is why I said that it requires
*discipline*. The kind of discipline that requires you to explicitly
verify that common structures and constants _actually used_ in your code
are the same in old and new headers. But this was actually *done* for
b_sock.c, which is why I *dared* to include new header and link old
library. I mean it's admittedly daring, but it's not groundless in this
particular case:-)

>> addrinfo] are included, but elder library is linked with is actually
>> intentional. Yes, it requires certain programming discipline, but it's
>> [considered] doable. As for IPv6. If w2k supports it only through
>> additional library, I'd say "is it really a problem not to have IPv6 on
>> pre-XP?"

>
> Seriously, I'd consider Winsock 1.1 as the one which should be left
> behind, rather than Windows 2000 users.


Windows 2000 users are not left behind, IPv6 on 2000 would be. I don't
see it as bigger problem (anybody running IPv6 on 2000 raise your
hands), but anyway...

> As I said in another mail,
> Winsock 2 is by default available since Windows 95 OSR2 and NT4.


Keep in mind 0x333, it's 3.51. If we switch to ws2_32, I'd insist on
bumping _WIN_WIN32 to 0x400. Shall we do that? I personally have no
objections to that.

> It's really not that hard. Always use ws2_32.dll instead of wsock32.dll,
> never include winsock.h and, last but not least, if loading getaddrinfo/
> freeaddrinfo from ws2_32.dll fails, try again by loading it from
> wship6.dll. If that fails, IPv6 is not available. However, I'm not
> sure if the DSO_global_lookup approach also covers wship6.dll
> automatically on W2K. Somebody would have to try it.


DSO_global_lookup looks only through currently loaded dlls, and never
attempts to load any new. On bright side one can simply throw in
LoadLibrary("wship6.dll") literally anywhere, e.g. next to WSAStartup. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org