September 2023 - wine-gitlab

[PATCH 0/5] MR334: hlsl: Replace bare list pointers with hlsl_block, part 9/9.
by Zebediah Figura (＠zfigura) 11 Sep '23

11 Sep '23

This is the last series I have to use hlsl_block instead of list manipulation. There is still some list manipulation around, but it's a little trickier to get rid of, and questionably worthwhile. At any rate things are a lot better now than they were. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/334

4 7

[PATCH v26 0/1] MR3074: Move getpeername() implementation to wineserver
by Ally Sommers (＠dropbear) 11 Sep '23

11 Sep '23

`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`. This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side. *This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.* -- v26: server: Move getpeername() implementation from ntdll/unix. https://gitlab.winehq.org/wine/wine/-/merge_requests/3074

3 2

[PATCH 0/1] MR3630: msi: Use CreateFileW() for handling path from cabinet_open() instead.
by Jactry Zeng (＠jactry) 11 Sep '23

11 Sep '23

This fixes an issue while the path includes non-ASCII characters. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3630

3 6

Re: [PATCH v3 0/1] MR3777: gdi32: Add stub for D3DKMTQueryAdapterInfo.
by Jacek Caban (＠jacek) 11 Sep '23

11 Sep '23

On Mon Sep 11 08:05:33 2023 +0000, Etaash Mathamsetty wrote: > might have gotten the wow64 thunk wrong, so pls tell me how to fix it if > that's the case :) wow64 needs to be added to wow64win/syscall.h. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3777#note_44868

1 0

[PATCH v3 0/1] MR3767: msvcp110: Add std::_Throw_future_error.
by Daniel Lehman (＠dlehman25) 11 Sep '23

11 Sep '23

-- v3: msvcp110: Add std::_Throw_future_error. https://gitlab.winehq.org/wine/wine/-/merge_requests/3767

3 3

[PATCH v52 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 11 Sep '23

11 Sep '23

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 not fully supported by this patch, matching the behavior of Windows. -- v52: ws2_32/tests: Add test for AF_UNIX sockets fix. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. ws2_32: Add support for AF_UNIX sockets. ntdll/unix: Add support for AF_UNIX sockets to multiple functions. ws2_32: Add afunix.h header. https://gitlab.winehq.org/wine/wine/-/merge_requests/2786

2 7

[PATCH 0/9] MR3782: dmime: Stub graph and tool interfaces for the performance.
by Rémi Bernon (＠rbernon) 10 Sep '23

10 Sep '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3782

3 12

[PATCH 0/9] MR3781: dmusic: Begin cleanup parsing of collection instruments.
by Rémi Bernon (＠rbernon) 10 Sep '23

10 Sep '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3781

3 10

[PATCH 0/2] MR3778: d3d8/tests: Try harder to drop focus in test_window_position.
by Stefan Dösinger (＠stefan) 10 Sep '23

10 Sep '23

This MR fixes this random failure: http://test.winehq.org/data/126363ea5f9056449e8bd22cc69b51bd2d7dd9aa/linux_… It happens mostly in d3d9, but if you try hard enough you can see it on d3d8 too. There are more random failures in test_window_position that I have seen when running on an actual display but not in a dummy X server or Xephyr. One failure mode is that we lose focus in the initial create_device and minimize ourselves. This particular problem is specific to focus follows mouse. Another is that fvwm seems to place the window slightly offscreen, maybe shifted by the size of the window decoration. I am still looking into those issues. Unrelated to test_windoow_position, there is at least one more random failure in test_wndproc (Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0.), so expect more fvwm3 related MRs after this one... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3778

3 5

[PATCH v2 0/2] MR3372: ole32: Leave the RunningObjectTable Critical Section before unmarshalling object stream
by Lorenzo Ferrillo (＠llde) 10 Sep '23

10 Sep '23

In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem. Visual Studio 2019 deadlock on start without this. I'm not sure how to test this properly. Also add debug info for this critical section so it show a significant name in the log. Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it> -- v2: ole32: Add debug info to RunningObjectTable critical section ole32: Leave the RunningObjectTable Critical Section before umarshalling object https://gitlab.winehq.org/wine/wine/-/merge_requests/3372

2 2

2025

2024

2023

2022

wine-gitlab September 2023