On Tue, Apr 18, 2023, 4:44 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm trying to bring my old AF_UNIX patch up to date:
https://www.winehq.org/pipermail/wine-devel/2021-May/187049.html
It's not going too well as the code has changed quite a lot.
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?
(I'm not very familiar with the architecture of wine, which seems a bit confusing, so I'm just guessing how it all works.)
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW