The aim of this serie is to (re)implement dbghelp.EnumerateLoadedModules
in order to return correct 32bit & 64bit modules information for a 32bit
debuggee from a 64bit debugger.
- In this case, Wine ntdll (incorrectly) stores the paths in LdrData
(for system modules) within the syswow64 directory while native stores
them within the system32 directory
(except for 32bit ntdll which Wine correctly stores within system32).
- So now dbghelp implements the system32 => syswow64 path rewrite (for
the relevant cases), which is currently used only for ntdll.
- This allows:
- to be transparent in dbghelp if ntdll is fixed to store the same
path as native
- the paths returned by dbghelp are consistent with native (in the
64bit debugger / 32bit debuggee case mentionned above)
It must be noted that the remaining todo:s in tests are only for
the case of a 32bit debugger / 32bit debuggee in (old|new) wow setup,
where the returned paths are the (untouched from ntdll) paths, hence
in syswow64 when native reports them from system32.
- this patch doesn't modify the returned path, and we haven't noticed
any issue so far
- with redirection in place, access to the image files should be
tranparent
- so we can keep it as is (not fixing ntdll).
--
v2: dbghelp: Reimplement EnumerateLoadedModules().
dbghelp/tests: Add more test wrt. modules's imagename handling.
dbghelp/test: Review old-wow64 expected values.
dbghelp/tests: Fix process kind detection on old Windows machines.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2830
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v11: ws2_32/tests: Add test for AF_UNIX sockets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
--
v2: xaudio2: Use the preprocessor to modify definitions in xaudio2.idl and xaudio2fx.idl.
xaudio2: Create XAPO objects directly from CreateAudioVolumeMeter() and CreateAudioReverb().
xaudio2: Move CreateAudioVolumeMeter() and CreateAudioReverb() to xapo.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2918
This is to prevent NULL pointers when creating a standalone text service
that doesn't have any text set and then using functions like EM_SETSEL.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v2: riched20: Set empty text by default in CreateTextServices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941