#176 winsock2.h vs winsock.h conflict

WSL
closed
None
wont-fix
Known_bugs
2014-08-13
2002-08-17
No

I ran into this compiling OpenSSL 0.9.6g.
winsock2.h gets included automatically with windows.h,
which blocks any subsequent inclusion of winsock.h.
OpenSSL 0.9.6g seems to make use of winsock 1.1
API. Although it includes winsock.h,
WSACancelBlockingCall() prototype is not imported and
link will fail because wrong calling convention is chosen.
As a simple fix, please activate section of winsock2.h
which includes these Winsock 1.1 functions (like
WSACancelBlockingCall() ) and is disabled using #if 0
so that code that uses it will compile...

Discussion

  • Danny Smith

    Danny Smith - 2002-08-17

    Logged In: YES
    user_id=11494

    A simpler and safer fix if you want to use the
    winsock1.1 interface is to include winsock.h before
    windows.h. This will block inclusion of winsock2.h

    Some of the defines in winsock2.h are incompatable
    with functions exported from wsock32.dll (and similarly
    there are proplems including winsock.h and linking in
    ws2_32.dll before wsock32.dll).

    The documentation for WSACancelBlockingCall at

    http://msdn.microsoft.com/library/default.asp?
    url=/library/en-us/winsock/wsapiref_704y.asp

    is very explicit in the deprecation of that function for
    winsock2 interface

    Danny

     
  • Danny Smith

    Danny Smith - 2002-08-17

    Logged In: YES
    user_id=11494

    Hmm, well maybe I was being a bit too protective. The
    pseudo-blocking functions are deprecated but they are
    available throught ws2_32.dll (another doc i had read
    earlier said they were notavailable _directly_ from
    ws2_32.dll. However, the names certainly are
    exported). Unless, I hear an objection I'll remove the
    #if 0 and correct the comment.

    GCC3.x has a new attribute __attibute__((deprecated))
    that warns about obsolete functions. But I can already
    hear the screams from failing configure scripts that
    don't like warnings.

    Danny
    Danny

     
  • Jan Hlavatý

    Jan Hlavatý - 2002-08-17

    Logged In: YES
    user_id=94016

    Yes, but that will require changing source that works
    otherwise.
    Why would you make it different from what Microsoft headers
    do? Programs that compile with MSVC will not compile under
    MING32!
    Microsoft's windows.h includes winsock.h, not winsock2.h by
    default, and apps inlcude winsock2.h only when they need it.
    I think it should be made so that win32api behaves similarly
    to MS headers for maximum compatibility.

     
  • Jan Hlavatý

    Jan Hlavatý - 2002-08-17

    Logged In: YES
    user_id=94016

    That is, winsock2.h should be included _before_ windows.h,
    not winsock.h on apps that use winsock2 API.

     
  • Danny Smith

    Danny Smith - 2002-08-17

    Logged In: YES
    user_id=11494

    The reason that winsock2.h is default inclusion by
    windows.h is because of infomation from MSDN info

    Q124876 - INFO Sockets Applications on Microsoft
    Windows Platforms
    and

    Q257460 - INFO Header and Library Requirement When
    Set-Get Socket Options at the IPPROTO_IP Level

    (sorry I don;t have uptodate links).

    Also if you look at MSDN docs on winsock functions,
    they refer almost exclusively to winsock2.h and
    ws2_32.lib.

    At one stage, MS versions of windows.h included
    winsock2.h by default on anything higher than Win95.
    Maybe that has changed.

    I'll remove the #if 0 from the pseudo-blocking
    functions in winsock2.h, but I am not convinced about
    making a deprecated interface the default.

    Danny

     
  • Earnie Boyd

    Earnie Boyd - 2002-11-25
    • status: open --> closed-wont-fix
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-22
    • labels: w32api (deprecated use WSL) -->
    • status: closed-wont-fix --> closed
    • resolution: --> wont-fix
    • category: --> Known_bugs
    • milestone: --> WSL
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks