November 2025 - Wine-gitlab

[PATCH v2 0/10] 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. -- 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/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). -- 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) 04 Dec '25

04 Dec '25

-- 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

[PATCH v5 0/2] MR9265: crt: Run MingW and MSVC constructors/destructors
by Yuxuan Shui (＠yshui) 03 Dec '25

03 Dec '25

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/2] MR9605: icuin: Prefer native.
by Zhiyi Zhang (＠zhiyi) 03 Dec '25

03 Dec '25

Cyberpunk 2077 ships its own ICU library and calls `u_setMemoryFunctions_65()` and C++ exports. "\-Wb,--prefer-native" was in https://gitlab.winehq.org/wine/wine/-/merge_requests/8817. But it got lost when the MR got committed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9605

4 7

[PATCH v7 0/5] MR8837: opcservices: Add basic support for reading OPC packages.
by Vibhav Pant (＠vibhavp) 02 Dec '25

02 Dec '25

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

3 7

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

02 Dec '25

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; } } ``` -- v8: dlls/twaindsm: Recursively search in C:\Windows\twain_xx for installed data sources https://gitlab.winehq.org/wine/wine/-/merge_requests/9519

4 10

[PATCH v7 0/8] MR8812: winegstreamer: Support 2D sample buffer.
by Conor McCarthy (＠cmccarthy) 02 Dec '25

02 Dec '25

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. -- v7: winegstreamer: Support 2D sample buffer. mf/tests: Test color convert 2D buffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/8812

3 12

[PATCH v7 0/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) 02 Dec '25

02 Dec '25

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. -- v7: mfsrcsnk: Implement thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

3 6

[PATCH v2 0/3] MR9454: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client."
by Giovanni Mascellani (＠giomasce) 02 Dec '25

02 Dec '25

This reverts commit 21fb3555ed1f26e46d4c82cb2ec8fc29f730a0e9, which inadvertently removed support for converting audio formats not directly supported by mmdevapi. I'll work on a better solution over the next few days. -- v2: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client." https://gitlab.winehq.org/wine/wine/-/merge_requests/9454

3 4