November 2022 - Wine-GitLab

[PATCH 0/8] MR1489: DirectMusic: Don't force a calling convention on internal functions.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

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

4 10

[PATCH 0/3] MR1536: Preparation to long types migration (serie II)
by eric pouech (＠epo) Nov. 24, 2022

Nov. 24, 2022

Migration a couple of bits to unsigned int. Note to Zebediah (mainly on second commit of this serie): - there is also a load of 'uint32_t flags' parameters that I didn't change (mainly not to change too many things) Is this something to consider? - I didn't touch the local variables either. Maybe it's something to consider also. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1536

4 5

Re: [PATCH v2 0/1] MR1396: configure: On macOS, build the loader targeting 10.7 when preloader is used.
by Dean M Greer (＠Gcenx) Nov. 24, 2022

Nov. 24, 2022

On Wed Nov 23 21:10:49 2022 +0000, Brendan Shanks wrote: > Yes, although I also reproduced it with a test app I built on Mojave. On > Mojave environ wasn’t NULL, on Monterey/Ventura it was. >From searching this seems to be a known issues since macOS 11.1 https://www.gnu.org/software/gnulib/manual/html_node/environ.html -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1396#note_17364

1 0

[PATCH v3 0/4] MR1502: Draft: winevulkan: wow64 memory mapping using VK_EXT_external_memory_host
by Jacek Caban (＠jacek) Nov. 24, 2022

Nov. 24, 2022

This MR implements memory mapping for wow64 using VK_EXT_external_memory_host. This has some problems (more below), but overall, it looks promising as a stopgap. It passes D3D tests and works fine in general. For proper solution, we'd need a new Vulkan extension. I experimented with a prototype extension https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 and it looks like we can make it work, my WIP implementation is here https://gitlab.winehq.org/jacek/wine/-/tree/vulkan-map-placed. However, it would be nice to have a fallback working on existing drivers as well. The main problem of this MR is that it breaks Vulkan spec. The main rule it breaks is that according to spec, we should explicitly specify that we plan to use external memory when creating VkBuffer or VkImage. The problem is that we don't know if we will until we bind memory to the buffer. I tried some workarounds for that (delaying actual buffer creation, recreating buffer when needed). I got it mostly working and passing tests without validation errors, but it was more invasive than I'd like and still had other problems. I'd rather avoid that if possible. After looking at Mesa sources, I think that the way this MR breaks the spec should be harmless for its drivers. I don't have the hardware to test with Nvidia. If it works there, I'm tempted to ignore spec violation for now, given that the right path forward is VK_EXT_map_memory_placed anyway. Performance-wise, this MR is sub-optimal because we're limited in what memory types we can use. However, I ran Unigine benchmarks on radv and the difference was marginal. In case of Heaven, it was even slightly faster on wow64, which could be explained by 64-bit Vulkan driver being generally slightly faster, but the difference is too small to draw any conclusion. The last patch is not meant for (eventual) merge, but it's nice for testing the concept. It makes it possible to force using external memory in any kind of Wine build to experiment with its effects without need for wow64. To test that, just set `WINEVULKAN_EXTERNAL_MEMORY` environment variable. -- v3: winevulkan: Introduce debugging environment variables. winevulkan: Use VK_EXT_external_memory_host extension to map memory on wow64. winevulkan: Wrap VkDeviceMemory. winevulkan: Don't try to unwrap missing optional handle struct members. https://gitlab.winehq.org/wine/wine/-/merge_requests/1502

3 6

[PATCH v2 0/2] MR1528: winhttp: Improve WinHttpGetProxyForUrl() execution time when wpad is not available
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

Fixes Marvel Snap being unable to connect to servers (part of it, another part is wmic patches), and maybe improves wait times in many other apps. Typically "http://wpad/..." (which is commonly requested as lpszAutoConfigUrl for WinHttpGetProxyForUrl) is not available and WinHttpGetProxyForUrl() is hanging for a really long time resolving this name in download_script(). On Windows 10 here the name resolution timeout is about 9sec (and I could not find a way to configure it for a longer timeout). On Linux default DNS timeouts are typically longer. Yet, while WinHttpGetProxyForUrl() execution time is not consistent here, when I run it right after reboot or after network interface reconnection it typically takes ~4-7 seconds to complete on the first run. Then, testing it again shortly after yields no noticeable timeout. I suppose Windows caches and manages that globally in some service, so maximum possible 9 seconds name resolution timeout is rarely hit. Since proxy config URL, if available, is supposed to be in the local network, having the timeout of 5 seconds for name resolution looks more than enough to me. -- v2: winhttp: Cache script in download_script(). winhttp: Set name resolution timeout in download_script(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1528

3 4

[PATCH v2 0/7] MR1422: winhttp: Do not reference request from websocket.
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

The initial motivation is to make WinHttpCloseHandle(request) with request previously upgraded to websocket deliver WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING right away and not after websocket is closed much later (this late notification causes crash in Microsoft Flight Simulator). That happens so as the notification is sent when the object is destroyed, not when the handle is closed. This logic seems correct to me: when testing some more things involving closing handles and observing which threads get the notifications I saw Windows delivering WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING in the other threads, which suggests that the notification can be queued and delayed on Windows too in case there are pending operations involving the object. So the right thing to do seems to be to have just the separate websocket and do not reference request from it. It probably deserves a separate explanation why I am adding a refcounting to netconn and copying it to webscoket instead of just nullifying the netconn in request. Doing that way (just nullifying the netconn in request) immediately caused regression in Elden Ring which started failing in a convoluted way: it doesn't wait for WebSocketReceiveResponse() to complete and calls WebSocketCompleteUpgrade(). That currently succeeds in Wine due to some lack of validation. Then, after upgrade, async WebSocketReceiveResponse proceeds, but with NULL netconn it gets an error from prior WebSocketReceiveResponse in callback and fails the thing. The core problem here is that unless recursive request is involved WebSocketReceiveResponse is always sync on Windows and, as my testing goes, does not involve network communication at all. I. e., looks like the actual reply receiving should be done in WebSocketSendRequest, WebSocketReceiveResponse only sends notifications and possibly queues recursive reque sts. I have a WIP patches for that and_with the help of those and existing winhttp test I realized that removing connection from request is wrong even without convoluted story. We have an existing test in winhttp.c which performs second request / upgrade on a request already upgraded socket. The test as is succeeds even with NULL connection in request by that is by chance only (as we don't try to receive response from our in process server yet which is failing in this case). With connection removed request opens a new one which doesn't get processed by our server, while in the same test on Windows I see that request is actually received by server, suggesting that it uses all the same existing connection on Windows, and so we should keep the same connection in request. As a separate note, I suspect that we now can erroneously cache connection for request upgraded to websocket. But that happens not on request close but under different conditions and looks the same before and after present patches, so this should be probably checked and fixed separately. Patch "winhttp: Move read buffer to websocket." might look weird as introducing the buffer for the only purpose of preserve initial data. While I don't immediately see how that can be done simplier, I have another small excuse for that. Currently the logic of closing websocket handles does the correct thing WRT notifications and aborting the operation. Yet it is still racy a bit due to we use app's buffer in socket read calls. If we happen to receive some data already after we sent notifications but before the read operation is aborted it may write to already freed or otherwise reused app's buffer. It seems to me that the only clean way to deal with that later is to use our own read buffer and copy the data only when we are going to send non-abort completion notification. So this read buffer might have more use in the future. -- v2: winhttp: Do not reference request from socket. winhttp: Move read buffer to websocket. winhttp: Move flags to websocket header. winhttp: Store connection in websocket. winhttp: Send connection close notifications in finished_reading(). winhttp/tests: Avoid race condition on closing connection in server_thread(). winhttp: Add reference counting for connection. https://gitlab.winehq.org/wine/wine/-/merge_requests/1422

3 9

[PATCH 0/10] MR1526: mshtml: Misc improvements.
by Gabriel Ivăncescu Nov. 24, 2022

Nov. 24, 2022

For the `performance.navigation` props, I store them in the timing that's already linked from the window, to prevent adding more code around that just for 2 props, so it keeps it simple. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1526

2 13

Re: [PATCH v2 0/2] MR1399: explorer: Use a valid taskbar position when the taskbar is hidden.
by Francois Gouget (＠fgouget) Nov. 24, 2022

Nov. 24, 2022

For reference see bug https://bugs.winehq.org/show_bug.cgi?id=53963 This got fixed by MR!1524 in that the TestBot can again run the full test suite in Wine on dual-screen configurations (but I suspect there is still some underlying issue we are no longer triggering). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1399#note_17352

1 0

[PATCH v9 0/3] MR741: ntdll: Implement NtFlushProcessWriteBuffers.
by Torge Matthies (＠tmatthies) Nov. 24, 2022

Nov. 24, 2022

Based on [a patch](https://www.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.… by Jinoh Kang (@iamahuman) from February 2022. I removed the need for the event object and implemented fast paths for Linux. On macOS 10.14+ `thread_get_register_pointer_values` is used on every thread of the process. On Linux 4.14+ `membarrier(MEMBARRIER_CMD_GLOBAL_EXPEDITED, ...)` is used. On x86 Linux <= 4.13 `madvise(..., MADV_DONTNEED)` is used, which sends IPIs to all cores causing them to do a memory barrier. On non-x86 Linux <= 4.2 and on other platforms the fallback path using APCs is used. -- v9: ntdll: Add thread_get_register_pointer_values-based implementation of NtFlushProcessWriteBuffers. ntdll: Add sys_membarrier-based implementation of NtFlushProcessWriteBuffers. ntdll: Add MADV_DONTNEED-based implementation of NtFlushProcessWriteBuffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/741

3 4

[PATCH v2 0/8] MR1535: windows.gaming.input: Implement IForceFeedbackMotor_get_SupportedAxes + some fixes.
by Ivo Ivanov (＠logos128) Nov. 24, 2022

Nov. 24, 2022

-- v2: windows.gaming.input: Assume that joysticks with single FFB axis are racing wheels. windows.gaming.input: Implement the number of FFB axes according to the SupportedAxes property. dinput/tests: Reduce the available FFB axes to X and Y in test_windows_gaming_input. windows.gaming.input: Set initial effect parameters within the CS. windows.gaming.input: Implement IForceFeedbackMotor_get_SupportedAxes. dinput: Always send both "Type Specific" and "Set Effect" reports on initial Download. dinput/tests: Test zero-ed force feedback effect parameters. https://gitlab.winehq.org/wine/wine/-/merge_requests/1535

3 10