May 2025 - Wine-gitlab - list.winehq.org

[PATCH v13 0/4] MR6855: server: Fix renaming file to a hardlink of itself.
by Gabriel Ivăncescu 26 Nov '25

26 Nov '25

-- v13: server: Handle hardlinks and casefolding when renaming the same file. server: Handle renames to destinations containing trailing slashes. kernel32/tests: Test renaming a file into a hardlink of itself. kernel32/tests: Use FindClose instead of CloseHandle when closing https://gitlab.winehq.org/wine/wine/-/merge_requests/6855

3 12

[PATCH 0/4] MR6462: winemac: Use win32u for move/resize window SysCommand.
by Rémi Bernon 21 Nov '25

21 Nov '25

It's not completely clear what exactly it was doing differently from win32u, but keeping the captions within the work area is probably fine for win32u, and de-duplicating this code is probably a good thing and makes later changes for DPI-based virtual display settings easier. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6462

1 6

[PATCH 0/4] MR7512: win32u: Introduce shared memory objects for windows.
by Rémi Bernon 21 Nov '25

21 Nov '25

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

4 29

[PATCH 0/1] MR7257: winex11: Get rid of x11drv_win_data use_alpha flag.
by Rémi Bernon 21 Nov '25

21 Nov '25

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

1 3

[PATCH 0/1] MR4078: dmime/tests: Mark 3 PMsg tests as flaky
by Michael Stefaniuc (＠mstefani) 17 Nov '25

17 Nov '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55637 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4078

4 9

[PATCH v3 0/1] MR5809: winecrt0, msvcrt: Implement static constructor support.
by Rémi Bernon 15 Nov '25

15 Nov '25

-- v3: winecrt0: Implement static constructors support. https://gitlab.winehq.org/wine/wine/-/merge_requests/5809

3 8

[PATCH v6 0/4] MR1825: kernelbase/path.c: UrlFixupW()
by Thomas Csovcsity (＠thc13) 14 Nov '25

14 Nov '25

## Summary Tests for UrlFixupW and semi stub function implementaion. ## Test results - Tests are 100% ok on my local WIN 10 pc. Wine test bot seems to be okay too. - Wine tests on debian machine | function type | result | | ------ | ------ | | stub | 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **200** failures), 0 skipped. | | semi stub| 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **100** failures), 0 skipped. | ## Todos For follow up merge request(s). - [ ] Add more tests for priority investigation, who url scheme fix up is working on windows. - [ ] Implement missing parts of fix up. ## Conclusion Semi stub implementation is an improvement to the existing solution. A grep showed that wine internals do not call this function, therefore it should not introduce any new bugs. Windows applications using/relying on the function should now work better, if not they may reveal already existing bugs. -- v6: shlwapi: fixup leading and trailing typos in UrlFixupW shlwapi: check for colon in UrlFixupW kernelbase: Restructure UrlFixupW() shlwapi/tests: Add tests for UrlFixupW. https://gitlab.winehq.org/wine/wine/-/merge_requests/1825

3 11

[PATCH v23 0/6] MR6166: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) 09 Nov '25

09 Nov '25

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) 09 Nov '25

09 Nov '25

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/1] MR5890: winex11.drv: Fix a possible desktop window message queue hang.
by Zhiyi Zhang (＠zhiyi) 06 Nov '25

06 Nov '25

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