BUG: Socket Inheritance in Windows 95 and Windows NT 3.51

ID: Q150523


The information in this article applies to:


SYMPTOMS

Windows 95 does not treat inheritance of Winsock socket handles in the same manner as Windows NT. This article summarizes the difference between the two operating systems.


STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.


MORE INFORMATION

Under Windows NT, socket handles are inheritable by default. This feature is often used by a process that wants to spawn a child process and have the child process interact with the remote application on the other end of the connection.

It is also common practice on Windows NT to set the standard handles (standard input, output, or error) of the child process to the socket handle. In such cases, the child process usually does not know that its standard handles are actually sockets.

Windows 95 differs from Windows NT in the following manner:

The following sample code illustrates how to write applications that will inherit sockets in child processes on both Windows 95 and Windows NT. Please note that this is 32-bit code only. 16-bit applications cannot inherit socket handles.

Sample Code


   // This is a Winsock server that is listening on a port.

   // When a client connects, the server spawns a child process and
   // passes the socket handle to the child.
   // The child can use this socket handle to interact with the
   // client and the parent is free to go back to waiting for
   // other clients to connect.

   OrigSock=accept(listen_socket,(struct sockaddr *)&from,&fromlen);

   if (OrigSock == INVALID_SOCKET)  {
      fprintf(stderr,"accept failed %d\n",GetLastError());
      return -1;
   }
   {
      STARTUPINFO si;
      PROCESS_INFORMATION pi;
      char argbuf[256];

      memset(&si,0,sizeof(si));

      // 
      // Duplicate the socket OrigSock to create an inheritable copy.
      // 
      if (!DuplicateHandle(GetCurrentProcess(),
            (HANDLE)OrigSock,
            GetCurrentProcess(),
            (HANDLE*)&DuplicateSock,
            0,
            TRUE, // Inheritable
            DUPLICATE_SAME_ACCESS)) {

         fprintf(stderr,"dup error %d\n",GetLastError());
         return -1;
      }
      // 
      // Spawn the child process.
      // The first command line argument (argv[1]) is the socket handle.
      // 

      wsprintf(argbuf,"child.exe %d",DuplicateSock);
      if (!CreateProcess(NULL,argbuf,NULL,NULL,
               TRUE, // inherit handles
               0,NULL,NULL,&si,&pi) ){
         fprintf(stderr,"createprocess failed %d\n",GetLastError());
         return -1;
      }

      // 
      // On Windows 95, the parent needs to wait until the child
      // is done with the duplicated handle before closing it.
      // 
      WaitForSingleObject(pi.hProcess, INFINITE);
   }
   // 

   // The duplicated socket handle must be closed by the owner
   // process--the parent. Otherwise, socket handle leakage
   // occurs. On the other hand, closing the handle prematurely
   // would make the duplicated handle invalid in the child. In this
   // sample, we use WaitForSingleObject(pi.hProcess, INFINITE) to
   // wait for the child.
   // 
   closesocket(OrigSock);
   closesocket(DuplicateSock); 

The following sample code illustrates how the newly created process extracts the socket handle from its command line:

   main(int argc, char *argv[]){
      SOCKET Sock;

      /* WSAStartup etc. */ 
      if (2 == argc){
         Sock = atoi(argv[1]);   // use Sock
      }
   } 


Keywords          : kbnetwork kbAPI kbNTOS351bug kbSDKPlatform kbWinOS95bug kbWinsock kbGrpNet 
Version           : 
Platform          : 
Issue type        : kbbug 

Last Reviewed: March 10, 1999