From: <no...@so...> - 2002-08-17 07:22:17
|
Bugs item #596369, was opened at 2002-08-17 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-08-17 09:30:49
|
Bugs item #596369, was opened at 2002-08-17 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2002-08-17 21:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-08-17 10:36:27
|
Bugs item #596369, was opened at 2002-08-17 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2002-08-17 22:36 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 21:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-08-17 15:34:13
|
Bugs item #596369, was opened at 2002-08-17 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- >Comment By: Jan Hlavatý (hlavac) Date: 2002-08-17 17:34 Message: 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. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 12:36 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 11:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-08-17 15:48:35
|
Bugs item #596369, was opened at 2002-08-17 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- >Comment By: Jan Hlavatý (hlavac) Date: 2002-08-17 17:48 Message: 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. ---------------------------------------------------------------------- Comment By: Jan Hlavatý (hlavac) Date: 2002-08-17 17:34 Message: 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. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 12:36 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 11:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-08-17 22:51:17
|
Bugs item #596369, was opened at 2002-08-17 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2002-08-18 10:51 Message: 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 ---------------------------------------------------------------------- Comment By: Jan Hlavatý (hlavac) Date: 2002-08-18 03:48 Message: 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. ---------------------------------------------------------------------- Comment By: Jan Hlavatý (hlavac) Date: 2002-08-18 03:34 Message: 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. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 22:36 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 21:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |
From: <no...@so...> - 2002-11-25 21:23:02
|
Bugs item #596369, was opened at 2002-08-17 03:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 Category: w32api Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jan Hlavatý (hlavac) Assigned to: Earnie Boyd (earnie) Summary: winsock2.h vs winsock.h conflict Initial Comment: 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... ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 18:51 Message: 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 ---------------------------------------------------------------------- Comment By: Jan Hlavatý (hlavac) Date: 2002-08-17 11:48 Message: 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. ---------------------------------------------------------------------- Comment By: Jan Hlavatý (hlavac) Date: 2002-08-17 11:34 Message: 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. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 06:36 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-08-17 05:30 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=596369&group_id=2435 |