Winsock Handles not inherited in CreateProcess called with bInheritHandles=TRUE

SYNOPSIS - in ROS when child process created with bInheritHandles=TRUE winsock handles are not inherited, in W2003 they are

This could be a problem in ntoskrnl, kernel32, or winsock. Trying to determine that now. (I believe I traced it down to winsock ws2helper DLL which cannot find context or catalog for handles inherited from parent, no idea how to fix.) (TRACED TO WINSOCK)

When an existing process has several sockets created and active and creates a child process through the CreateProcess API function, the child process should be able to use the existing handles and find them in the correct connection state. This is not true under ReactOS 0.4.15-x86-dev (retesting now under latest, but I expect no difference). Under this build using an existing connected handle fails reporting winsock errors. This method is used by many open source network server applications, and was detected when porting SAMBA4 to ReactOS.

I created a command line test application for it using Delphi, but it is a bit complicated to test because you need two processes and several connections.

I apologize for the long test description, but here goes.

To test you need to create two applications a command line client and a server paired to work in tandem doing a ping-pong set of tests. The server application is launched first and listens on a TCP port, creates a second socket sets it nonblocking and connects it to the first soring the 'accept' socket. It then sends a test message which it receives on the 'accept' socket and confirms it functions. The server then calls CreateProcess to execute the client with the handle inheritance parameter of CreateProcess set True.

The client then gets the UINT handle number of the 'accept' socket for the active connection and then makes a blocking receive call recv() on it, expecting to receive the information sent by the server in its non-blocking call.

Currently under ReactOS the client receives winsock error 10038 (not a socket) the moment it tries to use the inherited 'accept' socket.

I haven't tested this with file handles to see if it's a problem for inheriting all handles, but socket handles are definitely not being inherited properly. Both parts of the test work correctly in Windows 10.