Hello I am trying socket programming in c++. I need confirmation or say rejection for this logic. I think socket.h header files are designed for UNIX systems whereas for Windows everything is done with winsock.h.
Is this correct?
For windows, you need winsock2.h and ws2tcpip.h.
On Linux, you need sys/socket.h and sys/types.h for the socket functions and netinet/in.h for the IP related structs.
Some other differences:
Windows uses SOCKET for socket descriptors while Linux uses int
Windows has closesocket() to close sockets, while Linux uses close()
On Windows, you need to call WSAStartup() before calling any socket functions, and WSACleanup() when you are done using sockets.
On Linux, you can print errors from socket functions using perror() or strerror(). On Windows, you have to call WSAGetLastError() to get the error code and FormatMessage to get the error text.
Most platforms implement a BSD-compatible socket API, however different platforms do use different .h files to declare their API. So, to answer your question, Yes, Windows uses winsock.h (and winsock2.h), whereas POSIX-based platforms like Unix/Linux use sys/socket.h instead (socket.h is defined as part of the POSIX standard, but Windows is not a POSIX-compatible platform). If you want to write cross-platform code, you have to take this into account. As well as other differences, which #dbush outlined in his answer.
Every header file starting with "sys/..." is designed for UNIX environment. As for windows, they tend to use "win" as a prefix to every header file they use.
If you are interested in windows sockets (winsocks) i guess you should start from here.
As for UNIX sockets, this site seems very interesting and easy going :)
Related
Question is really simple.
I need a tool to convert char* to ip adress and use it in
sockaddr_in.s_addr
arpa/inet.h has inet_addr() function, but I am not sure if I already have this file somewhere in MS VS 2010 installation or should I get it elsewhere.
Win32 provides its own implementation of the sockets API (Winsock) which uses slightly different headers.
From the MSDN for inet_addr:
Header Winsock2.h
arpa/inet.h is the include used on Unix-like systems.
On Windows, you must use winsock2.h.
Example from the MSDN.
I'd like to get the socket and other posix headers and libraries.
How do I get them?
Thanks
Jack
Headers alone won't do you any good. You will need a complete sockets library as well.
Unfortunately, there isn't really a "POSIX socket" library for Windows.
You need to use the WinSock library.
You may find this thread of use too:
Windows posix sockets performance
idevs.h, netinet/in_systm.h, netinet/ip.h, netinet/tcp.h openssl/ssl.h sys/socket.h
These header files can work in Linux but in visual studio 2008 compile error says unable to open header file. These are socket program related headers. (I am unable to get any proper result from web search)
Problem:
Please let me know any dll I have include for these headers or any other equivalent headers are available ?
Thanks in advance.
In windows environment you need to include the windows specific headers like winsock.h and others (http://msdn.microsoft.com/en-us/library/windows/desktop/ms738545(v=vs.85).aspx). You need to switch between headers using the #ifdef statements when doing builds for different platforms.
Nobody ever promised that windows implementation of the sockets concept is 100% identical to the one of Unix. These implementations have a lot in common, but differences are also present.
Sockets are not part of the C++ standard and are implemented in different ways in Linux and Windows. That means, that the native socket libraries are different in both OSes, and Windows has other headers for its socket API than Linux. So you will not only have to include other headers but might also need to use other functions.
Depending on what you want to achieve, you might want to use a library that wraps the OS specific parts and provides a portable interface. There are several more or less portable networking libraries, one of the best known might be Boost.Asio
I was just trying to build netcat in MSYS using MinGW and realized that MinGW never really ported all of the BSD socket stuff to Windows (eg sys/socket.h). I know you can use Windows Sockets in MinGW, but why did they never make a Windows port of the BSD sockets? I noticed quite a few programs using #ifdef's to workaround the issue. Is there a Windows port of the BSD sockets somewhere that can be used instead?
Here are the errors when doing a make for netcat in MSYS:
gcc -DLOCALEDIR=\"\/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c `test -f 'core.c' || echo './'`core.c
In file included from core.c:29:
netcat.h:38:24: sys/socket.h: No such file or directory
netcat.h:39:63: sys/uio.h: No such file or directory
netcat.h:41:24: netinet/in.h: No such file or directory
netcat.h:42:55: arpa/inet.h: No such file or directory
There are no #ifdef's for MinGW. Is there a library/package I can add to MSYS to make everything compile without errors?
Note: You can download netcat here and browse the CVS repo here
BSD sys/socket.h is a POSIX header and the win32 API doesn't support it. MinGW headers are just a reimplementation of native win32 headers and don't offer additional POSIX compatibility.
If you are looking for sys/socket.h support, try either GNU gnulib's sys/socket.h replacement or go with Cygwin, which provides a POSIX compatibility wrapper on Windows.
WinSock and WinSock2 have different function names from the BSD Sockets. If I wish to write cross-platform applications, then I have code a lot of work-arounds just to keep Microsoft happy.
It would be so much easier if there were special "socket.h" and "socket.c" files included with MinGW that simply translated stuff by calling the respective WinSock2 counter-parts.
I'm just starting to learn C programming, so I'm unable to do this myself, but I'm surprised that nobody seems to have even attempted this so far.
These comments from another answer served as the answer I needed to get a piece of simple bsd socket code to compile with mingw on windows.
Replace all of those includes with #include as that would
be the equivalent header for winsock, then see what happens.
You will also need to link against ws2_32 and use
WSAStartup/WSACleanup. Which might get you up and running.
EDIT:
I also ended up having to replace close with shutdown / closesocket and write with send.
The code compiled fine but didn't actually work without those additional changes.
As ChrisW said, Winsock2 is a port of BSD sockets. Which part of winsock are you trying to use which differs from BSD sockets ? (other than the WSAStartup and WSACleanup)
MingWin is minimalist, and that is the most important aspect of it. Because it makes it easier to understand, at the end it is the developer's responsibility to write the application. MingWin only makes things easier but does no magic in turing nix apps to windows.
See the stackoverflow link : Where does one get the "sys/socket.h" header/source file?
The answer/solution is more explicit.
Is there a way to read file names from a folder using purely C (or C++)? That means without including windows.h (no FindFirstFile(), etc...).
It doesn't look like fstream has this functionality. I know that file names are operating system dependent, but I was hoping there is some library that will allow it in Windows.
boost filesystem is a nice solution. Of course under the hood, it will still be using the windows API calls (when you build on windows), but this is abstracted away from you.
C++ typically does not supply you with such functionality. A cross-platform solution is to use boost::filesystem.
Try the POSIX functions opendir() and readdir() for iterating through directories. See this link for the manual page with some great example code. These functions should be available on most platforms, both Windows and UNIX.
If you wish to use opendir() and readdir() on windows, you can download MinGW, a windows port of the famous GNU compiler collection. It includes windows ports of the UNIX header files, including dirent.h, which will allow you to use the specified functions. Keep in mind these will call native API's either way.
-John