Hi,
Post by Noszticzius, Istvan via RTWith 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.
Post by Noszticzius, Istvan via RTWhile 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>.
Post by Noszticzius, Istvan via RT“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-***@openssl.org
Automated List Manager ***@openssl.org