December 2025 - Wine-gitlab

Re: [PATCH v2 0/4] MR9661: opengl32: Get OpenGL function table on process attach. - approved
by Alexandre Julliard (＠julliard) 04 Dec '25

04 Dec '25

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

1 0

Re: [PATCH v2 0/1] MR9672: win32u: Don't alter memory beyond structure effective size in NtUserEnumDisplaySettings(). - approved
by Alexandre Julliard (＠julliard) 04 Dec '25

04 Dec '25

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

1 0

[PATCH v3 0/3] MR9585: win32u: Introduce a D3DKMT escape code to set fullscreen present rect. (1/2)
by Rémi Bernon 04 Dec '25

04 Dec '25

These calls are Wine-specific and expected to fail on Windows, as the escape codes and parameter combinations are likely invalid there. There doesn't seem to be any mechanism to do this otherwise. When a window presentation rect has been set, the window is meant to be presented to that rect on screen exactly, mapped to physical coords. Then this also has the following side effects: * In exclusive fullscreen mode, GDI drawn child windows are clipped out of the rendered screen, regardless of the normal clipping rules. * The window position and size changes should be ignored wrt its visible area, and in particular the window should not be unmapped even if its Win32 rect is moved to an invisible location. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58844 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58443 --- This only introduces the mechanism and calls it from Wine D3D side. The side effects will be implemented later in win32u and the user drivers. This is necessary both for Command & Conquer 2, which has dialog child windows covering the entire game window while using WS_CLIPCHILDREN, and for Fallout 3 which does a bogus call sequence after window restoration which moves the window outside of screen area and causes its window and client rects to be empty: ``` SetRect(&rect, 0, 0, width, height); AdjustWindowRectEx(&rect, style, FALSE, 0); SetWindowPos(hwnd, 0, rect.left, rect.bottom, rect.right - rect.left, rect.top - rect.bottom, 0); ``` We need either this kind of mechanism (which could be later changed to some D3DKMTPresent call, but it would require a lot more work and I'd like to fix those regressions before the release), or to hook the window proc like modern Windows seems to be doing as tested in !9549 (and more tests suggest that invalid window moves are also now inhibited and corrected on modern Windows). -- v3: wined3d: Use the present rather than client rect when fullscreen. wined3d: Set the window present rect when entering fullscreen mode. win32u: Introduce a D3DKMT escape code to set fullscreen present rect. https://gitlab.winehq.org/wine/wine/-/merge_requests/9585

2 4

[PATCH v2 0/1] MR8701: devenum: Add DevicePath field for a video input device.
by Haoyang Chen (＠chenhaoyang) 04 Dec '25

04 Dec '25

-- v2: devenum: Add DevicePath field for a video input device. https://gitlab.winehq.org/wine/wine/-/merge_requests/8701

3 2

[PATCH v3 0/11] MR9520: VMR7 fixes
by Matteo Bruni (＠Mystral) 04 Dec '25

04 Dec '25

For Resident Evil 2 Classic. These are relatively small and simple patches, but I can certainly cut at 5 or so for a first MR. -- v3: quartz/tests: Add some VMR7 tests for unsupported formats. quartz/tests: Test VMR7 AllocateSurface with a BITMAPV4HEADER. quartz/tests: Test allocating BI_BITFIELDS pixel format. quartz/tests: Test allocating a surface with different bit depth from the primary. quartz/vmr7: Validate BITMAPINFOHEADER size. quartz/vmr7: Create a ddraw object if necessary to check for FourCC support. quartz/vmr7: Reject unsupported FOURCC formats. quartz/vmr7: Implement IVMRSurfaceAllocatorNotify::SetDDrawDevice(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9520

4 13

[PATCH v2 0/2] MR9571: winegstreamer: Implement media_object_Get{Input,Output}CurrentType.
by Yuxuan Shui (＠yshui) 04 Dec '25

04 Dec '25

-- v2: winegstreamer: Implement media_object_Get{Input,Output}CurrentType. mf/tests: Test Get{Input,Output}CurrentType. https://gitlab.winehq.org/wine/wine/-/merge_requests/9571

4 9

[PATCH 0/1] MR9669: winegstreamer: Fix SetOutputType of the wma decoder DMO.
by Yuxuan Shui (＠yshui) 04 Dec '25

04 Dec '25

In 60d5afc914e6e5aaee96022834a7f0d5f6a38e94 I moved transform creation to before the decoder->output_type is set, resulting in the decoder trying to create wg_transform with an empty type. bug introduced in !9570. 😖 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9669

4 3

[PATCH v14 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) 04 Dec '25

04 Dec '25

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- v14: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 7

[PATCH 0/1] MR9648: dlls/wmp: Implement the OLEIVERB_SHOW needed by the software Alldup
by pan hui (＠panhui) 04 Dec '25

04 Dec '25

The software "Alldup" uses OLEIVERB_SHOW, but OLEIVERB_SHOW is not implemented in oleobj.c, resulting in errors when running the Alldup via Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9648

3 2

[PATCH v13 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) 04 Dec '25

04 Dec '25

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- v13: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. kernel32: Use GetCurrentProcess() handle in CreateToolhelp32Snapshot if possible. kernel32/tests: Test CreateToolhelp32Snapshot with TH32CS_SNAPMODULE32. kernel32: Fix CreateToolhelp32Snapshot on old WoW64. include: Add TH32CS_SNAPMODULE32. kernel32/tests: Handle ERROR_BAD_LENGTH from CreateToolhelp32Snapshot. kernel32/tests: Fix CreateToolhelp32Snapshot failure check. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 8