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

Re: [PATCH v5 0/4] MR11710: msvcrt: Don't inherit std fd attributes. - approved
by Alexandre Julliard (＠julliard) Aug. 21, 2026

Aug. 21, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11710

1 0

[PATCH 0/1] MR11723: appwiz.cpl: Fix default_dir lookup
by Ken Sharp (＠imwellcushtymelike) Aug. 21, 2026

Aug. 21, 2026

Refactored to include the default prefix of `/usr/local/share` from configure. Declaring `WCHAR data_dirs[]` fixed this anyway. Left in as a fallback. Package managers may add/remove packages from `/usr/share/wine`, so `/usr/local/share/wine` is very handy (particularly when bisecting). The TRACEs helped a lot here, so left some behind. Symptom: Wine would insist that packages I downloaded manually to `/usr/local/share/wine/mono` had to be downloaded again (to `~/.cache`). The new Mono package is not ready/installed locally at time of writing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11723

3 6

[PATCH 0/2] MR11719: rometadata: Add additional tests for WinRT metadata shipped with Windows
by Vibhav Pant (＠vibhavp) Aug. 21, 2026

Aug. 21, 2026

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

3 8

[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