August 2026 - Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR11729: kerberos: Don't access Lsa mode data in user mode functions.
by Piotr Caban (＠piotr) Aug. 21, 2026

Aug. 21, 2026

-- v2: kerberos: Don't access Lsa mode data in user mode functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/11729

2 2

[PATCH 0/2] MR11729: kerberos: Don't access Lsa mode data in user mode functions.
by Piotr Caban (＠piotr) Aug. 21, 2026

Aug. 21, 2026

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

2 2

[PATCH 0/3] MR11727: gdiplus/metafile: Fix emf+ image rendering
by Tobi Laskowski (＠tobil) Aug. 21, 2026

Aug. 21, 2026

The documentation says that the upper-left, upper-right, and lower-left corners should be passed in. However, the code was incorrectly passing the lower-right corner instead of the lower-left, resulting in skewed rendering. https://learn.microsoft.com/en-us/windows/win32/api/gdiplusgraphics/nf-gdip… Before: ![image.png](/uploads/99a36aa98590a141cad695275f4ec1f8/image.png){width=141 height=145} After: ![image.png](/uploads/68a7acd512824392c57cd7dfc5f1ba95/image.png){width=132 height=137} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11727

3 4

[PATCH v3 0/6] MR11720: wined3d: Various.
by Elizabeth Figura (＠zfigura) Aug. 21, 2026

Aug. 21, 2026

-- v3: wined3d: Allow disabling video decoding support. dxgi: Implement D3D11_CREATE_DEVICE_VIDEO_SUPPORT. https://gitlab.winehq.org/wine/wine/-/merge_requests/11720

5 10

Re: [PATCH v2 0/1] MR11318: winebus: Coalesce pending SDL axis input reports.
by Rémi Bernon (＠rbernon) Aug. 21, 2026

Aug. 21, 2026

On Thu Jul 9 08:34:10 2026 +0000, Rémi Bernon wrote: > I will have a closer look but it might take some time, and I'll be out > for a couple of weeks as well. Fwiw this might be okay, but SDL is only > one of the multiple backends we have, and we may want to have something > similar elsewhere. > Also I believe (but that may need to be confirmed that it's still the > case) there's other performance bottlenecks in the HID device path, and > if a device is pushing a high volume of events, it's probably going to > impact wineserver badly anyway. This is because of our current NT device > I/O, which I believe does several wineserver roundtrips for IRP processing. So my opinion is that this will cause some potential input loss, especially with quick motion, which may even happen randomly just because one read was a little bit too late for some reason, and not only under heavy load. If we are unable to keep up with high polling rate devices we need to find exactly where the bottlenecks are and fix it there. It is not obvious to me that the SDL polling loop is the bottleneck, but if it is it will need to be measured more exactly. The whole roundtrip between the hardware / Linux, or even just between the received SDL event, and the XInput frontend includes too many intermediate and much heavier layers, like the NT device IO, for which I'm much more confident that are a source of contention / load / delay. If this polling loop is a bottleneck it can easily be measured with some QPC calls around two successive SDL_WaitEventTimeout calls. As far as I can tell here, it's in the order of a couple microseconds, so should be fast enough to cope with events coming at several kHz at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11318#note_149538

1 0

[PATCH v8 0/3] MR11699: win32u and explorer: Exclude taskbar and appbars from system work area rect
by Andrea Faulds (＠hikari_no_yume) Aug. 21, 2026

Aug. 21, 2026

This is a package of changes that fix https://bugs.winehq.org/show_bug.cgi?id=59976 and possibly other issues. It is both a usability and a compatibility improvement. Please see the commit messages for further details. Feedback on if anything here is reasonable to write conformance tests for would be appreciated. I don't know if it makes sense for the IPC things. I did a bunch of manual testing of how Windows and WINE behave using two small test programs: [appbar.c](/uploads/49ed846bdbd32bfecdb0603304f5c332/testapp.c) and [workarea.c](/-/project/5/uploads/ab8f82c70d8df1e337e8b15be5f32cab/workarea.c). --- Before these changes: ![Screenshot From 2026-08-18 21-20-09.png](/uploads/75181aa0e0816399d1705a61ea8a21a0/Screenshot_From_2026-08-18_21-20-09.png){width="729" height="600"} ![Screenshot From 2026-08-18 21-20-14.png](/uploads/988c8becadd9ba1f928b9a50e4eda290/Screenshot_From_2026-08-18_21-20-14.png){width="729" height="600"} Note how: * The Office 97 Shortcut Bar is covering up part of the taskbar. This is worse if it's docked to the right (which is the default), because then it covers up system tray icons. * The maximized Word 97 window is covering up both the taskbar and the Shortcut Bar. After these changes: ![Screenshot From 2026-08-18 21-21-52.png](/uploads/56376b4356fd3a6b67c9596bd2271b25/Screenshot_From_2026-08-18_21-21-52.png){width="729" height="600"} You'll notice that the Word window here is still overhanging both the taskbar and the Shortcut Bar. I believe that's correct behavior as maximized windows always overhang the screen, and it just looks weird because WINE doesn't support `WS_EX_TOPMOST` yet in desktop mode. -- v8: explorer: Update system work area rect to exclude taskbar and appbars explorer: Account for the actual size of the taskbar if it is visible https://gitlab.winehq.org/wine/wine/-/merge_requests/11699

3 5

[PATCH 0/1] MR11717: faudio: Initialize COM before creating the WMA decoder.
by Nello De Gregoris (＠bluechxin) Aug. 21, 2026

Aug. 21, 2026

Found while testing STEINS;GATE RE:BOOT (https://store.steampowered.com/app/4012810/STEINSGATE_REBOOT/) The visual novel voiceovers were not playing and every time one was supposed to play, the following showed up in logs: `err:ole:com_get_class_object apartment not initialised` Tracing this led me to `FAudio_WMADEC_init`, which runs CoCreateInstance on the thread the application called IXAudio2::CreateSourceVoice() from, with FAudio however never initializing COM on that path. That makes combase then reject the call with the decoder never being created. I believe most games don't run into this because Media Foundation is usually initialized before this code path is hit, which leaves a process-wide MTA in place. Since the voiceovers play correctly on Windows, handling it in FAudio seemed like the right call. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11717

5 8

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

Aug. 21, 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

4 7

[PATCH v3 0/2] MR11600: ntdll: Handle the MEM_LARGE_PAGES and MEM_PHYSICAL allocation flags.
by Allan Vester (＠AllanVester) Aug. 21, 2026

Aug. 21, 2026

The flag combination shows up in Forza Motorsport, which allocates a 14 MB staging pool with MEM_COMMIT|MEM_RESERVE|MEM_PHYSICAL|MEM_LARGE_PAGES and does not check the result, so under Wine it runs on a NULL pointer. Behaviour measured on real Windows with the Test Bot (job 163938, `ntdll_test.exe virtual`, 64 bit, SeLockMemoryPrivilege not held on any VM): | type | Win7 | Win8.1 | 10-1507 | 10-22H2 | Win11 | Wine before | |---|---|---|---|---|---|---| | `0x3000` COMMIT\|RESERVE | 0 | 0 | 0 | 0 | 0 | 0 | | `0x20003000` +LARGE | c0000061 | c0000061 | c0000061 | c0000061 | c0000061 | c000000d | | `0x402000` RESERVE\|PHYSICAL, RW | 0 | 0 | 0 | 0 | 0 | c000000d | | `0x402000` RESERVE\|PHYSICAL, EXEC | - | c00000f4 | c00000f4 | c0000045 | c0000045 | c000000d | | `0x403000` COMMIT\|RESERVE\|PHYSICAL | - | c00000f3 | c00000f3 | c000000d | c000000d | c000000d | | `0x20403000` PHYSICAL\|LARGE | c00000f3 | c00000f3 | c00000f3 | 0 | 0 | c000000d | | `0x80003000` +4MB_PAGES | - | c00000f3 | c00000f3 | c000000d | c000000d | c000000d | Two things the patch deliberately does not do: * It does not implement the large page size alignment rule. An unaligned request now returns STATUS_PRIVILEGE_NOT_HELD where 10-22H2 and 11 return STATUS_INVALID_PARAMETER, because <= 10-1507 check the privilege first and the later versions check the alignment first. The test traces that case but does not assert it. * AWE itself stays unimplemented. The reservation succeeds and AllocateUserPhysicalPages() still fails with its existing FIXME, instead of the reservation failing with a status that says the arguments were wrong. Verified in three states: the tests alone on Wine report the five assertions as todo with no failures, the same binary passes on the seven Windows VMs above, and tests plus fix report no todo and no failures. -- v3: ntdll: Handle the MEM_LARGE_PAGES and MEM_PHYSICAL allocation flags. ntdll/tests: Test MEM_LARGE_PAGES and MEM_PHYSICAL allocation flags. https://gitlab.winehq.org/wine/wine/-/merge_requests/11600

3 5

[PATCH 0/5] MR11728: ntdll: Partial support for MEM_PHYSICAL and MEM_LARGE_PAGES.
by Alexandre Julliard (＠julliard) Aug. 21, 2026

Aug. 21, 2026

As an alternative to !11600. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11728

2 5