- Wine-GitLab - list.winehq.org

[PATCH 0/5] MR9658: PDB reader speedup 1.
by eric pouech (＠epo) Dec. 2, 2025

Dec. 2, 2025

This is a (first) MR about optmizing (new) PDB reader. Context: - game ships with a 1+ GB file and throws an exception at some point in the game, then captures a backtrace with a bunch of dbghelp invocations. - exception is also raised on native but is handled rather quickly (1-2seconds wall time), during what the game completly freezes. Old PDB reader (first context was on Wine 9.x) crashed when reading the PDB file. Serie starts with a fix for that, but it takes ages to load the PDB file. Context moved to Wine 10.x (with new PDB reader). Freeze time is about 7-8s. So this serie and subsequent ones will reduce freeze time (current status is 2.6s). This serie contains: - fix for old PDB reader to avoid crash, - some cleanups in PDB handling (nothing too fancy), - remove the computation of CRC when considering an ELF module, (the only place where this is used if when generating minidump including ELF modules, but the CRC is recomputed anyway). Since the CRC is computed on the whole ELF module image, and depending on number of referenced ELF modules, this can save quite some time (here ~1s). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9658

2 5

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

Dec. 2, 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? -- v8: 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. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

3 14

[PATCH v5 0/5] MR9572: opengl32: Implement GL_EXT_memory_object_win32 for base handle types.
by Derek Lesho (＠dlesho) Dec. 2, 2025

Dec. 2, 2025

Not sure about the extension replacement mechanism. Also, should tests be failing when extensions aren't supported? -- v5: opengl32: Expose GL_EXT_memory_object_win32. win32u/opengl: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. opengl32, win32u: Move gl_error to wgl_context. win32u/opengl: Implement GL_DEVICE_LUID_EXT and GL_DEVICE_NODE_MASK_EXT. opengl32: Cleanup glGet* and fix typo in glGetDoublev. https://gitlab.winehq.org/wine/wine/-/merge_requests/9572

2 7

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

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

Dec. 2, 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; } } ``` -- 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/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) Dec. 2, 2025

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

3 6

[PATCH 0/1] MR9657: msvfw32: Retry with avivideo device type if open fails.
by Akihiro Sagawa (＠sgwaki) Dec. 2, 2025

Dec. 2, 2025

King's Quest: Mask of Eternity (demo) has an AVI file named "w32opn_1.dll" and tries to open it with MCIWndCreate(). Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=36514 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9657

2 1

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

Dec. 2, 2025

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

[PATCH 0/1] MR9655: winevulkan: Update to VK spec version 1.4.335.
by Georg Lehmann (＠DadSchoorse) Dec. 2, 2025

Dec. 2, 2025

We should support VK_EXT_present_timing at some point, but it's not trivial to handle and I won't have time for it before the code freeze (nor a linux driver to test). For now, at least update the spec to ship the VK_EXT_ray_tracing_invocation_reorder fix. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9655

3 2

[PATCH 0/4] MR9656: msado15: Add _Recordset::LockType implementation.
by Piotr Caban (＠piotr) Dec. 2, 2025

Dec. 2, 2025

This patches allows setting/retrieving LockType. We don't take it into account while updating values. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9656

2 4