- Wine-GitLab - list.winehq.org

Re: [PATCH v3 0/1] MR9512: widl: Fix MethodList value for apicontract typedefs. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/7] MR9531: msado15: Reimplement Field::get_Value and Field::put_Value. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/1] MR9528: winevulkan: Avoid returning innacurate extension counts. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/1] MR9529: user32: Avoid out-of-bounds read in DdeCreateDataHandle with offset (ASan). - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v4 0/2] MR9500: In CreateProcess(), set std handle when passing a pseudo-console. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v4 0/6] MR9453: xactengine3/tests: Add many more tests. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/6] MR9523: wined3d: Move backend-specific code out of texture.c. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/4] MR9527: widl: Use the metadata short name for parameterized types. - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

Re: [PATCH v2 0/6] MR9525: rometadata: IMetaDataImport implementation, part 1 - approved
by Alexandre Julliard (＠julliard) Nov. 19, 2025

Nov. 19, 2025

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

1 0

[PATCH 0/1] MR9519: dlls/twain_32: Offer TWAIN DSM as twaindsm.dll for 64 Bit and send DAT_ENTRYPOINT earlier.
by Bernd Herd (＠herdsoft) Nov. 19, 2025

Nov. 19, 2025

64-Bit Windows applications typically expect the Twain Data Source manager to be named twaindsm.dll. Send the DG_CONTROL/DAT_ENTRYPOINT/MSG_SET before DG_CONTROL/DAT_IDENTITY/MSG_OPENDS so sane.ds does not need to know the module name to find the DSM entry point. An explanation for the request to offer the name twaindsm.dll for 64-Bit windows is offered here by the TWAIN organization: https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc They cannot update the twain_32.dll installed and maintained by Microsoft, so they choose the new name twaindsm.dll instead. This name is also used at least by Irfanview and oder versions oder LibreOffice (Newer Libreoffice version start a 32-Bit process for 32-Bit TWAIN usage). This Merge request also changes the twain_32.dll so that it send it's entry points earlier, before opening the data source. This is the same behaviour as the twaindsm.dll from the TWAIN organization from [https://github.com/twain/twain-dsm/](https://github.com/twain/twain-dsm/blo… Otherwise sane.ds would in MSG_OPENDS try to find the DSM entry point based on the module-name "twain_32" in sane_main.c:60: ``` if (SANE_dsmentry == NULL) { HMODULE moddsm = GetModuleHandleW(L"twain_32"); if (moddsm) SANE_dsmentry = (void*)GetProcAddress(moddsm, "DSM_Entry"); if (!SANE_dsmentry) { ERR("can't find DSM entry point\n"); return TWRC_FAILURE; } } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

5 5

[PATCH 0/1] MR9524: comctl32_v6/taskdialog: Fix not enough width for the expando button text.
by Zhiyi Zhang (＠zhiyi) Nov. 19, 2025

Nov. 19, 2025

The icon width and text offset are subtracted from the dialog max width and the result is then used for the expando button text rect calculation. When it's done, the expando button width should be the text width + icon width + text offset, not just the text width. ![Screenshot_From_2025-11-19_11-24-51](/uploads/b9f4f0ca8b72d6537e2a6b7788914cd3/Screenshot_From_2025-11-19_11-24-51.png) Test program: [test_taskdialog.zip](/uploads/0f710d99f9cfe8eb6a52645310cb1f53/test_taskdialog.zip) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9524

3 2

[PATCH 0/5] MR9521: comctl32/updown: Refactor UPDOWN_DrawBuddyBackground() to support drawing...
by Zhiyi Zhang (＠zhiyi) Nov. 19, 2025

Nov. 19, 2025

This MR marks the end of the series. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9521

3 6

Re: [PATCH v6 0/2] MR8360: include: Don't evaluate format arguments to ok() unless we need them.
by Bernhard Übelacker Nov. 19, 2025

Nov. 19, 2025

Hello @yshui, I am sorry, but I think I found an unwanted side effect of this patch. Since a9edbf49 got merged a failure in the [test pattern page of advapi32:registry](https://test.winehq.org/data/patterns.html#advapi32:regi… showed up. ``` registry.c:2267: Test failed: RegQueryValueExA returned: 0 ``` Because I was not able to reproduce it with testbot or a VM I tried to use gitlab CI: - [failure shows up here with a9edbf49](https://gitlab.winehq.org/bernhardu/wine/-/jobs/206300#L82) - [but succeeds here without a9edbf49](https://gitlab.winehq.org/bernhardu/wine/-/jobs/206303#L82) - Unfortunately adding a few traces around the place makes the failure go away like [here](https://gitlab.winehq.org/bernhardu/wine/-/jobs/209460#L82) - Also disabling optimizations for the function containing the test did not help like [here](https://gitlab.winehq.org/bernhardu/wine/-/jobs/209463#L83) (The git history of these Jobs can still be accessed by following the "Commit" at the right side, button "Browse Files", button "History.) What do you think? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8360#note_122996

1 0

Re: [PATCH v2 0/1] MR9477: shell32: Implement the function PickIconDlg.
by Vijay Kiran Kamuju (＠infyquest) Nov. 19, 2025

Nov. 19, 2025

Please check if it can be split into smaller patches -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9477#note_122995

1 0

[PATCH 0/9] MR9520: VMR7 fixes
by Matteo Bruni (＠Mystral) Nov. 19, 2025

Nov. 19, 2025

For Resident Evil 2 Classic. These are relatively small and simple patches, but I can certainly cut at 5 or so for the first part. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9520

4 11

Re: [PATCH v6 0/3] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Elizabeth Figura (＠zfigura) Nov. 19, 2025

Nov. 19, 2025

On Wed Nov 19 18:58:21 2025 +0000, Rémi Bernon wrote: > That's only the case for (D3D) drawables created from a > `wglSetPixelFormatWINE` call, and they should be kept referenced as long > as they are needed? > The window GL drawable(s) created with the window pixel format are kept > with the window itself (at least we keep one unused around). No, that's my bad, I thought we grabbed and released the DC on every frame, but we don't. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9382#note_122988

1 0

Re: [PATCH v6 0/3] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

On Wed Nov 19 18:58:01 2025 +0000, Elizabeth Figura wrote: > > Anyway, it's not needed anymore, I moved the cleanup to ReleaseDC, > limited to the kind of DCs that wined3d uses, it should be good enough > for now. > Wait, does this mean we're destroying the drawable on every ReleaseDC() > call? Isn't that going to kill performance? That's only the case for (D3D) drawables created from a `wglSetPixelFormatWINE` call, and they should be kept referenced as long as they are needed? The window GL drawable(s) created with the window pixel format are kept with the window itself (at least we keep one unused around). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9382#note_122985

1 0

Re: [PATCH v6 0/3] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Elizabeth Figura (＠zfigura) Nov. 19, 2025

Nov. 19, 2025

> Anyway, it's not needed anymore, I moved the cleanup to ReleaseDC, limited to the kind of DCs that wined3d uses, it should be good enough for now. Wait, does this mean we're destroying the drawable on every ReleaseDC() call? Isn't that going to kill performance? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9382#note_122982

1 0

[PATCH v2 0/6] MR9522: dmsynth: DLS fixes, part 2
by Anton Baskanov (＠baskanov) Nov. 19, 2025

Nov. 19, 2025

-- v2: dmsynth: Explicitly ignore CONN_DST_EG1_SHUTDOWNTIME. dmsynth: Make voice shutdown instant. dmsynth: Set GEN_EXCLUSIVECLASS to the key group. dmsynth: Handle bipolar transform for LFO connections. https://gitlab.winehq.org/wine/wine/-/merge_requests/9522

4 10

[PATCH 0/2] MR9515: dxgi: Prepare partial presentation tests
by Andrew Boyarshin (＠andrew-boyarshin) Nov. 19, 2025

Nov. 19, 2025

This is the first part of my partial presentation support patchset. Only the tests and minor implementation changes. Actual implementation will follow in multiple parts: minor refactoring of swapchain backbuffers, then actual implementation for dirty rectangles (with limitations), then limitations will be removed step-by-step, at the very end the scroll will be implemented. I had to mark many new tests as "flaky" (not "todo"). They are not actually flaky, they are perfectly stable on both Windows 8 RTM and one of the latest Windows 11 Canary builds. But since they check multiple pixels and some of them match, this causes the "failures". I saw no better solution which didn't involve new APIs in `wine/test.h`. Their number will drop in the next MRs to 0. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9515

3 5

[PATCH v3 0/2] MR9500: In CreateProcess(), set std handle when passing a pseudo-console.
by eric pouech (＠epo) Nov. 19, 2025

Nov. 19, 2025

This MR tests and fix the std handles in child process when using CreateProcess with extended information and passing a pseudo-console handle. >From the added tests, and other manual testing (see linked bugzilla entry), it turns out native overrides the (bound) std handles from the parent console with handles on the passed pseudo-console for the child process. But happily inherits other kind of handles. As side notes: - resetting the std handle in RTL_USER_PROCESS_PARAMETERS being console handles could be optimized: potentially, native could just test if the passed handles are bound to the passed console and reset them if not. - hijacked an unused bit in ConsoleFlags to discriminate when to recreate the std handles in child (didn't check-out how native does it though). -- v3: kernelbase: Create std handles from passed pseudo-console. kernel32/tests: Test std handles in CreateProcess with pseudo console. https://gitlab.winehq.org/wine/wine/-/merge_requests/9500

3 4

[PATCH 0/1] MR9533: win32u: Avoid leaking semaphore and fence exported fds.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

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

1 1

[PATCH v6 0/8] MR8812: winegstreamer: Support 2D sample buffer.
by Conor McCarthy (＠cmccarthy) Nov. 19, 2025

Nov. 19, 2025

Performance issues can occur when a video output sample has a 2D buffer, because winegstreamer currently outputs only to a linear buffer, which must then be copied into the 2D buffer. Worse, a linear lock of the 2D buffer requires the current contents to be copied to a linear buffer, even when we intend to overwrite it, because MF linear buffers do not support write-only locking. -- v6: winegstreamer: Support 2D sample buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/8812

3 14

[PATCH v2 0/1] MR9512: widl: Fix MethodList value for apicontract typedefs.
by Vibhav Pant (＠vibhavp) Nov. 19, 2025

Nov. 19, 2025

apicontract typedefs don't have any associated methods, so the MethodList value should be 0. -- v2: widl: Fix MethodList value for apicontract and enum typedefs. https://gitlab.winehq.org/wine/wine/-/merge_requests/9512

3 3

[PATCH v4 0/5] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v4: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. user32/tests: Use a dedicated window instead of the desktop window. ddraw/tests: Use a dedicated window instead of the desktop window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 5