Hi, > With this change: http://cvs.openssl.org/chngview?cn=18216 dtls1.h now > includes winsock.h (instead of winsock2.h). This can cause conflicts > with Winsock2 applications that include this header file (that have > already included winsock2.h).
This is a bit misleading and is not really true. What is misleading is to intermix "application" and "including a header file". I mean "winsock2 application" normally refers to "executable what is linked with ws2_32.dll", but it doesn't necessarily have everything to do with inclusion of <winsock2.h> to some specific or several source code files. Or rather including <winsock.h> or failure to include <winsock2.h> somewhere doesn't affect your chances to link with ws2_32.dll. As for untrue part. <windows.h> actually includes even <winsock.h>, or in other words every source file that includes <windows.h> implicitly includes even <winsock.h>(*). So that having both <winsock2.h> and <winsock.h> is not prohibited and kind of common place, because inclusion of <windows.h> is common place. But it has to be done in this specific order, first <winsock2.h> then <windows.h>/<winsock.h>. Meaning that those places that include <winsock2.h> prior <dtls1.h>, i.e. exactly the situation you describe, is not actually a problem. > While there might be some ways of working > around the issue without modifying dtls1.h, I believe dtls1.h should > include winsock2.h, As we already established that including both is not a problem, let's ask ourselves which header would cause least harm? Under assumption that we don't imply which of the two application developer chooses to include, directly or indirectly by way of <windows.h> (probably more common scenario). Given that including windows.h/winsock.h and *then* <winsock2.h> is problematic, we'd have to conclude that <winsock.h> is actually more appropriate [for public header such as <dtls1.h>]. Indeed, consider #include <windows.h> followed by #include <dtls1.h> and vice versa. With <winsock.h> in <dtls.h> both work, while with <winsock2.h> one doesn't. As #include <windows.h> is more likely to be first, it makes more sense to keep <winsock.h>. > since as the OpenSSL documentation says (INSTALL.W32): > > “On additional note newer OpenSSL versions are compiled and linked with > Winsock 2. This means that minimum OS requirement was elevated to NT 4 > and Windows 98 [there is Winsock 2 update for Windows 95 though].” Yes, but it doesn't mean that application itself has to be compiled with winsock2.h and linked with ws2_32.dll, if at all linked with either. Bottom line, case if being dismissed with no need to change resolution. (*) Well, not if you have WIN32_LEAN_AND_MEAN defined, which is defined with OpenSSL itself is built. And it should be noted that application might have to define WIN32_LEAN_AND_MEAN in order to avoid conflict *if* it includes *another* OpenSSL header file. But this doesn't change the fact that including both <winsock2.h> and <winsock.h>, in this order, is not actually a problem. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
