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 [EMAIL PROTECTED]
