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

[PATCH v6 0/2] MR2545: winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID
by Yeshun Ye (＠yeyeshun) Nov. 30, 2025

Nov. 30, 2025

winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID winmm/tests: Add flags tests for mixerGetLineControlsA/W support MIXER_GETLINECONTROLSF_ONEBYID and MIXER_GETLINECONTROLSF_ONEBYTYPE Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- v6: winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID winmm/tests: Add flags tests for mixerGetLineControlsA/W https://gitlab.winehq.org/wine/wine/-/merge_requests/2545

2 3

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

Nov. 21, 2025

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/1] MR4078: dmime/tests: Mark 3 PMsg tests as flaky
by Michael Stefaniuc (＠mstefani) Nov. 17, 2025

Nov. 17, 2025

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

3 7

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

Nov. 15, 2025

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

3 7

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

Nov. 14, 2025

## 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

2 7

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

Nov. 6, 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 0/1] MR3228: Update heap.c removed return NULL at line 985. Prevents Wing Commander...
by James Carthew (＠dmjc) Oct. 28, 2025

Oct. 28, 2025

Update heap.c removed return NULL at line 985. Prevents Wing Commander Prophecy and Secret Ops for loading/playing. Fixes WINE bug 55176. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3228

5 4

[PATCH v3 0/2] MR1321: Reject wic invalid formats
by Zhiyi Zhang (＠zhiyi) Oct. 21, 2025

Oct. 21, 2025

These invalid formats are rejected when creating WIC render targets. Otherwise, Wine may create a WIC render target with an unsupported format and in turn, will make testing IsSupported() method difficult. -- v3: d2d1: Test creating WIC bitmap render targets. d2d1: Reject unsupported formats when creating WIC bitmap render targets. https://gitlab.winehq.org/wine/wine/-/merge_requests/1321

3 6

[PATCH 0/1] MR3880: ntdll: Only declare/set wow_teb on platforms using it
by Gerald Pfeifer (＠gerald) Oct. 17, 2025

Oct. 17, 2025

Otherwise we see dlls/ntdll/unix/signal_x86_64.c:2351:14: warning: unused variable 'wow_teb' on FreeBSD. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3880

4 4

[PATCH 0/1] MR6140: ntdll: Exclude biggest envars to fit 32767 chars limit in get_initial_environment.
by Martino Fontana (＠tinozzo123) Oct. 11, 2025

Oct. 11, 2025

Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en… Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes. With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded. This is useful when a user has very long environment variables in their system for reasons unrelated to Wine. Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941 Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6140

7 12