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

[PATCH 0/1] MR10974: mfreadwrite: Do not return NEED_MORE_INPUT from source_reader_push_transform_samples().
by Conor McCarthy (＠cmccarthy) Aug. 6, 2026

Aug. 6, 2026

MF_E_TRANSFORM_NEED_MORE_INPUT is only relevant when pulling samples. Fixes an issue where only one sample can be drained from a decoder in source_reader_pull_transform_samples() if another transform is present downstream. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10974

3 5

[PATCH 0/1] MR11534: documentation: Update macOS version.
by Dean M Greer (＠Gcenx) Aug. 6, 2026

Aug. 6, 2026

The lowest version of macOS wine now compiles on is macOS Catalina (10.15) so make that the new minimum. I've updated the other languages as best I could but some are extremely outdated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11534

3 7

[PATCH 0/7] MR11360: win32u: Allow GL contexts on the unix side without a client context handle.
by Rémi Bernon (＠rbernon) Aug. 6, 2026

Aug. 6, 2026

I believe this makes the unix/PE split cleaner removing some weird opengl32 / win32u unix side cooperation, and would make it possible for other modules (ie: wined3d) to use OpenGL on the unix side using the win32u `__wine_get_opengl_driver` / `opengl_funcs` interface. That interface only implements a subset of the wgl API, but it should be enough to create unix-side only rendering contexts, set window pixel formats (including D3D internal format) to create drawables for HDCs, and render whatever we need to render. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11360

2 8

[PATCH v3 0/1] MR11373: Improve wow64_NtUserGetPointerInfoList.
by Bernhard Übelacker (＠bernhardu) Aug. 6, 2026

Aug. 6, 2026

Hello, I noticed a failure in win32u:win32u, probably related to !11332. I tried to take a look and it seems a new-wow64 only issue. I came up with this patches transferring the 64-bit structs into 32-bit one. Are they going into the right direction? These patches fix the failure in win32.c:1974, but they introduce now a new wow64-only failure with win32.c:1935, the last invalid_ptr test. I can see at the 64-bit side we hit the SIGSEGV, but somehow at the 32-bit side it still returns without failure. Somehow I fail to find any other similar wow64 function that has special handling of invalid pointers, what I am missing? [Test pattern page](https://test.winehq.org/data/patterns.html#win32u:win32u) CC: @rbernon -- v3: wow64win: Improve wow64_NtUserGetPointerInfoList. https://gitlab.winehq.org/wine/wine/-/merge_requests/11373

3 4

[PATCH 0/2] MR8861: shell32: Accept CSIDL values in SHBrowseForFolderW().
by Attila Fidan (＠atticf) Aug. 5, 2026

Aug. 5, 2026

This fixes an access violation when clicking the button to browse for an installation directory in some installers using the BURIKO (BGI/Ethornell) engine. The affected applications call `SHBrowseForFolderA(&bi)` with `bi.pidlRoot` being 0x11, which causes wine to dereference 0x11 inside InitializeTreeView. On native, this opens the treeview from My Computer. 0x11 is the CSIDL value for My Computer, and passing any pidlRoot from 0 to 2^16 will not crash on native like resource IDs. If an invalid folder value is used then native returns 0 without showing a window. If I delete the My Pictures folder then use `CSIDL_MYPICTURES`, the folder gets recreated. None of this works if `BIF_NEWDIALOGSTYLE` is used, native crashes with access violation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8861

3 6

[PATCH v2 0/2] MR11524: Align handle objects allocated for SymCrypt
by Ivan Lyugaev (＠valy) Aug. 5, 2026

Aug. 5, 2026

On Debian 11, when installing dotnet40, crashes are observed in different places within bcrypt/rsaenh. The reason is that some objects contain internal SymCrypt states (SYMCRYPT_HASH_STATE, SYMCRYPT_HMAC_STATE, etc.) that require correct alignment when using SSE. The crash may occur in different SymCrypt calls depending on which object happened to be misaligned. The fix allocates these objects with aligned allocation and frees them accordingly. -- v2: rsaenh: Align handle objects allocated for SymCrypt bcrypt: Align handle objects allocated for SymCrypt https://gitlab.winehq.org/wine/wine/-/merge_requests/11524

5 18

[PATCH 0/1] MR11538: win32u: Enable host Vulkan portability enumeration.
by Dean M Greer (＠Gcenx) Aug. 5, 2026

Aug. 5, 2026

This change allows MoltenVK to be usable via the vulkan-loader. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538

4 14

[PATCH v5 0/7] MR9973: Draft: conhost: add basic VT control sequence
by Thomas Csovcsity (＠thc13) Aug. 4, 2026

Aug. 4, 2026

This is a minimal approach to running MC in wineconsole and addresses https://bugs.winehq.org/show_bug.cgi?id=49780. Wineconsole thus supports basic CSI control sequences for: - SGR (Select Graphic Rendition) and - CUP (Cursor Position) ![mc-in-wineconsole-260126](/uploads/36ed70375b31955fa44dc477e832242c/mc-in-wineconsole-260126.gif){width=900 height=507} **TODO:** - [x] check for ENABLE_VIRTUAL_TERMINAL_PROCESSING - [x] bug states that SetConsoleMode does not return error code and therefore applications fail to handle it correctly - [ ] rewrite, if that is the way to go i will do that, to use newer API. This would allow more colors than ANSI colors only - [x] test shared: several programs attached to the same console > - tried to test it with mc and w64devkit in wineconsole both works as far control sequences are implemented. > - tested following seq: > - write esc seq to change current color in red, > - don't emit esc seq to go back to default color > - use old API to get screen buffer color and check the result (GetConsoleScreenBufferInfo) > > -> GetConsoleScreenBufferInfo matches the color which was set via CSI/SGR seq. -- v5: conhost: add basic CUP color handling kernel32/tests: add console test for CUP conhost: improve basic SGR color handling conhost: add basic SGR color handling kernel32/tests: add console tests for basic SGR conhost: add basic VT control sequence parsing kernel32/tests: add console tests for CSI https://gitlab.winehq.org/wine/wine/-/merge_requests/9973

4 15

[PATCH v3 0/1] MR11449: urlmon: Implement URLDownloadA/W
by Anders Kjersem (＠anders) Aug. 4, 2026

Aug. 4, 2026

URLDownload is the undocumented cousin of [URLDownloadToFile](https://learn.microsoft.com/en-us/previous-versions/wind…, the difference is that the caller has to provide a full implementation of `IBindStatusCallback` and it gets to decide where to save the data (in a file, memory etc.). -- v3: urlmon: Implement URLDownloadA/W https://gitlab.winehq.org/wine/wine/-/merge_requests/11449

3 7

[PATCH v7 0/4] MR10261: Fix toolbar wrapping issues
by Ivan Ivlev (＠iviv) Aug. 4, 2026

Aug. 4, 2026

This MR resolves two bugs with toolbar wrapping I have discovered. 1. Toolbar missing four buttons when app window is maximized (wrap should not appear at all in this case). 2. Last toolbar button disappears when window size (toolbar size) is slightly narrower then button right border. Reasons of this behavior: 1. Toolbar buttons have BTNS_AUTOSIZE style, toolbar width is set using CCS_NORESIZE and equals to widths of all autosized buttons combined. cx (button width) value in TOOLBAR_WrapToolbar is set from nButtonWidth, which contains widest button width. Since buttons in toolbar have different widths, TOOLBAR_WrapToolbar miscalculates total width, because actual buttons widths are less then nButtonWidth. This results in TOOLBAR_WrapToolbar setting TBSTATE_WRAP when it is not not needed, and since app does not paint second button row, wrapped buttons just disappear. 2. After I fixed first issue, I noticed, that last button disappears, when toolbar become narrower then its right border. Then, when toolbar right border approximately in the middle of disappeared button, wrap happens. In windows system, wrapping occurs immediately when toolbar becomes narrower. Found solutions: 1. I noticed, that TOOLBAR_LayoutToolbar calculates buttons rects differently, thats because it checks if button have BTNS_AUTOSIZE style and then calculate size. So i moved this BTNS_AUTOSIZE size calculation in separate function for it to then be used in TOOLBAR_LayoutToolbar and TOOLBAR_WrapToolbar to guarantee that cx values for specific button will be equal in both functions. 2. TOOLBAR_WrapToolbar function decides to wrap in case `if ((x + cx - (infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2 > width).` This `(infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2` turns out, makes this gap, where button right border (x + cx) exceed toolbar right border (width), but wrap wont appear. I did not found any reasons to make this half-button gap, so I just removed it and it solved this issue. The comment above says /\* The layout makes sure the bitmap is visible, but not the button. \*/, but it was introduced in 1999, when TOOLBAR_LayoutToolbar did not existed, and I think its irrelevant now, since layout calculates cx taking both bitmap and string into account. I wrote tests for both fixes: 1. Creates CCS_NORESIZE toolbar, then add BTNS_AUTOSIZE buttons of different widths one by one and checks if wrap happened. In normal case (in windows) wrap should only happen on fourth button, but without fix wrap happens on third. 2. Creates CCS_NORESIZE toolbar with 4 BTNS_AUTOSIZE buttons. Toolbar width at the creation is calculated beforehand and equals exactly buttons widths combined. Then test reduces toolbar width by 1 and checks if wrap happened, in normal case wrap happens, without the fix its not. -- v7: comctl32/toolbar: Remove redundant toolbar wrapping logic. comctl32/toolbar: Use TOOLBAR_AutoSizeButtonWidth in WrapToolbar. comctl32/toolbar: Add TOOLBAR_AutoSizeButtonWidth from LayoutToolbar as a separate function. https://gitlab.winehq.org/wine/wine/-/merge_requests/10261

3 7