BUG: Socket Inheritance in Windows 95 and Windows NT 3.51

Last reviewed: May 2, 1996
Article ID: Q150523
The information in this article applies to:
  • Microsoft Win32 Software Development Kit (SDK) for Windows NT version 3.51 and Windows 95

SYMPTOMS

Windows 95 does not treat inheritance of Winsock socket handles in the same manner as Windows NT. This article summarises 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 reasearching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION

On 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:

  • Socket handles are not inheritable when created. To ensure that a child process can obtain and use a socket handle created in the parent, the handle must be explicitly duplicated using the Win32 API DuplicateHandle. Set the bInheritHandle parameter of the API to TRUE.
  • Socket handles cannot be set to the standard handles of the child process. A programmer may use other mechanisms to pass the socket handle to the client, such as passing the handle values as command line arguments so that the child process can simply look at its argument vector.

The following segment of 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.

Code Sample

   // 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;
      }

   }
   //
   // The parent must close both copies of the socket handles.
   //
   closesocket(OrigSock);
   closesocket(DuplicateSock);

The following segment of code illustrate how the newly created process would then extract 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
      }
   }


Additional reference words: 4.00
KBCategory: kbnetwork kbbuglist kbcode
KBSubcategory: NtwkMisc



THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: May 2, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.