October 2025 - Wine-GitLab - list.winehq.org

[PATCH v23 0/6] MR6166: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) Nov. 9, 2025

Nov. 9, 2025

Because WINENV is limited (32767 bytes), and HOSTENV can be much larger, a whitelisting approach is used to keep WINENV as small as possible. Currently, only the following envvars are propagated from the host env to WINENV WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE Moreover, the NIXENV (env for running wine processes - not applications) on the host system is not produced from WINENV anymore, but the global ENV is propagated to all wine processes and threads. This might be an alternative approach to MR!5231, MR!6140, bug #56941 and should provide a more deterministic behaviour of wine, because unrelated envvars do have no influence on the env for running windows applications. Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects. Moreover, this is my first merge request, so your feedback is highly appreciated. -- v23: ntdll: main_envp has been replaced by environ ntdll: remove is_dynamic_env_var(...) because it is not needed anymore ntdll: remove unused vars ntdll: remove dead code ntdll: conversion from HOSTENV to WINENV is now using whitelisting instead of blacklisting of envvars currently only envvars "WINE"<special_var> (as defined in is_special_env_var() ) are whitelisted. ntdll: separate env for windows applications (WINENV) from env for wine processes (NIXENV) WINENV is typically limited to 32767 WCHAR, the host environment where wine processes are running can be much larger. Keeping the two envs separate enables a more granula handling of envvars. (see also MR!5231, MR!6140, bug #56941) https://gitlab.winehq.org/wine/wine/-/merge_requests/6166

4 8

[PATCH 0/1] MR7901: ntdll: Treat XDG_DATA_DIRS as special env variable.
by Louis Lenders (＠xe) Nov. 9, 2025

Nov. 9, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49987 GTK apps seem to use this env var to find path to schemas, like Meld: https://download.gnome.org/binaries/win32/meld/3.22/Meld-3.22.2-mingw.msi which doesn't start at all without this patch. More info in https://bugs.winehq.org/show_bug.cgi?id=49987. v2: add WINEXDG_DATA_DIRS and use that in winemenubuilder. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7901

4 4

[PATCH v2 0/2] MR9312: d2d1: Add support for using IWICBitmapLock with CreateSharedBitmap()
by Jason Wendt (＠jason.wendt) Nov. 8, 2025

Nov. 8, 2025

I found this deficiency while trying to run Paint.NET v4.0. -- v2: d2d1: Add support for using IWICBitmapLock with CreateSharedBitmap() d2d1/tests: Add a test for using IWICBitmapLock with CreateSharedBitmap() https://gitlab.winehq.org/wine/wine/-/merge_requests/9312

3 5

[PATCH 0/4] MR9270: winex11: Prevent larger than monitor window resizes.
by Rémi Bernon Nov. 7, 2025

Nov. 7, 2025

This prevents WMs like KWin or Mutter from automatically maximizing windows which frames are larger than their monitor area. The maximization otherwise gets fed back into the win32 state, and often confuses applications which are operating a fullscreen window change by resizing a window then later changing its decoration. It isn't possible to tell between a maximization initiated by the user and one that is initiated by the WM responding to a window resize from us. This heuristic should hopefully be good enough, as it is unlikely that the user will ever be able to resize a window in a such a way that its *frame* covers a monitor entirely. Note that if the user resizes a window such that its *visible* area covers a monitor entirely, we are going to make it fullscreen already anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9270

3 8

[PATCH v2 0/1] MR5890: winex11.drv: Fix a possible desktop window message queue hang.
by Zhiyi Zhang (＠zhiyi) Nov. 7, 2025

Nov. 7, 2025

After an X11 event handler queues messages to another thread, TRUE should be returned and eventually propagated to X11DRV_ProcessEvents(). When FALSE is always returned in xrandr14_device_change_handler(), a possible hang can happen for the desktop message queue as follows: 1. The explorer.exe calls GetMessageW() -> NtUserGetMessage() -> wait_objects() -> wait_message(). 2. In wait_message(), user_driver->pProcessEvents() gets called in the desktop window thread to handle RRNotify events and calls xrandr14_device_change_handler() -> display_mode_changed(FALSE) -> send_message(get_desktop_window(), WM_DISPLAYCHANGE, ...) -> desktop_window_proc() -> send_message_timeout() -> send_client_message() -> process_message() -> broadcast_message() -> send_message_timeout() -> send_client_message() -> process_message() -> send_inter_thread_message() -> wait_message_reply() -> a server set_queue_mask() with skip_wait being 1 -> wake_mask and changed_mask are set to 0. 3. In wait_message(), user_driver->pProcessEvents() returns FALSE from xrandr14_device_change_handler(). So wait_message() continues to call NtWaitForMultipleObjects(). 4. Now NtWaitForMultipleObjects() hangs for INFINITE timeout because wake_mask and changed_mask for the message queue are set to 0 so the thread is not woke up. The hang is sensitive to message ordering and only happens in this specific case so it's hard to reproduce with tests. I believe some of the past test timeouts on TestBots can be attributed to this bug. -- v2: winex11.drv: Fix a possible desktop window message queue hang. https://gitlab.winehq.org/wine/wine/-/merge_requests/5890

2 2

[PATCH v2 0/1] MR9103: ntdll/unix: Explicitly cast to XSAVE_FORMAT* before dereferencing FPUX_sig
by Thibault Payet (＠thpayet) Nov. 6, 2025

Nov. 6, 2025

This will fixes build on FreeBSD targeting i386. -- v2: ntdll/unix: Explicitly cast the NULL value for FPU_sig, FPUX_sig and XState_sig to the correct one https://gitlab.winehq.org/wine/wine/-/merge_requests/9103

4 6

[PATCH 0/1] MR9184: sane.ds: Adding saving scanner settings to the registry
by Ivan Lyugaev (＠valy) Nov. 6, 2025

Nov. 6, 2025

The latest scanner settings are now automatically saved in the HKEY_CURRENT_USER\Software\ScannersSettings\Vendor\Product path. This modification was tested and worked correctly This is the second MR on this topic, and the first MR has been approved for a month, but it has not been added without merge :disappointed: Link: https://gitlab.winehq.org/wine/wine/-/merge_requests/8858 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9184

5 11

[PATCH v2 0/1] MR7897: kernel32/tests: Skip FreeConsole test at Windows 7.
by Bernhard Übelacker Nov. 5, 2025

Nov. 5, 2025

Followup of 13c77bc9e6. [Test pattern page](https://test.winehq.org/data/patterns.html#kernel32:console) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=158074) -- v2: kernel32/tests: Skip FreeConsole test at Windows 7. https://gitlab.winehq.org/wine/wine/-/merge_requests/7897

3 7

[PATCH v2 0/1] MR9067: windows.storage: Redirect SHGetKnownFolderPath() to shell32.
by Andrey Gusev (＠agusev) Nov. 5, 2025

Nov. 5, 2025

Fixes a crash with GamingRepair for Senua's Saga: Hellblade II. -- v2: windows.storage: Redirect SHGetKnownFolderPath() to shell32. https://gitlab.winehq.org/wine/wine/-/merge_requests/9067

3 3

[PATCH 0/2] MR9311: dwrite, win32u: Stop supporting very old FreeType versions.
by Brendan Shanks (＠bshanks) Nov. 4, 2025

Nov. 4, 2025

The new requirement is v2.5.0 (released in June 2013). If we wanted to go farther, the next stop would be v2.8.1 (released September 2017). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9311

4 6