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

[PATCH 0/4] MR10104: user32/edit: Reset capture on WM_LBUTTONDOWN if already enabled
by Ivan Ivlev (＠iviv) March 3, 2026

March 3, 2026

Edit control does not release mouse capture after WM_LBUTTONDOWN has been processed two times in a row. This MR fixes this issue by releasing capture and setting it again on WM_LBUTTONDOWN if window was already captured. I have stumbled upon the app in which edit control process WM_LBUTTONDOWN twice on one mouse click. While in windows it causes no problem, wine edit does not release capture, so other buttons inside this app become unclickable. It happens because when WM_LBUTTONDOWN is processed twice, WM_CAPTURECHANGED is sent and bCaptureState is set to FALSE, then EDIT_WM_LButtonUp does not release capture because bCaptureState is already FALSE. Thing about tests: I have added test case for this problem to be visible. I also had to use todo_wine because SendMessageA for WM_LBUTTONDOWN and WM_LBUTTONUP returns 0 in wine and 1 in windows (which is not the case for combobox test, where SendMessageА for WM_LBUTTONDOWN also returns 1 in wine). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10104

4 7

[PATCH 0/1] MR10059: comctl32: Fix the bug when the cInitial is too large which lead to...
by Kun Yang (＠yangkun) March 3, 2026

March 3, 2026

I'm sorry I have pushed another mr for this topic due to my fault for pushing to the master branch of my forked project. This is about the failure of CreateDIBSection in ImageList_Create. Last discussion is in !10039 (https://gitlab.winehq.org/wine/wine/-/merge_requests/10039) I have made my last fix in https://gitlab.winehq.org/wine/wine/-/merge_requests/10039#note_129134. Please review it again @zhiyi . I am sorry for making a new merge request again. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10059

3 2

[PATCH 0/1] MR10213: winmm/tests: Reserve additional memory in test_formats (ASan).
by Bernhard Übelacker March 3, 2026

March 3, 2026

Followup of fe239731. In `test_formats` only `sizeof(WAVEFORMATEXTENSIBLE)` gets allocated, but in `WINMM_OpenDevice` it tries to read one addional byte in the "cbSize += 1" test. CC: @giomasce [Test pattern page](https://test.winehq.org/data/patterns.html#winmm:wave) (This patch won't help here.) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=162097) (Shows also the other issues like the test pattern page.) <details> <summary>ASan details [gitlab ci run](https://gitlab.winehq.org/bernhardu/wine/-/jobs/232675#L2501)</summary> ``` ==winmm_test.exe==320==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0022fc78 at pc 0x784c4532 bp 0x04d3fbec sp 0x04d3f7bc READ of size 41 at 0x0022fc78 thread T243 #0 0x784c4531 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x78f3210e in WINMM_OpenDevice /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:1124:9 #2 0x78f30aad in WOD_Open /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:1277:11 #3 0x78f3638e in WINMM_DevicesMsgProc /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:2393:16 #4 0x7b13b573 in WINPROC_wrapper (C:\windows\system32\user32.dll+0x1004b573) #5 0x7b13bdf3 in call_window_proc /builds/bernhardu/wine/build64/../dlls/user32/winproc.c:111:15 #6 0x7b13beea in dispatch_win_proc_params /builds/bernhardu/wine/build64/../dlls/user32/winproc.c #7 0x7b13c807 in User32CallWinProc /builds/bernhardu/wine/build64/../dlls/user32/winproc.c:827:14 #8 0x7be1dc86 in dispatch_user_callback /builds/bernhardu/wine/build64/../dlls/ntdll/exception.c:297:18 #9 0x7be46a62 in KiUserCallbackDispatcher /builds/bernhardu/wine/build64/../dlls/ntdll/signal_i386.c:205:23 #10 0x79d81d3b in NtUserPeekMessage (C:\windows\system32\win32u.dll+0x10011d3b) #11 0x78f361d6 in WINMM_DevicesThreadProc /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:2475:16 #12 0x784d6f21 in asan_thread_start(void*) /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_win.cpp:147:14 #13 0x7be4678a in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc4678a) #14 0x7be470fa in call_thread_func /builds/bernhardu/wine/build64/../dlls/ntdll/signal_i386.c:503:9 Address 0x0022fc78 is located in stack of thread T0 at offset 56 in frame #0 0x0043676f in test_formats /builds/bernhardu/wine/build64/../dlls/winmm/tests/wave.c:2434 This frame has 1 object(s): [16, 56) 'fmt' (line 2455) <== Memory access at offset 56 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:1124:9 in WINMM_OpenDevice ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10213

3 4

[PATCH 0/3] MR10224: winmm: Initialize the audio client with AUTOCONVERTPCM.
by Giovanni Mascellani (＠giomasce) March 3, 2026

March 3, 2026

Currently nothing changes, but eventually the audio client will start rejecting formats that require channel or sample rate conversion if AUTOCONVERTPCM is not specified. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10224

3 4

[PATCH v7 0/3] MR9704: winmm, msvfw32: DGV window shenanigans with audio only files
by Bernhard Kölbl March 3, 2026

March 3, 2026

Basically, check if we can set a HWND in the driver, before doing so. Right now, msvfw32 + mciqtz32 error out on audio only playbacks, breaking the game Transcendence. -- v7: msvfw32: Only attempt to set a digital-video window, when the driver has a window itself. msvfw32/tests: Add a basic audio playback test. winmm/tests: Test digital-video window behavior for audio files. https://gitlab.winehq.org/wine/wine/-/merge_requests/9704

3 4

Re: [PATCH v28 0/1] MR9442: comctl32/treeview: check for child item before SendExpanding
by Zhiyi Zhang (＠zhiyi) March 3, 2026

March 3, 2026

On Tue Mar 3 10:12:36 2026 +0000, Thomas Csovcsity wrote: > I had a deeper look at the app behavior and tried to write a small app > reproducing it without success. > Following code flow and app behavior triggers the error, but i am not > sure which additional conditions are necessary to reproduce this. > - the app is actively deleting child items from node, after receiving TVN_ITEMEXPANDINGW > - without changing `item->state |= TVIS_EXPANDED;` the next mouse click > triggers a toggle, but this code still assumes that the node is > expanded, therefore it takes the wrong branch. > If i follow the rules > https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines, i am > stuck here to write a small app to reproduce the bug or to write a test > for this case. > Any hint is appreciated or please close this MR otherwise with a note. I would suggest writing a test that takes the code to execute on the wrong path, thus reproducing the bug. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9442#note_131083

1 0

[PATCH v2 0/6] MR9348: comctl32/imagelist: Pre-multiply rgb by the alpha channel in add_dib_bits for v6.
by Ziqing Hui (＠zhui) March 3, 2026

March 3, 2026

We used to do this when drawing the image. But our tests show that for v6, the image bitmaps have been alpha pre-multiplied before drawing. So we should do this when adding images. -- v2: comctl32/imagelist: Support adding 32bpp images to a non-32bpp image list for v6. comctl32/imagelist: Do alpha blending when adding 32bpp images to a non-32bpp image list. comctl32/imagelist: Introduce create_dib_section helper. comctl32/imagelist: Introduce image_list_color_flag helper. comctl32/imagelist: Pre-multiply rgb by the alpha channel in add_dib_bits for v6. comctl32/imagelist: Introduce premultiply_alpha_channel helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/9348

3 8

[PATCH 0/1] MR10238: winebus.sys: Prefer hidraw for all VKB (VID 231d) devices.
by Rémi Bernon March 3, 2026

March 3, 2026

Original patch from Ty (Chaos). Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/10226 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10238

1 1

[PATCH 0/6] MR10223: Wininet refactors
by Reyka Matthies (＠tmatthies) March 3, 2026

March 3, 2026

This is the second set of patches towards the mfplat network bytestream, after !9369. Mostly preparatory work and refactors. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10223

3 9

[PATCH 0/1] MR10233: dsound: fir.h is no longer a generated file.
by Sven Baars (＠sbaars) March 3, 2026

March 3, 2026

The coefficients are still being generated, but the code generating them is located in fir.h, so changes to this file need to be reviewed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10233

3 2