Yes. A quick overview:
- dlls/ws2_32/socket.c is the Windows Socket 2 implementation. It acts as a frontend for the underlying socket implementation (AFD.SYS).
- dlls/ntdll/unix/socket.c emulates the AFD.SYS driver. It acts as the backend and does the actual socket I/O.
- server/sock.c manages socket polling, asynchronous I/O, as well as overall socket state management.
One particular problem I'm having is in wineserver. We need to
convert the Windows socket path encoded as a UTF-8 string
(eg. Z:\tmp\sock) into a Unix filename. In the old code I used:
+ num = MultiByteToWideChar(CP_UTF8, 0, wun->sun_path, -1, NULL, 0);
+ win_path = HeapAlloc(GetProcessHeap(), 0, num * sizeof(WCHAR));
+ if (win_path == NULL)
+ return 0;
+ MultiByteToWideChar(CP_UTF8, 0, wun->sun_path, -1, win_path, num);
+ unix_path = wine_get_unix_file_name(win_path);
+ heap_free(win_path);
However none of this seems to work inside wineserver (I guess because
it's not part of the "Windows world"). I cannot work out the
equivalent of this for wineserver, or if there's something else I
should be doing, such as converting the path before it is sent to
wineserver.
You should be converting the path before sending it to wineserver. The simplest hack would be using wine_get_unix_file_name() from ws2_32.
Note that you can't call wine_get_unix_file_name() from ntdll. That would constitute violation of abstraction boundary between the Win32 subsystem (which deals with DOS/Win32 paths) and the NT kernel (which deals with NT paths in Object Manager).
Supplemental question: There appears to be duplicate socket handling
code in wineserver server/sock.c and dlls/ntdll/unix/socket.c.
I don't believe this to be the case.
In my
tests only the wineserver code is called, and never the ntdll/unix
code. Why is that?
This would need further elaboration: which part of dlls/ntdll/unix/* did you expect to be called, but wasn't?