From: SourceForge.net <no...@so...> - 2006-02-08 12:49:09
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3564878 By: earnie Replace #include <winsock2.h> with #define __USE_W32_SOCKETS 1 #include <windows.h> Per Microsoft's documentation you are not supposed to include the Windows API parts directly. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-08 16:51:43
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3565306 By: chris_a_thomas really? I've never seen that method before, if you don't mind and please don't take it the wrong way, can you show me where it says to do this? I've seen examples from microsoft which include winsock2.h? so I'm a little confused as to when this method arose, perhaps it's a recent idea? thanks mate! chris ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2006-02-13 19:39:28
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3573787 By: chris_a_thomas earnie, I've read the messages on the mailing list and I would like to ask again if you have any information where you saw the statements or information where it says you shouldnt include winsock2 directly. I've searched google for hours and I can't find a thing, plus I can't find anything at MSDN for USE_W32_SOCKETS (omitting the front __ because sometimes it's _ or __, without it, it'll find any occurance) and well, I'm at a loss to find where you found this information. Also, the makeword macro is of course, rightly included anyway, so that gets thrown away, I'm still left with the WINSOCK_VERSION macro. I've followed the mailing list debate, I think since you are providing a winsock2 api, you should provide what microsoft provides, hence, that macro should exist for compatibility reasons with microsoft, so you dont have to go altering boiler plate winsock2 code to compile on mingw. Even if the macro is seen as a bad idea, it's three lines of bad idea, and it eliminates some headaches. if you are in the position to change this, you should add the macro and just be done with it as for the discussion of my eclipse environment, that shouldnt concern you, since this error occurs regardless of eclipse, if I run from the cmd.exe, I get the same problem and it's fixed in the same way, so eclipse isnt the problem here. as for problems with my install, I'll have a look and find out for sure which header file is being included from where and hopefully, it'll resolve itself ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: Michael G. <mg...@te...> - 2006-02-13 20:41:36
|
> as for the discussion of my eclipse environment, that shouldnt concern yo= u, > since this error occurs regardless of eclipse, if I run from the cmd.exe,= I > get the same problem and it's fixed in the same way, so eclipse isnt the = problem > here. I very well remember that I wrote that I don't have this problem when I do compile and run your code from the commandline which kind of proves your above claim wrong. I also said I _suspect_ your eclipse environment. Since I don't know your environment and so far you haven't provided any information as to which versions of the various components you are using. > as for problems with my install, I'll have a look and find out for sure w= hich > header file is being included from where and hopefully, it'll resolve its= elf Knowing the problem does not exist in a clean installation I *KNOW* there has to be something wrong with your environment, be it Eclipse or the way you installed the stuff or whatever. Also you wrote that your changing of the header files you think are what is included does not change anything kind of proves that the headerfiles you think are included in fact are not. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Earnie B. <ea...@us...> - 2006-02-13 23:32:36
|
Quoting "SourceForge.net" <no...@so...>: > > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=3573787 > By: chris_a_thomas > > earnie, > > I've read the messages on the mailing list and I would like to ask again if > you have any information where you saw the statements or information where it > says you shouldnt include winsock2 directly. I've searched google for hours > and I can't find a thing, plus I can't find anything at MSDN for > USE_W32_SOCKETS > (omitting the front __ because sometimes it's _ or __, without it, it'll find > any occurance) and well, I'm at a loss to find where you found this > information. > The one thing you can depend on MSDN for is changing its documentation. :) The only reference I can find that remotely suggests including windows.h is a must is http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarw98bk/html/thewindowshheaderfile.asp Watch out for the line wrapping. I can't find a reference to __USE_W32_SOCKETS either. I wonder where it came from originally? And __USE_W32_SOCKETS replaced Win32_Winsock which I can't find references for either. > Also, the makeword macro is of course, rightly included anyway, so that gets > thrown away, I'm still left with the WINSOCK_VERSION macro. I've > followed the > mailing list debate, I think since you are providing a winsock2 api, > you should > provide what microsoft provides, hence, that macro should exist for > compatibility > reasons with microsoft, so you dont have to go altering boiler plate winsock2 > code to compile on mingw. Even if the macro is seen as a bad idea, > it's three > lines of bad idea, and it eliminates some headaches. > I can only use available documentation to determine what to provide. Looking at the CVS code winsock2.h already includes windows.h. I don't find a reference to WINSOCK_VERSION on MSDN. Feel free to submit a patch to define it. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Earnie B. <ea...@us...> - 2006-02-13 23:56:28
|
Quoting Earnie Boyd <ea...@us...>: > > I can only use available documentation to determine what to provide. > Looking at the CVS code winsock2.h already includes windows.h. I > don't find a reference to WINSOCK_VERSION on MSDN. Feel free to > submit a patch to define it. > > On second thought, the code samples I find all define WINSOCK_VERSION or winsock_version using MAKEWORD within the code. E.G.: http://www.nevrax.org/docs/doxygen/nel/de/d92/sock_8cpp-source.html Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |