- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10054: mf: Don't perform preroll if we are scrubbing.
by Brendan McGrath (＠redmcg) Feb. 9, 2026

Feb. 9, 2026

Tests on Windows show that a preroll isn't requested by the media session if rate is zero. This MR changes media session to match that behaviour. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10054

3 2

[PATCH 0/2] MR10053: mf: Fix crash when stream is null during sample request.
by Brendan McGrath (＠redmcg) Feb. 9, 2026

Feb. 9, 2026

Windows waits until it receives the MEStreamStarted event(s) before subscribing to the sink event queues. This is the successor to MR !9716. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10053

3 3

Re: [PATCH v7 0/6] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. - closed
by Kun Yang (＠yangkun) Feb. 9, 2026

Feb. 9, 2026

This merge request was closed by Kun Yang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

1 0

[PATCH v6 0/6] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) Feb. 9, 2026

Feb. 9, 2026

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v6: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 7

[PATCH v5 0/5] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) Feb. 9, 2026

Feb. 9, 2026

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v5: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 5

[PATCH v4 0/4] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) Feb. 9, 2026

Feb. 9, 2026

When I was porting a software from windows, I met a problem that the icons in the imagelist were not displaying correctly. In the Application, the correct icons are: ![1](/uploads/9d474b7fa9447c9ff7ada8515a4dc07b/1.bmp){width=269 height=29} But when I run it under wine is like this: ![2](/uploads/8b69186797c6e3542fe371ff6c4f6b0a/2.bmp){width=271 height=29} When I disassable the application code I found that the Application calls ImageList_Create by given a very large cInitial, which is 0xc0c0c0. This will lead to CreateDIBSection fail. Then the source hbitmap is lost, only hMask is left and shown up on the screen. I use windbg to debug this application on windows, I found that after ImageList_Create is called on Winodws, there is a valid hbitmap handle generated. When ImageList_Add is called for 4 times, it changed and called Bitblt to copy the hbitmap already added. So I guess windows has the error handling for ImageList_Create. If CreateDIBSection failes due to the large image count, it reduced the image count. By observing the action in ImageList_Add, I think the reduced count is 1 (4x1). Then fix the cMaxImage to 1+1 which is same as ImageListImpl_Initialize to make the hbitmap expand. The example in the attachment can reproduce this bug. [imagelist.7z](/uploads/b5f7013fa9383c00bbbc38f82383ff1a/imagelist.7z) -- v4: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

2 4

Re: [PATCH v9 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) Feb. 9, 2026

Feb. 9, 2026

v9: - Add zero padding at the ends of the FIR. This is required for correct linear interpolation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_129130

1 0

[PATCH v8 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) Feb. 9, 2026

Feb. 9, 2026

This implements a number of optimizations, in particular: - Swapping around the resampling loops in case of downsampling, allowing the FIR step to stay fixed regardless of the resampling ratio. - Rearranging the FIR array elements to make the access sequential. - Adding SSE versions of the resampling functions. Together, these amount to more than a 5x reduction of `cp_fields_resample` execution time. The quality of the resampling should be the same, or even improve slightly, due to a more precise `rem` calculation and removal of the FIR step rounding, although I haven't yet conducted any measurements. **UPDATE** Added some more optimizations: - Using fixed point math inside the resampling functions. - Optimizing the SSE versions by hand. - Adding AVX+FMA3 versions of the resampling functions. - Getting and putting all channel samples in one go. Combined with the previous ones, these bring the total speedup to 15x for upsampling and 13x for downsampling compared to the upstream. -- v8: dsound: Initialize freqAccNum to freqAdjustDen / 2. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/9928

1 1

Re: [PATCH v7 0/34] MR9928: Draft: dsound: Speed up resampling.
by Anton Baskanov (＠baskanov) Feb. 9, 2026

Feb. 9, 2026

v7: - Fix `mixpos` calcluation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9928#note_129124

1 0

[PATCH v2 0/2] MR10008: start: Fix arg parsing for quoted paths ending with backslash.
by Yeshun Ye (＠yeyeshun) Feb. 9, 2026

Feb. 9, 2026

When using the `start` command with a `/d` switch specifying a quoted path that ends with a backslash (e.g., `start /d "c:\path\" app.exe`), subsequent arguments were incorrectly concatenated into the path string due to parsing ambiguity. The error I encountered was with `start /d "c:\temp\" test.exe`, which was parsed into the arguments `/d` and `"c:\temp\" test.exe`. The path and the executable were merged into a single argument as a new path, preventing the child process from launching. In my first patch, I attempted to identify and split this combined argument, but this caused test failures in `kernel32`. I then retested on Windows and found that Windows also parses it as `/d` and `"c:\temp\" test.exe`—Wine's parsing is consistent with Windows. However, `start` works correctly on Windows because it is a built-in command, whereas in Wine, `start` is an external executable, leading to different behavior. Signed-off-by: YeshunYe yeyeshun(a)uniontech.com -- v2: start: Refactor command line argument parsing functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10008

3 5