Corinna Vinschen wrote: > Thanks. We still don't know *why* that happens, though. That bugs me.
For future reference here is what happens in Jason's experiments. All of them start in the system service environment and do as follows A) [optional] call gethostname to initialize wsock B) setgid/setgroups/setuid to remove 544 from the token problem does not occur if 544 stays. Problem occurs even with 545 (Users), so it's unlikely to a be a file/registry access issue. C) create socket and call dup (using WSADuplicateSocket method). There are 4 cases. Note that in case 2) the problem occurs before the dup. 1) A absent. Call directly from Windows WSADuplicateSocket fails 10022 WSAEINVAL Invalid argument. "Some invalid argument was supplied. In some instances, it also refers to the current state of the socket—for instance, calling accept on a socket that is not listening." 2) A absent. Call through sh -c (doesn't matter if sh initializes wsock) socket fails 10106 net helpmsg 10106 "The requested service provider could not be loaded or initialized." fgrep 10106 /usr/include/w32api/winerror.h #define WSAEPROVIDERFAILEDINIT 10106L WSAPROVIDERFAILEDINIT OS dependent Unable to initialize a service provider. "Either a service provider's DLL could not be loaded (LoadLibrary failed) or the provider's WSPStartup/NSPStartup function failed." 3) A present. Call directly from Windows Everything OK 4) A present. Call through sh -c (doesn't matter if sh initializes wsock) WSADuplicateSocket fails 10022 > > Just out of curiosity, why hasn't this always been done? I blindly thought > > it couldn't but I have just looked up MSDN and there is no mention of any > > restriction of DuplicateHandle with sockets, on any platform. > > Using WinSock2 should workaround the problem with the order in which sockets > are closed on 9x. Uh.. Do you have a pointer to that? I am only aware of such problems when sockets are duplicated across processes (by fork). Pierre