September 2025 - Wine-GitLab

[PATCH v10 0/2] MR8635: oleaut32: Convert VT_BSTR numeric strings to VT_I4 in VarAnd
by Maotong Zhang (＠xiaotong) Oct. 19, 2025

Oct. 19, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56280 -- v10: oleaut32: Convert VT_BSTR numeric strings to VT_I4 in VarAnd oleaut32/tests: Add more VT_BSTR test cases for VarAnd https://gitlab.winehq.org/wine/wine/-/merge_requests/8635

3 4

[PATCH v8 0/2] MR8178: user32: Fix uiLengthDrawn calculation in DrawTextExW().
by JiangYi Chen (＠meshine) Oct. 17, 2025

Oct. 17, 2025

uiLengthDrawn should represent the number of characters that have been processed. However, the original implementation uses len (the count of displayed characters in the current line), which is not accurate. When text requires line breaks or special processing (such as adding an ellipsis), the actual number of processed characters may differ from the number of displayed characters. When the DT_CALCRECT flag is absent, len gets decremented to 0 during the drawing loop. Consequently, uiLengthDrawn becomes inaccurate since it relies on len's value for statistics. -- v8: user32: Fix uiLengthDrawn calculation in DrawTextExW(). user32/tests: Add some tests for uiLengthDrawn calculation in DrawTextExW(). https://gitlab.winehq.org/wine/wine/-/merge_requests/8178

3 3

[PATCH v11 0/1] MR6131: Extend bcp47langs.dll with GetUserLanguages
by Marius Schiffer (＠MariusSchiffer) Oct. 17, 2025

Oct. 17, 2025

This is an undocumented API used by some programs to fetch the user's selected languages. Example is Fusion360 (during its login process). Signature currently taken from here: https://stackoverflow.com/questions/63877075/what-is-the-right-way-to-get-t… (Maybe that stackoverflow answer is also why Fusion has implemented this...) I'm a first-time contributor, please point out if I'm doing anything wrong -- v11: bcp47langs: Implement GetUserLanguages() https://gitlab.winehq.org/wine/wine/-/merge_requests/6131

3 10

[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] MR8931: winex11.drv: Fixing an issue where the window size was not saved after...
by Ivan Lyugaev (＠valy) Oct. 16, 2025

Oct. 16, 2025

winex11.drv: Fixing an issue where the window size was not saved after switching from full-screen mode When switching from maximized window to windowed mode, the window retains the size of the entire screen. This bug is reproducible in xfce. Upon closer examination of the logs, I noticed that xfce was duplicating ConfigureNotify requests. The duplicate requests had the send_event=TRUE flag. These requests caused the window to resize incorrectly. The current implementation of wine uses the asynchronous ConfigureNotify event notification method - NtUserPosteMessage with the WM_WINE_WINDOW_STATE_CHANGED flag. I suggest returning to the synchronous method using Send_message. This bug is a regression. This issue first appeared in commit 0f1d999b, which moved the handling of GetWindowStateUpdates in win32u/message.c to the handle_internal_message function via NtUserPostMessage. I decided to revert the handling logic to before this patch was applied, adapting it to the current handling of GetWindowStateUpdates in win32u/message.c This solution was tested in xfce, mate, and a number of different programs. Everything worked correctly -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8931

2 7

[PATCH 0/1] MR8933: mf: Update the stream sink input type when a transform output type changes.
by Conor McCarthy (＠cmccarthy) Oct. 14, 2025

Oct. 14, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8933

2 2

[PATCH v7 0/2] MR8887: mf/tests: Test H.264 sink media type height alignment.
by Conor McCarthy (＠cmccarthy) Oct. 14, 2025

Oct. 14, 2025

H.264 uses a 16-pixel alignment, and the stream sink media type should have the aligned height after the session has started. -- v7: mf/tests: Test H.264 decoder alignment. mf/tests: Test H.264 sink media type height alignment. https://gitlab.winehq.org/wine/wine/-/merge_requests/8887

3 3

[PATCH v3 0/1] MR8988: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor...
by Kun Yang (＠yangkun) Oct. 12, 2025

Oct. 12, 2025

win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. In NtGdiTransparentBlt function, the StretchBlt mode of dst hdc is not set. The Default StretchBlt Mode in wine is BlackOnWhite. It is not correct to use this StretchBltMode in TransparentBlt dealing with color bitmap. According to MSDN, it should be converted to ColorOnColor. My test code shows that, the image converted by wine generates a lot of chromatic noise. [test_blt.c](/uploads/26101bc7bdb27400d02c8ff5bf741864/test_blt.c) [test_blt.exe](/uploads/98ee3ab7ce0d590e1511bd8a5fb5a1bb/test_blt.exe) ![source](/uploads/0c56c5e6d1280040ba08cd3dee7acd95/source.bmp) ![result_wrong](/uploads/2076396e069f852914313a8fb86dd5e2/result_wrong.bmp) ![result](/uploads/cf3ec00bf0f0e7f3ea7fe1e2085385d6/result.bmp) -- v3: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. https://gitlab.winehq.org/wine/wine/-/merge_requests/8988

3 5

[PATCH v2 0/1] MR411: win32u: Don't load bitmap only TTF fonts without bitmap table.
by Paul Gofman (＠gofman) Oct. 12, 2025

Oct. 12, 2025

The offending font is NotoColorEmoji.ttf which is present in, e. g., google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open it with default font viewer) fails while currently succeeds on Windows. fontforge also refuses to open this font. That is because the font is bitmap only but missing bitmap table. Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and do not expect that to have an error return (as we currenly do), which leads to crash on unhandled division by zero exception. I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with fontforge to make sure that such font can still be loaded in Wine. This font also loads on Windows (both with AddFontResourceA() and with default font viewer). There are other font types which can be legitimately missing EBDT table, but FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject those fonts. [test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf) -- v2: win32u: Don't load bitmap only TTF fonts without bitmap table. https://gitlab.winehq.org/wine/wine/-/merge_requests/411

3 2

[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