From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert A. Mackie" To: Mumit Khan Cc: cygwin@sourceware.cygnus.com Subject: Re: posix style DGRAM sockets with cygwin.dll Date: Wed, 25 Aug 1999 14:39:00 -0000 Message-id: <37C4633C.F64DC8D4@mail.com> References: <199908250127.UAA28632@mercury.xraylith.wisc.edu> X-SW-Source: 1999-08/msg00698.html Mumit, Thank you for looking. I'm sorry this I asked for your time on what turned out to be a code inspection issue rather than a cygwin issue. Since the unix system on which it ran correctly uses network order for memory, the code worked there, inspite of my error. I should have been more vigilent. Rob. PS: I'm very impressed with the value of cygwin. I should free up from my most urgent deadlines in the next month or so. I plan to volunteer some effort to help support cygwin at that point. What a convenient set of tools and library. Mumit Khan wrote: > "Robert A. Mackie" writes: > > > > I'm trying to get a very simple UDP example ported to cygwin as a > > starting point for some real code I expect to develop. Everything > > compiles and links, but the sockets don't communicate. When built for > > unix the same code works fine. (unless I've introduced some small bug > > trying to get it to work under cygwin.) I notice I'm not the first to > > say something like this. The last person was using the -no-cygwin > > option and was told to call WSAStartup. I read as much documentation as > > I could find. It looked to me like that was not necessary when using > > the posix calls, rather than the winsock calls. (Maybe I'm wrong ?) > > If you're using -mno-cygwin, you're using Windows sockets (and you need > WSAStartup); if you're *not* using -mno-cygwin, you're using POSIX sockets > and obviously don't need the windows hacks, er features. > > > If I do need to initialize winsock explicitly, could you help me with a > > couple of details? The only place that I see WSAStartup and WSACleanup > > defined is in . This file seems to be set up for > > an MSC compiler, and includes a bunch of other similar headers. When I > > include any of them and the standard headers I'm used to, I get all > > sorts of re-definition collisions between the headers. When I include > > them without the standard headers, things like strerror aren't defined. > > You include winsock.h, not the internal headers, but *only* if you're using > Windows sockets. If you're using Cygwin runtime, use the POSIX specs and > forget about the windows headers (Cygwin runtime will do the right thing). > > It's quite unclear from your message what runtime you're trying to use > and so on. If you could elaborate, we could try to help. > > As far as your code is concerned, there is at least one blatant bug I > see right away -- > > server_address.sin_port = htonl(SERVER_UDP_PORT); > ^^^^^ (should be htons) > > likewise in the other case. Just remember that sin_addr is htonl and > sin_port is htons and life would be a lot easier. > > Perhaps you ought to check over your code a bit more and try again. > > Regards, > Mumit From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert A. Mackie" To: Mumit Khan Cc: cygwin@sourceware.cygnus.com Subject: Re: posix style DGRAM sockets with cygwin.dll Date: Tue, 31 Aug 1999 23:49:00 -0000 Message-ID: <37C4633C.F64DC8D4@mail.com> References: <199908250127.UAA28632@mercury.xraylith.wisc.edu> X-SW-Source: 1999-08n/msg00698.html Message-ID: <19990831234900.VRpIMH8ETOan7vw-i15FxvSnUoJM45IJq-EByLzsZZM@z> Mumit, Thank you for looking. I'm sorry this I asked for your time on what turned out to be a code inspection issue rather than a cygwin issue. Since the unix system on which it ran correctly uses network order for memory, the code worked there, inspite of my error. I should have been more vigilent. Rob. PS: I'm very impressed with the value of cygwin. I should free up from my most urgent deadlines in the next month or so. I plan to volunteer some effort to help support cygwin at that point. What a convenient set of tools and library. Mumit Khan wrote: > "Robert A. Mackie" writes: > > > > I'm trying to get a very simple UDP example ported to cygwin as a > > starting point for some real code I expect to develop. Everything > > compiles and links, but the sockets don't communicate. When built for > > unix the same code works fine. (unless I've introduced some small bug > > trying to get it to work under cygwin.) I notice I'm not the first to > > say something like this. The last person was using the -no-cygwin > > option and was told to call WSAStartup. I read as much documentation as > > I could find. It looked to me like that was not necessary when using > > the posix calls, rather than the winsock calls. (Maybe I'm wrong ?) > > If you're using -mno-cygwin, you're using Windows sockets (and you need > WSAStartup); if you're *not* using -mno-cygwin, you're using POSIX sockets > and obviously don't need the windows hacks, er features. > > > If I do need to initialize winsock explicitly, could you help me with a > > couple of details? The only place that I see WSAStartup and WSACleanup > > defined is in . This file seems to be set up for > > an MSC compiler, and includes a bunch of other similar headers. When I > > include any of them and the standard headers I'm used to, I get all > > sorts of re-definition collisions between the headers. When I include > > them without the standard headers, things like strerror aren't defined. > > You include winsock.h, not the internal headers, but *only* if you're using > Windows sockets. If you're using Cygwin runtime, use the POSIX specs and > forget about the windows headers (Cygwin runtime will do the right thing). > > It's quite unclear from your message what runtime you're trying to use > and so on. If you could elaborate, we could try to help. > > As far as your code is concerned, there is at least one blatant bug I > see right away -- > > server_address.sin_port = htonl(SERVER_UDP_PORT); > ^^^^^ (should be htons) > > likewise in the other case. Just remember that sin_addr is htonl and > sin_port is htons and life would be a lot easier. > > Perhaps you ought to check over your code a bit more and try again. > > Regards, > Mumit