- Wine-GitLab - list.winehq.org

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

Dec. 4, 2025

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) Dec. 4, 2025

Dec. 4, 2025

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) Dec. 4, 2025

Dec. 4, 2025

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) Dec. 4, 2025

Dec. 4, 2025

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

[PATCH v12 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) Dec. 4, 2025

Dec. 4, 2025

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? -- v12: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 9

[PATCH v11 0/7] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) Dec. 4, 2025

Dec. 4, 2025

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? -- v11: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

3 17

[PATCH 0/1] MR9673: dlls/sane.ds: Workaround for LineArt mode in some SANE backends
by Bernd Herd (＠herdsoft) Dec. 4, 2025

Dec. 4, 2025

If value for bytes_per_line is not reasonable in 1 bit per pixel mode, calculate a new value. The sane backend for the HP Officejet Pro 8600 N911a printer/scanner is has the bug that it specified a wrong value for the number of bytes per scan line in lineart mode (1 bit per pixel). Debugging seems to indicate that the faulty value is coming from the firmware of that 11 years old printer/scanner device. Some Sane frontends ignore the bytes_per_line values. This who use it do not work with that device, notable when scanning with Libreoffice Writer. So the problem is obviously caused by the sane backend, not by the sane.ds code. This merge requests offers a workaround by calculating a new value from the scan width in pixels if the given value is not plausible. This makes scanning in LineArt mode possible for that device. It is unclear if any other devices are also effected. It is unclear if the wine project wants to add workrounds like this to the code base, so I see it as a proposal for a discussion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9673

3 3

[PATCH v10 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. 4, 2025

Dec. 4, 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; } } ``` -- v10: 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 https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

3 5

[PATCH v8 0/5] MR8837: opcservices: Add basic support for reading OPC packages.
by Vibhav Pant (＠vibhavp) Dec. 4, 2025

Dec. 4, 2025

This MR introduces an initial implementation for `ReadPackageFromStream` in order to be able to decompress/read OPC packages, and enumerate their parts. This is required for supporting AppX packages, which themselves are OPC packages as well. As such, the code does not implement support for reading relationships or interleaved archives, as AppX does not support either (`APPX_E_RELATIONSHIPS_NOT_ALLOWED`, `APPX_E_INTERLEAVING_NOT_ALLOWED`). -- v8: opcservices: Implement IOpcPart::GetContentType for opened packages. opcservices: Implement IOpcPart::GetContentStream for opened packages. opcservices: Create IOpcPart objects for ZIP entries in an opened package. opcservices: Add stubs for ReadPackageFromStream. opcservices: Set flags field for central directory records as well. https://gitlab.winehq.org/wine/wine/-/merge_requests/8837

2 5

[PATCH 0/1] MR9682: bcrypt/tests: Fix test failures on Windows 8 and 11.
by Hans Leidekker (＠hans) Dec. 4, 2025

Dec. 4, 2025

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

2 1

[PATCH 0/1] MR9681: opengl32, win32u: Move GL error to wgl_context.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

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

2 2

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

Dec. 4, 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. -- v6: crt: Run MSVC constructors and destructors. winecrtend: Add a staticlib for holding ctor/dtor section pointers. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

3 14

[PATCH v8 0/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) Dec. 4, 2025

Dec. 4, 2025

Follow-up to !8184. This also adds a bunch of helpers for writing media source tests (without involving the mf session) in mfsrcsnk, these could be helpful for more tests of this kind in the future. I'm somewhat unsure as to why we haven't done tests for source behavior so far: while those are plugins, applications rely on a bunch of things in the builtin sources that microsoft provides. Since this affects both mfsrcsnk and winegstreamer sources, tests should be run both with `HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler` enabled and disabled. Due to this I figured it'd make sense to implement everything first and then remove the test todo_wine's and the statements rejecting the thin parameter in a single commit ("Allow thinning"). Perhaps this could be solved more nicely by setting the registry key in the tests themselves? I'm unsure if that is something we do in tests, generally. `MEStreamThinMode` events need to be emitted between the last sample using the outdated thinning parameter and the first sample using the updated thinning parameter. The winegstreamer implementation for this turned out a bit complex, if there is a simpler way to do this please let me know. Regarding winegstreamer, note that buffers need to be intercepted before the decoder because decoders often discard `GST_BUFFER_FLAG_DELTA_UNIT` flags (which is already annoying in itself - it causes all samples to be marked as `MFSampleExtension_CleanPoint`, this should potentially be worked around in the future). But even besides that, intercepting before the decoder is the "proper" implementation, since the point of thinning is increasing decoding speed by skipping delta frames, tho there are some games that rely on the semantics as well. -- v8: mfsrcsnk: Implement thinning. mfsrcsnk: Process SetRate asynchronously. winedmo: Fall back to dts for sample time if pts is not present. mfsrcsnk/tests: Add tests for thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

3 13

[PATCH 0/2] MR9680: wbemprox/tests: Consistently use check_property_nullable().
by Hans Leidekker (＠hans) Dec. 4, 2025

Dec. 4, 2025

And drop some workarounds for old Windows versions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9680

2 2

[PATCH 0/1] MR9679: winewayland: Update client surface position in update callback.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57393 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59061 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9679

1 1

[PATCH v2 0/10] MR9520: VMR7 fixes
by Matteo Bruni (＠Mystral) Dec. 4, 2025

Dec. 4, 2025

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. -- v2: ddraw/tests: Test FourCC surface creation with DDSCAPS_OFFSCREENPLAIN. 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: Use the ddraw clipper to compute the presentation rect. quartz/vmr7: Reject unsupported FOURCC formats. ddraw: Advertise NV12 FOURCC as supported. quartz/vmr7: Reject BI_RGB and BI_BITFIELDS formats with different bit depth. quartz/vmr7: Handle BI_BITFIELDS formats. https://gitlab.winehq.org/wine/wine/-/merge_requests/9520

4 18

[PATCH 0/4] MR9678: msado15: Partial _Recordset::Update and _Recordset::CancelUpdate implementation.
by Piotr Caban (＠piotr) Dec. 4, 2025

Dec. 4, 2025

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

2 4

[PATCH v2 0/4] MR9676: win32u: Query EGL devices UUID with EGL_EXT_device_persistent_id.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

-- v2: win32u: Query EGL devices UUID with EGL_EXT_device_persistent_id. https://gitlab.winehq.org/wine/wine/-/merge_requests/9676

1 5

[PATCH v2 0/2] MR9595: cmd: Reparse support.
by Elizabeth Figura (＠zfigura) Dec. 4, 2025

Dec. 4, 2025

-- v2: cmd: Implement mklink /j. https://gitlab.winehq.org/wine/wine/-/merge_requests/9595

3 5

[PATCH v4 0/2] MR7938: Draft: winemac: Use IOSurface to update native window layers instead of CGImage.
by Marc-Aurel Zent (＠mzent) Dec. 4, 2025

Dec. 4, 2025

This consolidates the two separate `CGImage`s (`colorImage` and `shapeImage`) previously used in `WineContentView` into a single `IOSurface` that also holds the window mask information in its alpha channel now. The alpha channel is now being updated in `macdrv_surface_flush`, whenever the shape changes (and stores that change for the next update, to also keep the front buffer in sync). This reduces the delay from setting a `CGImage` to a layer from 50ms to about 1.5ms in the `IOSurface` case (also accounting for `vImageSelectChannels_ARGB8888` operation). Based on a patch by @bshanks. I am already putting it out for feedback, but I will so some more testing to see how the performance impact of this is and do more exhaustive testing with shaped windows. Ideally the double buffer solution can be avoided as well... Also the `HBITMAP` for the windows is currently backed by a `CGDataProviderRef` and could also become an `IOSurface` I believe. -- v4: winemac: Use IOSurface to update native window layers instead of CGImage. https://gitlab.winehq.org/wine/wine/-/merge_requests/7938

2 4

[PATCH 0/1] MR9677: opengl32: Cleanup glGet* and fix typo in glGetDoublev.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9677

2 2

[PATCH v3 0/2] MR7938: Draft: winemac: Use IOSurface to update native window layers instead of CGImage.
by Marc-Aurel Zent (＠mzent) Dec. 4, 2025

Dec. 4, 2025

This consolidates the two separate `CGImage`s (`colorImage` and `shapeImage`) previously used in `WineContentView` into a single `IOSurface` that also holds the window mask information in its alpha channel now. The alpha channel is now being updated in `macdrv_surface_flush`, whenever the shape changes (and stores that change for the next update, to also keep the front buffer in sync). This reduces the delay from setting a `CGImage` to a layer from 50ms to about 1.5ms in the `IOSurface` case (also accounting for `vImageSelectChannels_ARGB8888` operation). Based on a patch by @bshanks. I am already putting it out for feedback, but I will so some more testing to see how the performance impact of this is and do more exhaustive testing with shaped windows. Ideally the double buffer solution can be avoided as well... Also the `HBITMAP` for the windows is currently backed by a `CGDataProviderRef` and could also become an `IOSurface` I believe. -- v3: winemac: Use IOSurface to update native window layers instead of CGImage. winemac: Also return alpha channel in macdrv_window_background_color. https://gitlab.winehq.org/wine/wine/-/merge_requests/7938

2 6

[PATCH 0/4] MR9676: win32u: Query EGL devices UUID with EGL_EXT_device_persistent_id.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

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

1 4

Re: [PATCH v2 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

> Er, right, I meant the video present node source ID, that's the monitor as I understand. Maybe, but in any case we don't have a proper implementation of those anyway. > Well, the point is, it's always going to be the full monitor, isn't it? Perhaps, but I don't think it really matters as this is a custom and probably a temporary mechanism. Ultimately we might want to do things differently but here I'm only aiming at something simple that works for Wine 11, not something perfect that will take time to design properly. We have the rect at hand, while getting a monitor would require something more complicated possibly with more unforeseen issues. > Right, we also need that call. I think it's still better arrangement to have calls in those three places. Sure, changed it to this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9585#note_124659

1 0

[PATCH 0/1] MR9675: winemac: Avoid taking the window lock when creating client surface.
by Rémi Bernon Dec. 4, 2025

Dec. 4, 2025

It's not even necessary anymore, and macdrv_create_view blocks on the main thread, which sometimes seems to trigger a deadlock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9675

1 1