- Wine-GitLab - list.winehq.org

[PATCH v3 0/4] MR10864: winegstreamer: Rebase PTS values so the stream starts at zero.
by Akihiro Sagawa (＠sgwaki) Aug. 24, 2026

Aug. 24, 2026

mpegpsdemux uses raw PTS values from the stream, which often start at a non-zero timestamp. To avoid an initial delay, we rebase the PTS by subtracting the first raw value so that the buffer timeline begins at zero for the MPEG-I splitter in DirectShow. Without this adjustment, the first sample would not be presented until its original (non-zero) timestamp in MPEG-1 system stream. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59565 -- v3: winegstreamer: Rebase PTS values so the stream starts at zero. winegstreamer: Change wg_parser_create argument from bool to bit flags. quartz/tests: Add a timestamp test for the first sample. winegstreamer: Make sure every stream has a buffer or an initial gap on initialization. https://gitlab.winehq.org/wine/wine/-/merge_requests/10864

5 8

[PATCH v7 0/1] MR11387: start: Avoid buffer overflows during path lookup.
by Likun Li (＠lilikun124) Aug. 24, 2026

Aug. 24, 2026

start.exe searches for its first argument using fixed-size path buffers. Several normalized paths, path components, executable names, and PATHEXT entries were copied without consistent bounds checks, allowing a long protocol URL to cause an access violation before ShellExecuteExW. Validate each destination buffer operation and leave arguments that cannot be represented by the path search buffers unchanged for ShellExecuteExW. The later fix update adds a cmd.exe conformance test. It registers a temporary protocol and verifies that cmd.exe /c start passes a URL longer than MAX_PATH to its handler unchanged. Related merge request: !11386 adds per-user protocol lookup and desktop export for handlers registered under HKCU\\Software\\Classes. End-to-end Notion Calendar testing was performed with this MR and !11386 applied together. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57229 Signed-off-by: Likun Li lilikun124(a)gmail.com -- v7: start: Avoid buffer overflows during path lookup. https://gitlab.winehq.org/wine/wine/-/merge_requests/11387

3 5

[PATCH v4 0/7] MR11720: wined3d: Various.
by Elizabeth Figura (＠zfigura) Aug. 24, 2026

Aug. 24, 2026

-- v4: mfplat/tests: Remove a todo. https://gitlab.winehq.org/wine/wine/-/merge_requests/11720

4 7

[PATCH 0/1] MR11737: ntdll: Infer the trap number in segv_handler() when the context lacks one.
by Nat Brown (＠natbro) Aug. 24, 2026

Aug. 24, 2026

An issue found while adding Apple Silicon macOS host support for building Proton (https://github.com/ValveSoftware/Proton/pull/10087) Proton's Wine version builds and then runs 64-bit and 32-bit versions of wine in order to create a base prefix as part of a redistributable package phase, all within a guest linux/amd64 container. 32-bit i386 processes translate with QEMU in this host context, while 64-bit x86_64 uses the host's Rosetta 2 translation system. It is likely but not confirmed that QEMU would similarly be used and 32-bit wine would fail to run when virtualizing linux/amd64 on linux/arm64 hardware. qemu-user synthesizes signal frames without filling in the trap number, leaving TRAP_sig() as -1. segv_handler() then falls through to the default case, logs "Got unexpected trap -1" and never services the fault, so page faults during 32-bit module loading surface as unhandled exceptions. Infer the trap from the delivered signal instead. Note that ERROR_sig() is unset for the same reason, so faults routed to TRAP_x86_PAGEFLT are classified as reads; that is sufficient to get through process startup but is not a complete emulation of the missing context. A different option to this hardening would be to work with the QEMU project to fill in its signal frames. This fix may be appropriate standalone hardening for Wine. Although discovered as a "build issue" it impacts many plausible layered and virtualized real uses of Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11737

4 6

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 15:13:29 2026 +0000, Andrea Faulds wrote: > I'm not completely sure of this, but I don't think we can. I think the > helper is only designed to close certain windows that appear when errors > occur like “There is no Windows program associated with this type of > file”, and I think this file is only testing things that should trigger > errors… my guess is that there's no existing tests for shell folders > precisely because there's no code for closing them. Thanks for the explanation! In that case, please add ```c if (!winetest_interactive) { skip( "interactive explorer guid argument test (set WINETEST_INTERACTIVE=1)\n" ); return; } ``` at the top of the `test_guid()` function so that it doesn't run in batch mode. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149692

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 15:02:01 2026 +0000, Jinoh Kang wrote: > Can we reuse the existing helper? It doesn't make multi-process > assumptions and close the window instead. I'm not completely sure of this, but I don't think we can. I think the helper is only designed to close certain windows that appear when errors occur like “There is no Windows program associated with this type of file”, and I think this file is only testing things that should trigger errors… my guess is that there's no existing tests for shell folders precisely because there's no code for closing them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149691

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 14:41:54 2026 +0000, Andrea Faulds wrote: > It works under WINE, because WINE launches a separate `explorer` process > for every folder window, and therefore gives a process handle. Without > this bit, the WINE session never ends, which is very annoying. > However, I would not be surprised if it does nothing on Windows (which > doesn't launch separate `explorer` processes) and there is in fact a > hidden explorer window sticking around, which is not good… > I think it might be possible to rework this to try to find the new > window with `IShellWindows` and close it, but that would make things > very complicated and I'm a little worried it might be fragile. > If I removed the test, do you think the fix would still be mergeable? > Otherwise, I guess I'll do the `IShellWindows` thing. Can we reuse the existing helper? It doesn't make multi-process assumptions and close the window instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149686

1 0

[PATCH v2 0/1] MR11742: krnl386: Don't free DISCARDABLE resources in FreeResource16.
by Alex Henrie (＠alexhenrie) Aug. 24, 2026

Aug. 24, 2026

If a resource is marked DISCARDABLE, it is not actually freed when its refcount reaches 0. In theory the resource's memory is freed when the system is low on memory, but its global handle remains valid to allow the resource to be resurrected with the same handle later. In practice, 16-bit programs can't run out of memory on modern hardware, and the game Tetris Jr. depends on its discardable resources never being discarded. See https://devblogs.microsoft.com/oldnewthing/20040202-00/?p=40783 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=23364 -- v2: krnl386: Don't free DISCARDABLE resources in FreeResource16. https://gitlab.winehq.org/wine/wine/-/merge_requests/11742

3 4

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 14:24:38 2026 +0000, Jinoh Kang wrote: > Does this actually work? Our tests are non-interactive, and should never > leave stray windows open when the test finishes. It works under WINE, because WINE launches a separate `explorer` process for every folder window, and therefore gives a process handle. Without this bit, the WINE session never ends, which is very annoying. However, I would not be surprised if it does nothing on Windows (which doesn't launch separate `explorer` processes) and there is in fact a hidden explorer window sticking around, which is not good… I think it might be possible to rework this to try to find the new window with `IShellWindows` and close it, but that would make things very complicated and I'm a little worried it might be fragile. If I removed the test, do you think the fix would still be mergeable? Otherwise, I guess I'll do the `IShellWindows` thing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149683

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

Jinoh Kang (@iamahuman) commented about dlls/shell32/tests/shlexec.c: > + sei.cbSize = sizeof(sei); > + sei.fMask = SEE_MASK_NOCLOSEPROCESS | SEE_MASK_NOASYNC | SEE_MASK_FLAG_NO_UI; > + sei.lpVerb = L"open"; > + sei.lpFile = L"::{20d04fe0-3aea-1069-a2d8-08002b30309d}"; > + sei.nShow = SW_HIDE; > + > + result = ShellExecuteExW(&sei); > + ok(result, "ShellExecuteExW failed\n"); > + > + /* kill the new subprocess if possible as cleanup */ > + > + if (sei.hProcess) > + { > + TerminateProcess(sei.hProcess, 0); > + CloseHandle(sei.hProcess); > + } Does this actually work? Our tests are non-interactive, and should never leave stray windows open when the test finishes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149679

1 0