- Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/4] MR10741: msxml3: Support for max-element-depth property. - approved
by Alexandre Julliard (＠julliard) April 27, 2026

April 27, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10741

1 0

Re: [PATCH v2 0/1] MR10749: secur32: Handle SEC_WINNT_AUTH_IDENTITY_EX in the Negotiate provider. - approved
by Alexandre Julliard (＠julliard) April 27, 2026

April 27, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10749

1 0

Re: [PATCH v2 0/1] MR10746: po: Update Lithuanian translation. - approved
by Alexandre Julliard (＠julliard) April 27, 2026

April 27, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10746

1 0

[PATCH v3 0/3] MR10748: wusa: Recognize runtime.syswow64 expressions.
by David Carrasco Flores (＠dcf1007) April 27, 2026

April 27, 2026

Some update manifests use $(runtime.syswow64) as an explicit target for the 32-bit system directory. wusa currently handles runtime.system32 with WoW64-aware redirection, but does not recognize runtime.syswow64, causing expression expansion to fail. Map runtime.syswow64 to CSIDL_SYSTEMX86 on x86_64, matching the existing runtime.programfilesx86 and runtime.commonfilesx86 handling. -- v3: Revert "wusa: Split cabinet path before calling FDICopy." https://gitlab.winehq.org/wine/wine/-/merge_requests/10748

3 5

[PATCH v2 0/2] MR10748: wusa: Recognize runtime.syswow64 expressions.
by David Carrasco Flores (＠dcf1007) April 27, 2026

April 27, 2026

Some update manifests use $(runtime.syswow64) as an explicit target for the 32-bit system directory. wusa currently handles runtime.system32 with WoW64-aware redirection, but does not recognize runtime.syswow64, causing expression expansion to fail. Map runtime.syswow64 to CSIDL_SYSTEMX86 on x86_64, matching the existing runtime.programfilesx86 and runtime.commonfilesx86 handling. -- v2: wusa: Split cabinet path before calling FDICopy. https://gitlab.winehq.org/wine/wine/-/merge_requests/10748

3 5

[PATCH v4 0/4] MR10261: Fix toolbar wrapping issues
by Ivan Ivlev (＠iviv) April 27, 2026

April 27, 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. -- v4: comctl32/toolbar.c: Wrap toolbar immediately after width exceeded. comctl32/tests/toolbar.c: Test wrapping occurs immediately when needed. comctl32/toolbar.c: Move BTNS_AUTOSIZE processing from LayoutToolbar in a separate function and use it in WrapToolbar. comctl32/tests/toolbar.c: Test wrapping for fixed size toolbar and autosized buttons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10261

2 5

[PATCH v5 0/2] MR9775: gdiplus: Move X position calculation to callbacks.
by Dmitry Timoshkov (＠dmitry) April 27, 2026

April 27, 2026

An application I'm working on does GdipMeasureCharacterRanges(graphics, "1", 1, ..., 2, regions); GdipGetRegionBounds(regions[0], graphics, &bounds); GdipSetClipRegion(graphics, regions[0], CombineModeReplace); GdipDrawString(graphics, graphics, "1", 1, ..); which leads to an almost completely clipped text output. Attached test application graphically shows the results of bounding boxes calculated by GdipMeasureCharacterRanges(), GdipMeasureString() and GdipDrawString(). This patchset makes the resulting image look closer to what is observed under Windows. Gdip[test_GdipMeasureCharacterRanges.tar.xz](/uploads/53c8bd3f9b7b005d5b0b675296f0631c/test_GdipMeasureCharacterRanges.tar.xz) -- v5: gdiplus: Copy logic for calculating y-offset from GdipDrawString() to GdipMeasureCharacterRanges(). gdiplus: Copy logic for trimming bounds width from GdipMeasureString() to GdipMeasureCharacterRanges(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9775

4 8

[PATCH v5 0/3] MR10743: small odbc fixes
by Ivan Ivlev (＠iviv) April 27, 2026

April 27, 2026

1)odbc32: compare strings case-insensitively in get_driver_filename() Driver names should be compared without case-sensetivity. unixODBC has no problems when testDSN got "Driver = SQLite3" instead of "Driver = SQLITE3" https://learn.microsoft.com/en-us/openspecs/sql_server_protocols/ms-odbcstr… 2)odbc32: skip set_value for NULL filename in replicate_odbc_to_registry() get_driver_filename can return NULL, for example when \~/.odbc.ini contains driver that has been deleted. We want to prevent SIGSEGV because of wcslen(filename) when filename is NULL. 3)odbc32: check if row_number is NULL in param_options_unix() According to documentation, SQLParamOptions can accept NULL row_number. Now when NULL row_nuber is passed, crash happens 4)odbc32: make sure ODBC_CALL returns SQLRETURN Not sure about this one, need opinion. The targeted problem: now ODBC_CALL return SQLRETURN which is truncated from NTSTATUS. If WINE_UNIX_CALL fails at some point, ODBC_CALL returns truncated NTSTATUS error code, STATUS_ACCESS_VIOLATION (0xC0000005) truncated to 5, then function gets invalid SQLRETURN. The following solution checks of NTSTATUS is actually short SQLRETURN casted to NTSTATUS. -- v5: odbc32: Check if row_number is NULL in param_options_unix(). odbc32: Skip operations for NULL filename in replicate_odbc_to_registry(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10743

3 6

[PATCH v6 0/4] MR10104: user32/edit: set bCaptureState flag after SetCapture()
by Ivan Ivlev (＠iviv) April 27, 2026

April 27, 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). -- v6: comctl32_v6/edit: Set bCaptureState flag after SetCapture(). user32/edit: Set bCaptureState flag after SetCapture(). comctl32/tests/edit.c: Test WM_LBUTTONDOWN processing. user32/tests/edit.c: Test WM_LBUTTONDOWN processing. https://gitlab.winehq.org/wine/wine/-/merge_requests/10104

2 5

[PATCH v3 0/1] MR10757: vbscript: Fix call depth decrement on early returns from exec_script.
by Francis De Brabandere (＠francisdb) April 27, 2026

April 27, 2026

The early-return paths in exec_script skip the call_depth decrement that the normal exit path performs, so any of them leak the depth counter and can spuriously trigger VBSE_OUT_OF_STACK. This is a fix for a regression introduced in !10592 -- v3: vbscript: Move call_depth check past exec_script's setup phase. https://gitlab.winehq.org/wine/wine/-/merge_requests/10757

2 1