Porting C network programs from Unix to Windows 9x/NT/2k/XP/ME

Porting C network programs from Unix to Windows 9x/NT/2k/XP/ME

Post by William Umb » Tue, 06 Nov 2001 22:40:18



Are there any issues I have to consider when porting network programs
written in C for Unix to the various Windows platforms? Besides system
functions like fork(), do I have to look out for anything else when
porting programs using sockets on Unix to Windows using winsock?
Thanks.
 
 
 

Porting C network programs from Unix to Windows 9x/NT/2k/XP/ME

Post by Chuck Dillo » Tue, 06 Nov 2001 23:48:44



> Are there any issues I have to consider when porting network programs
> written in C for Unix to the various Windows platforms? Besides system
> functions like fork(), do I have to look out for anything else when
> porting programs using sockets on Unix to Windows using winsock?
> Thanks.

I went through this exercise recently.  Here is a summary of my #ifdef _WIN32
clauses...

#ifdef _WIN32
#include <winsock.h>
#include <io.h>
#include <fcntl.h>
#else
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#define closesocket  close
#endif

#ifndef _WIN32
#include <signal.h>
#endif

#ifndef _WIN32
typedef int SOCKET;  /* the win32 calls return a SOCKET */
#endif

#ifndef _WIN32
    sigignore(SIGPIPE);
#endif

#ifdef _WIN32
  { /* we have to make this call to init winsocks */
    WORD wVersionRequested;
    WSADATA wsaData;
    int err;
    wVersionRequested = MAKEWORD( 2, 2 );
    err = WSAStartup( wVersionRequested, &wsaData );
    if ( err != 0 ) return(err);
  }
#endif

// This one wasn't easy to dig out of the doc
#ifdef _WIN32
  { /* tells windoze we want synchronous socket communications */
    int optInt = SO_SYNCHRONOUS_NONALERT;
    if (setsockopt(INVALID_SOCKET, SOL_SOCKET, SO_OPENTYPE,
                   (char *)&optInt, sizeof(optInt))) perror(errno);
  }
#endif

// in windoze a socket is not an fd so if you plan to use read/write you have
to
// create an associated fd.  if your code uses send/recv can use the SOCKET
itself.
// rawsock is a SOCKET, wpd->sock is an int.
#ifdef _WIN32
  wpd->sock=_open_osfhandle(rawsock,O_RDWR|O_BINARY);
#else
  wpd->sock=rawsock;
#endif

// you have to explicitly cleanup winsocks when you are finished
#ifdef _WIN32
  WSACleanup();
#endif

--
Chuck Dillon
Senior Software Engineer
Accelrys Inc., a subsidiary of Pharmacopeia, Inc.

 
 
 

Porting C network programs from Unix to Windows 9x/NT/2k/XP/ME

Post by William Umb » Sat, 10 Nov 2001 23:31:20


Thanks Chuck. It was helpful
 
 
 

Porting C network programs from Unix to Windows 9x/NT/2k/XP/ME

Post by Jonathan de Boyne Pollar » Tue, 13 Nov 2001 02:13:46


CD> // in windoze a socket is not an fd so if you plan to use
CD> // read/write you have to create an associated fd.
CD> [...]
CD> #ifdef _WIN32
CD>   wpd->sock=_open_osfhandle(rawsock,O_RDWR|O_BINARY);
CD> #else

Your explanation in the comment is incorrect.  It should read:

-----------------------------------------------------------------
On Windows NT, a socket handle is a real Win32 handle.  But the Win32 handle
space is disjoint from the handle space used by the DOS system API[*]
functions provided in the runtime library, such as open(), close(), read(),
and write().  To use these DOS system API functions, one must first create a
DOS system API file handle that maps to the Win32 file handle, using
_open_osfhandle().

On DOS-Windows, a socket handle is not a real Win32 handle, and this code will
not work, because _open_osfhandle() requires a real Win32 handle.  Socket
handles on DOS-Windows are in a handle space all of their own, and only recv()
and send() can be used for performing I/O.
-----------------------------------------------------------------

[*] These functions, which are supplied in the runtime libraries of most C/C++
implementations for Win32, may look like the C language bindings to the POSIX
system API.  But in fact they aren't.  These functions are the C language
bindings to the _DOS_ system API.  (Win32 C/C++ implementations have inherited
them from DOS C/C++ implementations.) The DOS system API resembles the POSIX
system API on a dark night.

 
 
 

1. RH 8 client on a Windows NT/2K network

Our company currently has a Windows NT 4 based network (using
encrypted passwords).  I'm looking to integrate a Redhat 8 workstation
into this network so that the login/password can be validated against
the domain server, and the workstation can have access to its files on
file servers.

There's already a Windows lan ID and password set up, and I've created
a user account on the RH box that has the same login/pw.  Using samba
I've been able to connect to public folders and do directory lists,
but when I try to browse restricted folders that my lan ID has access
to, I get empty directory listings.  So:

a) how to configure RH 8 to validate against an NT domain server?
b) why aren't restricted folders/files showing up on file servers?

Thanks for any help.

jh

2. FvwmButtons under Red Hat 4. not working!

3. Porting Unix socket program to Windows NT

4. Latest Solaris 8 kernel patch (108528-15)

5. Linux Partitions from Windows NT/Windows 9x

6. Load balancing with SLIP?

7. Samba, FreeBSD and Windows XP/2K

8. Newbie Questions / CVSup

9. NIS and windows 9x/NT

10. DHCP support Windows 9x/NT/2000 Client?

11. need X terminal for windows 9x/nt IDEAS?

12. I think Windows 9x/nt/y2k/millenium have some advanteges

13. Dial-Up from Windows 9x/NT to DG/UX