- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR9672: win32u: Don't alter memory beyond structure effective size in NtUserEnumDisplaySettings().
by Paul Gofman (＠gofman) Dec. 4, 2025

Dec. 4, 2025

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

3 3

[PATCH 0/4] MR9674: PDB speedup 2
by eric pouech (＠epo) Dec. 4, 2025

Dec. 4, 2025

Continuing PDB reading optimizations: - optimize DBI hash table (150ms gained in ref test) - optimize compiland selection in line information queries (can be several hundreds of ms) moving from a linear to a binary search. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9674

2 4

[PATCH 0/4] MR9661: opengl32: Get OpenGL function table on process attach.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

Allowing win32u to use the OpenGL function table without requiring opengl32 module initialization. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9661

2 5

[PATCH 0/1] MR9663: Draft: winecoreaudio: Set the AudioChannelLayout on output units.
by Brendan Shanks (＠bshanks) Dec. 4, 2025

Dec. 4, 2025

Some users have reported the center/LFE channels being swapped when playing games that support surround sound. After investigating, it appears that winecoreaudio never sets AudioChannelLayout on the audio unit, and assumes that it matches the Windows layout (which is the order of `dwChannelMask`). This is often true, but not always. Using some test code [1] in `ca_setup_audiounit()` to get the AudioChannelLayout (Dell U2711 over HDMI), for some reason the audio unit defaults to having the center (3) and LFE (4) positions swapped from where Windows lays them out: ``` 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit Got channel layout: {tag: 0x0, bitmap: 0x0, num_descs: 6} 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 0: label 1 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 1: label 2 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 2: label 4 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 3: label 3 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 4: label 5 flags 0 1389548.056:0020:0124:err:coreaudio:ca_setup_audiounit desc 5: label 6 flags 0 ``` To fix this, set the AudioChannelLayout in `ca_setup_audiounit()`. Happily the Core Audio `AudioChannelBitmap` and Windows `dwChannelMask` perfectly match each other in speaker/bit positions, so this is easy. Marked as draft pending some extra testing. [1]: ``` { UInt32 size; Boolean writable; sc = AudioUnitGetPropertyInfo(unit, kAudioUnitProperty_AudioChannelLayout, kAudioUnitScope_Output, 0, &size, &writable); ERR("AudioChannelLayout sc %d\n", sc); if (sc == noErr) { AudioChannelLayout *layout = malloc(size); sc = AudioUnitGetProperty(unit, kAudioUnitProperty_AudioChannelLayout, kAudioUnitScope_Output, 0, layout, &size); ERR("AudioChannelLayout 2 sc %d\n", sc); ERR("Got channel layout: {tag: 0x%x, bitmap: 0x%x, num_descs: %u}\n", (unsigned int)layout->mChannelLayoutTag, (unsigned int)layout->mChannelBitmap, (unsigned int)layout->mNumberChannelDescriptions); for (unsigned int i = 0; i < layout->mNumberChannelDescriptions; i++) { ERR("desc %d: label %d flags %x\n", i, layout->mChannelDescriptions[i].mChannelLabel, layout->mChannelDescriptions[i].mChannelFlags); } free(layout); } } } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9663

3 2

[PATCH v4 0/5] MR9575: winegstreamer: Reject SetOutputType with a different number of channels.
by Yuxuan Shui (＠yshui) Dec. 4, 2025

Dec. 4, 2025

-- v4: winegstreamer: Reject SetOutput with a different number of channels. winegstreamer: Reject setting WMA DMO with an output type with a wrong formattype. mf/tests: Test if WMV decoder DMO accepts output type with a different size. mf/tests: Test SetOutputType with a wrong formattype on WMA decoder. mf/tests: Test if WMA decoder DMO accept output type with a different num of channels. https://gitlab.winehq.org/wine/wine/-/merge_requests/9575

2 5

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

Dec. 4, 2025

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). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9585

2 8

[PATCH v3 0/5] MR9575: winegstreamer: Reject SetOutputType with a different number of channels.
by Yuxuan Shui (＠yshui) Dec. 4, 2025

Dec. 4, 2025

-- v3: winegstreamer: Reject SetOutput with a different number of channels. winegstreamer: Reject setting WMA DMO with an output type with a wrong formattype. mf/tests: Test if WMV decoder DMO accepts output type with a different size. mf/tests: Test SetOutputType with a wrong formattype on WMA decoder. mf/tests: Test if WMA decoder DMO accept output type with a different num of channels. https://gitlab.winehq.org/wine/wine/-/merge_requests/9575

3 8

Re: [PATCH v2 0/2] MR9668: server: Always allow windows to activate after their creation. - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v3 0/1] MR9625: dlls/sane.ds: Make UI Non-Modal as required by Twain specification - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v2 0/8] MR9667: msado15: Add _Recordset Supports and Index implementation. - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v2 0/3] MR9666: ntdll: Rewrite arm64 packed unwind info handling. - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v2 0/1] MR9665: libs/ldap: Consistently use unicode version of QueryContextAttributes(). - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v3 0/2] MR9664: win32u: Remove scrollbar rect offsets when WS_HSCROLL or WS_VSCROLL is present. - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

Re: [PATCH v2 0/1] MR9662: win32u: Use asprintf in read_drm_device_prop. - approved
by Alexandre Julliard (＠julliard) Dec. 3, 2025

Dec. 3, 2025

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

1 0

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

Dec. 3, 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; } } ``` -- v9: dlls/twaindsm: Recursively search in C:\Windows\twain_xx for installed data sources dlls/twaindsm: Add DG_CONTROL/DAT_CALLBACKx/MSG_REGISTER_CALLBACK to support TWAIN 2.x protocol dlls/twaindsm: Implement DG_CONTROL/DAT_ENTRYPOINT/MSG_GET dlls/twaindsm, dlls/twain_32: Put DSM code into twaindsm.dll and add twain_32.dll wrapper https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

3 7

[PATCH 0/2] MR9668: server: Always allow windows to activate after their creation.
by Rémi Bernon Dec. 3, 2025

Dec. 3, 2025

When a process closes all of its window then opens a new one, Windows often allows it to get its "foreground process" status back, as long as it didn't actively give foreground to another process. On Wine the activate_other_window logic, or the host window manager, might have given focus to a different, non-parent, process already and we are preventing the old process from activating any window again. This relaxes the restriction a bit more, and allows new windows to be activated once after their creation, regardless of whether their owner is the foreground process or not. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59075 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9668

1 2

[PATCH 0/1] MR9634: dotnetfx35.exe: Add stub program.
by Rémi Bernon Dec. 3, 2025

Dec. 3, 2025

This overrides native dotnetfx35 installer, which is broken in an unfixable way. Recent Windows also bypass its execution. -- This has been in proton for a long time, it fixes various error popups when 3.5 .NET installer is executed. Native installer could still be attempted with `WINEDLLOVERRIDES` although it's never going to succeed installing with a recent Windows version. I think changing Windows version to XP might help it but it's also a manual step, so having an additional override to set shouldn't make much difference. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9634

3 15

[PATCH v2 0/1] MR9625: dlls/sane.ds: Make UI Non-Modal as required by Twain specification
by Bernd Herd (＠herdsoft) Dec. 3, 2025

Dec. 3, 2025

This is neccessary according to the Twain specification and also allows much more comfortable user interfaces. The Twain specification is clear that event processing in the main application must be provided while the data source shows it's User Interface: ``` "You cannot use the modal dialog creation call DialogBox( ) to create the Source’s user interface main window. To allow event processing by both the application and the Source, this call cannot be used" ``` This was already documented that way in Twain Specification 1.8. According to the specification, MSG_ENABLEDS only creates the dialog and then returns. But the implementation in ui.c with the call to CreatePropertySheetW equals a "DialogBox" call and returns only when the user clicks OK or CANCEL. This Merge Requests sets PSH_MODELESS to make CreatePropertySheetW create a non-modal dialog and then returns control back to the application. To avoid crashes, some of the pointers passed to CreatePropertySheetW must stay valid as long as the dialog remains open. A pointer to an additional struct SUiData is stored with the activeDS and cleared when the user interface is cleared with DestroyWindow on MSG_DISABLEDS. To reduce the number of changes in the source code, the PROPSHEETHEADERW is not part of the struct as no problems were observable. The user interface is no longer automatically closed after every scan. Depening on the application program, it can stay open, ready for the next scan with just a click on the "Scan" button, which results in a much easier and faster user interface experience. For example the user might modifiy settings like resolution or brightness and start a second scan with the modified parameters with a singe click. The progress dialog is modified * to use the UI dialog as it's parent window. * And get created centered on the user interface dialog instead of the screen. Application orograms I found to profit from the modified behaviour: * IrfanView 4.7.2 if the Button "Close Twain dialog after acquiring an image" is disabled. * The simple memxfer.c source I recently attached to an older merge request. -- v2: dlls/sane.ds: Make UI Non-Modal as required by Twain specification https://gitlab.winehq.org/wine/wine/-/merge_requests/9625

2 1

Re: [PATCH v5 0/1] MR5861: mshtml: Implement visibilitychange event.
by Gabriel Ivăncescu Dec. 3, 2025

Dec. 3, 2025

On Wed Dec 3 15:43:01 2025 +0000, Jacek Caban wrote: > Note that minimizing a window is just one case where this event should > fire, but there are many others. In regular browsers, switching tabs is > probably the most common source of the event. To support that, we would > need to detect real visibility changes of the document, not just window minimization. > That said, we do not need a complete solution right away, but since even > the limited support already requires awkward hooks, this does not look > very appealing. What exactly is it fixing? Do you have an actual > application that needs it? And what is the observable behavior > difference between this MR and just a stub? For example some games/apps XBox Sign-In is using it (via the Microsoft libs), probably for some sort of telemetry since it also does a bunch of performance timings, though I've no idea of the exact impact vs a stub. I actually wanted to have the tests not skipped on Wine (and also because we didn't have the hook before Esme implemented it, and now wanted to try it out). I mean, even if we do include it in other sources like switching tabs (although I'm unsure how to do that from mshtml without IE? aren't tabs in iexplore instead?), we'd still have to handle minimization somehow. And at least that one is more important since it works 100% without iexplore. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5861#note_124564

1 0

Re: [PATCH v8 0/1] MR9406: wined3d: texture.c split vulkan and opengl for cleaner clarity
by Stian Low (＠stianlow) Dec. 3, 2025

Dec. 3, 2025

Closing because these changes have been merged by: https://gitlab.winehq.org/wine/wine/-/merge_requests/9523 Comparing the diffs reveals nearly identical changes except for a few functions that were copied to different files. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9406#note_124552

1 0

Re: [PATCH v8 0/1] MR9406: wined3d: texture.c split vulkan and opengl for cleaner clarity - closed
by Stian Low (＠stianlow) Dec. 3, 2025

Dec. 3, 2025

This merge request was closed by Stian Low. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9406

1 0

[PATCH 0/8] MR9667: msado15: Add _Recordset Supports and Index implementation.
by Piotr Caban (＠piotr) Dec. 3, 2025

Dec. 3, 2025

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

2 8

[PATCH v5 0/2] MR9265: crt: Run MingW and MSVC constructors/destructors
by Yuxuan Shui (＠yshui) Dec. 3, 2025

Dec. 3, 2025

There are several motivations to enable ctor/dtor support: 1. ASan. This is not just about my wine-asan work, this is important for @bernhardu's PE asan work as well. The compiler generates ctors that poisons memory around global variables so misuses of them can be caught. This is the same both of our implementations of ASan. 2. Building third-party codebases against wine's CRT. This is not necessary for mingw-gcc or llvm-mingw, but the MSVC frontend of clang is another option for cross-compiling to Windows. However right now that requires Windows SDK. Bringing wine CRT to the point of being functional enough will give us another option. Could be useful for things like Proton. 3. (Controversial) Many dlls perform init/deinit tasks in `DllMain`. Some of them might benefit from a conversion to ctor/dtor. Since nothing in wine uses ctor/dtor right now, this change shouldn't have any impact by itself. -- v5: msvcrt: Run ctors and dtors from mainCRTStartup. winecrt0: Run ctors and dtors from DllMainCRTStartup. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

4 9

[PATCH 0/3] MR9666: ntdll: Rewrite arm64 packed unwind info handling.
by Martin Storsjö Dec. 3, 2025

Dec. 3, 2025

Instead of trying to handcraft all the cases for dealing with partial prologues, just synthesize the full unwind info for the function and execute that instead. The packed unwind info format always maps to a combination of regular unwind opcodes. This is how the arm packed unwind info implementation works already; this makes it easier to reason about compared with the handwritten code for dealing with partial prologues. The previous implementation is certainly faster and more efficient, but much harder to reason about, and to modify. Additionally, add testcases for more coverage, and fix another corner case in the handling of packed unwind info. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9666

1 3

[PATCH 0/1] MR9660: jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter in ES5+ modes.
by Gabriel Ivăncescu Dec. 3, 2025

Dec. 3, 2025

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

2 2