This is a discussion on Re: Cross compile OpenSSL in Linux using MinGW32 - Openssl ; >> 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 >> ...
>> 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
>> 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
> 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 email@example.com
Automated List Manager firstname.lastname@example.org