Re: [xml] wsdks + winsock behaviours

Hash: SHA1

On 31.03.2013 19:56, Roumen Petrov wrote:
LRN wrote:
result: CHAOS
May be . Based on my past experience to work with second version of
 windows socket program code should use: a) --- #define
WIN32_LEAN_AND_MEAN #include <windows.h> #include <winsock2.h> --- 
b) --- #include <winsock2.h> #include <windows.h> --- and later to
call socket startup/cleanup in "main" application method.
I prefer (b). Actually, i prefer ws2tcpip.h (it has some extra
definitions useful for apps that need rich network functionality).
ws2tcpip.h includes winsock2.h automatically. Anyway, not the point.

1) for MS PSDK 7 it does  practically nothing (unless it's MAC,
in which case it produces "_WINSOCKAPI_ redefined" warning)
So may be this has to be investigated further as libxml code use
this macro to call winsock specific methods. If is not defined in
some cases this is issue.
Well, my statement above is theoretical. This is the limit of my
ability, as i have a copy of PSDK to look at, but i'm not going to run
MSVS to compile libxml with it.

If someone here uses MSVS or non-MSVS-driven VC, please speak up.

2) for w32api it does  nothing ( doesn't use 
_WINSOCKAPI_ macro at all)
This is fine with me as libxml code use this definition.
Yes, i've noticed that libxml uses _WINSOCKAPI_ as an indicator of
winsockiness of the library. You might want to choose something else.

3) for mingw-w64 it produces a  warning "please include
<winsock2.h> before <windows.h>"
This is not expected. Please detail.
mingw-w64 winsock2.h has this code at the top:

#ifndef _WINSOCKAPI_
#define _WINSOCKAPI_
#warning Please include winsock2.h before windows.h

and winsock.h uses _WINSOCKAPI_ as its include guard.

winsock2.h defines _WINSOCKAPI_ to prevent winsock.h from being
included (because you can't have both at the same time).

If _WINSOCKAPI_ is already defined by the time winsock2.h is included,
it means that either winsock.h defined it and was processed, or that
something else defined _WINSOCKAPI_ (which is the case with libxml).

AFAIU, libxml defines it to prevent winsock.h from being processed, in
case it includes it by accident, before winsock2.h is included. It
didn't affect, and doesn't affect MS PSDK [anymore], and
produces a warning when used with mingw-w64. So i'd say that it's not
as effective as originally intended.

Build with w32 api show that winsock2.h is included
before windows.h (based on nanohttp.c): ... # 1590
"/opt/mingw46/include/zlib.h" # 1 "./include/wsockcompat.h" 1 # 12
"./include/wsockcompat.h" # 1 "[HEADERPATH]/include/winsock2.h" 1
3 # 17 "[HEADERPATH]/include/winsock2.h" 3 # 18
"[HEADERPATH]/include/winsock2.h" 3 # 1
"[HEADERPATH]/include/windows.h" 1 3 # 16
"[HEADERPATH]/include/windows.h" 3 # 17
"[HEADERPATH]/include/windows.h" 3 # 47
"[HEADERPATH]/include/windows.h" 3 # 1
"[GCCHEADERPATH]/include/stdarg.h" 1 3 4 # 102
"[GCCHEADERPATH]/include/stdarg.h" 3 4 # 48
"[HEADERPATH]/include/windows.h" 2 3 ... is set up to include winsock2.h for WINVER >= 0x400 - which
means practically always (unless you're compiling for Windows 9x). So
yes, with there's no winsock2 vs winsock infighting, unless
you're stupid enough to include winsock.h yourself.

I'd prefer to see libxml code fixed to include winsock2.h before
windows.h. If checking the code and moving includes around is
something no one wants to do, then CFLAGS+="-include winsock2.h" will
help (and, obviously, all #define _WINSOCKAPI_ will have to go, or be
put under #ifdef !defined(__MINGW64_VERSION_MAJOR))

I could also try speaking with mingw-w64 devs and having them do
something similar (i.e. don't include winsock.h from windows.h).

Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]