- Wine-GitLab - list.winehq.org

Re: [PATCH v3 0/3] MR9149: ntdll: Fix clearing nested exception flag on x64. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9149

1 0

Re: [PATCH v4 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

1 0

Re: [PATCH v2 0/3] MR9188: win32u: Use local handles in D3DKMT_ESCAPE_UPDATE_RESOURCE_WINE. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9188

1 0

Re: [PATCH v3 0/7] MR9166: win32u: Implement vulkan memory export / import through host fds. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9166

1 0

Re: [PATCH v3 0/2] MR9178: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9178

1 0

Re: [PATCH v2 0/3] MR9182: dmscript: Code cleanups related to loading the Script form - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9182

1 0

Re: [PATCH v4 0/5] MR9128: win32u: Process internal hardware messages while waiting. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9128

1 0

Re: [PATCH v2 0/4] MR9174: ole32: Move CoTreatAsClass() to combase. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2025

Oct. 16, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9174

1 0

[PATCH 0/1] MR9193: mscoree: Update Wine Mono to 10.3.0.
by Esme Povirk (＠madewokherd) Oct. 16, 2025

Oct. 16, 2025

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

2 1

[PATCH 0/6] MR9191: comctl32/tests: Add CCM_SETVERSION tests.
by Zhiyi Zhang (＠zhiyi) Oct. 16, 2025

Oct. 16, 2025

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

3 10

[PATCH 0/1] MR8931: winex11.drv: Fixing an issue where the window size was not saved after...
by Ivan Lyugaev (＠valy) Oct. 16, 2025

Oct. 16, 2025

winex11.drv: Fixing an issue where the window size was not saved after switching from full-screen mode When switching from maximized window to windowed mode, the window retains the size of the entire screen. This bug is reproducible in xfce. Upon closer examination of the logs, I noticed that xfce was duplicating ConfigureNotify requests. The duplicate requests had the send_event=TRUE flag. These requests caused the window to resize incorrectly. The current implementation of wine uses the asynchronous ConfigureNotify event notification method - NtUserPosteMessage with the WM_WINE_WINDOW_STATE_CHANGED flag. I suggest returning to the synchronous method using Send_message. This bug is a regression. This issue first appeared in commit 0f1d999b, which moved the handling of GetWindowStateUpdates in win32u/message.c to the handle_internal_message function via NtUserPostMessage. I decided to revert the handling logic to before this patch was applied, adapting it to the current handling of GetWindowStateUpdates in win32u/message.c This solution was tested in xfce, mate, and a number of different programs. Everything worked correctly -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8931

3 8

[PATCH 0/1] MR9192: activeds: Remove misleading comments.
by Dmitry Timoshkov (＠dmitry) Oct. 16, 2025

Oct. 16, 2025

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

2 1

[PATCH v2 0/1] MR9186: uxtheme: Add stub for GetThemeBitmap.
by Louis Lenders (＠xe) Oct. 16, 2025

Oct. 16, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58747 -- v2: uxtheme: Add stub for GetThemeBitmap. https://gitlab.winehq.org/wine/wine/-/merge_requests/9186

3 2

[PATCH v2 0/1] MR9126: ntdll: On macOS, use separate mmap() and mprotect() calls when mapping files with PROT_EXEC.
by Brendan Shanks (＠bshanks) Oct. 16, 2025

Oct. 16, 2025

Starting with macOS 10.15, `mmap()` for a file with `PROT_EXEC` fails with `EPERM`. But for some reason, doing separate `mmap()` and then `mprotect()` calls works. This fixes `NtUserRegisterClassExWOW: Failed to get shared session object for window class` errors seen when running a 32-bit EXE lacking the NX compat bit. The shared memory object being used for window classes was being mapped executable, this was failing because of the above, and then `map_file_into_view()` was falling back to `pread()` which doesn't make sense for a shared memory region. (It seems like a bug to use `pread()` in this scenario rather than return an error, although I'm not sure how that could be detected). I don't love the preprocessor black-magic to replace every mmap() call, but it avoids having to modify any other functions. If we want to avoid that, `map_pe_header()` and `map_file_into_view()` are the `mmap()` calls that I know need to be changed. CrossOver has used an almost-identical hack for years. -- v2: ntdll: On macOS, use separate mmap() and mprotect() calls when mapping files with PROT_EXEC. https://gitlab.winehq.org/wine/wine/-/merge_requests/9126

4 5

[PATCH 0/2] MR9190: win32u: Add stub and basic tests for D3DKMT keyed mutexes.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

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

1 2

[PATCH v2 0/7] MR9189: mmdevapi/tests: Add a lot of capturing tests.
by Giovanni Mascellani (＠giomasce) Oct. 16, 2025

Oct. 16, 2025

-- v2: mmdevapi/tests: Test extensible wave formats when capturing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9189

2 7

[PATCH v2 0/2] MR9178: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize
by Luca Bacci (＠lb90) Oct. 16, 2025

Oct. 16, 2025

The `RtlRunOnce` family of functions are implemented using (a variant of) the Double Checked Locking Pattern (DCLP). The DCLP requires memory fences for correctness, on both the writer and reader sides. It's pretty obvious why it's needed on the writer side, but quite surprising that any is needed on the reader side! On strong memory model architectures (x86 and x86_64), only compiler-level fences are required. On weak memory model architectures like ARM64, instead, you need both CPU and compiler fences. That's explained well in books like _Concurrent Programming on Windows_ by Joe Duffy and in online resources like [1]. The Wine implementation has fences on the writing side (`RtlRunOnceComplete`). That's because `InterlockedCompareExchangePointer` inserts a full memory fence. However some code paths on the reader side (`RtlRunOnceBeginInitialize`) are missing fences, specifically the (`RTL_RUN_ONCE_CHECK_ONLY`) branch and the (`!RTL_RUN_ONCE_CHECK_ONLY && (val & 3) == 2`) branch. ~~Add the missing fences using GCC's atomic builtins [2]~~ **EDIT:** using `ReadPointerAcquire` now Note: with this MR, the generated code should change only for ARM64 ### References: 1. [Double-Checked Locking is Fixed In C++11](https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp… 2. [GCC's Built-in Functions for Memory Model Aware Atomic Operations](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.ht… -- v2: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize include: add atomic read/write of pointers https://gitlab.winehq.org/wine/wine/-/merge_requests/9178

4 4

[PATCH v3 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) Oct. 16, 2025

Oct. 16, 2025

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- v3: d3dx10: Pass D3DX10_IMAGE_LOAD_INFO texture creation arguments through in load_texture_data(). d3dx10: Handle FirstMipLevel argument in load_texture_data(). d3dx10: Add support for generating mipmaps to load_texture_data(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

3 5

[PATCH 0/1] MR9186: uxtheme: Add stub for GetThemeBitmap.
by Louis Lenders (＠xe) Oct. 16, 2025

Oct. 16, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58747 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9186

3 2

[PATCH 0/7] MR9189: mmdevapi/tests: Add a lot of capturing tests.
by Giovanni Mascellani (＠giomasce) Oct. 16, 2025

Oct. 16, 2025

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

2 7

[PATCH 0/3] MR9188: win32u: Use local handles in D3DKMT_ESCAPE_UPDATE_RESOURCE_WINE.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

And some misc fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9188

1 3

[PATCH v2 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) Oct. 16, 2025

Oct. 16, 2025

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- v2: d3dx10: Pass D3DX10_IMAGE_LOAD_INFO texture creation arguments through in load_texture_data(). d3dx10: Handle FirstMipLevel argument in load_texture_data(). d3dx10: Add support for generating mipmaps to load_texture_data(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

2 4

[PATCH 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) Oct. 16, 2025

Oct. 16, 2025

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

3 10

[PATCH v3 0/5] MR9128: Draft: win32u: Process internal hardware messages while waiting.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

They don't produce any window messages and should be processed as soon as possible, without returning to the client side. -- v3: server: Don't set QS_RAWINPUT for internal hardware messages. win32u: Process internal hardware messages while waiting. server: Clear QS_RAWINPUT | QS_HARDWARE in get_rawinput_buffer. win32u: Keep waiting on the queue until it gets signaled. win32u: Use an absolute wait timeout in wait_message. https://gitlab.winehq.org/wine/wine/-/merge_requests/9128

1 6

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess.
by li xiao (＠xiaolizai) Oct. 16, 2025

Oct. 16, 2025

On Thu Oct 16 07:06:10 2025 +0000, Rémi Bernon wrote: > Sorry, there's no general method to debug this and there's many possible > root causes. This indicates that one thread is waiting on a critical > section forever as another thread didn't release it (possibly crashed > while holding it, but could be something else). The missing name > indicates that it's probably a critical section created by the application. > You can open a bug report on the website above, with details about the > application you are trying to run if you can, and log file of Wine > output with `WINEDEBUG=+wgl` environment variable set for instance, this > might give some clue, or someone (including myself) can then try to > reproduce the issue and debug it. thinks，I have another question. Window DC calls the function set_dc_opengl_drawable( dce-\>hdc, NULL ) to release opengl-drawable through release_dce or release_dc. After this submission:[**win32u: Don't store the window OpenGL drawables on the DCs.**](https://gitlab.winehq.org/wine/wine/-/merge_requests/8958/diffs?com… where is the resource release for opengl-drawable? I don't seem to have seen it in this submission. The release of opengl_drawable should be done by the window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118688

1 0