October 2025 - Wine-GitLab - list.winehq.org

[PATCH 0/2] MR9164: advapi, ntdll: Add a couple of event tracing stubs.
by Paul Gofman (＠gofman) Oct. 12, 2025

Oct. 12, 2025

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

2 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 0/2] MR9162: shell32: Set SFGAO_HASSUBFOLDER correctly for normal shellfolders.
by Elizabeth Figura (＠zfigura) Oct. 12, 2025

Oct. 12, 2025

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

4 5

[PATCH v8 0/1] MR4878: advpack: Ignore lines that begin with '@' in (Un)RegisterOCXs sections.
by Alex Henrie (＠alexhenrie) Oct. 12, 2025

Oct. 12, 2025

selfreg.c was copied from dlls/msi/tests and load_resource was copied from dlls/setupapi/tests/install.c. Two of the tests are marked todo because Wine currently doesn't support the UnregisterOCXs command, only RegisterOCXs. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56209 -- v8: advpack: Ignore lines that begin with '@' in (Un)RegisterOCXs sections. https://gitlab.winehq.org/wine/wine/-/merge_requests/4878

2 2

[PATCH v8 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 12, 2025

Oct. 12, 2025

-- v8: rometadata: Implement IMetaDataTables::{GetColumn, GetColumnInfo}. rometadata/tests: Add tests for IMetaDataTables::{GetColumnInfo, GetColumn}. rometadata: Implement IMetaDataTables::Get{String,Blob,Guid}. rometadata: Implement IMetaDataTables::GetRow. rometadata: Implement IMetaDataTables::GetTableInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/9147

2 7

[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/5] MR9163: Cmd engine rewrite (part XXXVIII)
by eric pouech (＠epo) Oct. 12, 2025

Oct. 12, 2025

This MR starts implementing pipe between commands with: - parallelism between the two sides of the pipe - using real pipes. (Current code is sequential: running LHS, storing its output into a temp. file, then running RHS with temp. file as input). The "interesting" part is: - in order to achieve parallelism, native cmd.exe when LHS or RHS of pipe contains a builtin command or instruction, run this part in a new and separate cmd.exe instance. - which means that we need to transform back the parsed structure of a tree of instructions into a string for feeding the new cmd.exe instance ('rebuild'). This serie mainly: - adds some tests to cover some quirks in pipe handling (esp. when expansion occurs between parent and child process), - refactors some code for the next patches, - introduce a new node in parse tree to help in the rebuild process (will be shown in next serie, and will allow matching the generated trailing spaces), - implement the pipe mechanism for "simple" commands. Next serie will cover the non-"simple" commands. Notes: - the now successful tests in the last patch of this serie are achieved because now the command string in expanded twice (once in parent cmd.exeprocess, and the second time, in child process). - all the wine_todo introduced in this serie will be solved in next serie. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9163

2 5

[PATCH v3 0/3] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Oct. 11, 2025

Oct. 11, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v3: cmd: Don't attempt to copy a file to itself. cmd/tests: Add tests for COPY to self. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

2 4

[PATCH 0/2] MR9161: dwrite: Update script information with Unicode 16.0 additions.
by Nikolay Sivov (＠nsivov) Oct. 11, 2025

Oct. 11, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9161

2 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