February 2026 - Wine-gitlab

Re: [PATCH v3 0/2] MR6492: d2d1: Implement drawing of ID2D1GeometryGroup
by Juergen R. (＠GitJR) 06 Feb '26

06 Feb '26

On Wed Feb 4 20:30:48 2026 +0000, Nikolay Sivov wrote: > You are probably testing with Wine 11.0 and not Wine-staging 11.0? @nsivov: thanks for the hint. I retested with 11.1 (staging) and the tax program displayed the preview as expected. Many thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_128975

1 0

[PATCH 0/2] MR10042: dlls: Rename light.msstyles to aero.msstyles.
by Dmitry Timoshkov (＠dmitry) 06 Feb '26

06 Feb '26

A .NET based application installer that I have here fails to initialize. This happens during WPF initialization because it fails to load C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\PresentationFrameWork.light.dll. An investigation shows that the installer (or rather WPF) uses uxtheme.GetCurrentThemeName() to build the target DLL name for loading. Under Windows 10/11 directory C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\WPF doesn't contain PresentationFrameWork.light.dll neither, it has the following backends for the theme support: PresentationFramework.Aero.dll PresentationFramework.Aero2.dll PresentationFramework.AeroLight.dll PresentationFramework.Classic.dll PresentationFramework.Luna.dll PresentationFramework.Royale.dll and C:\WINDOWS\Resources\Themes contains only 2 files with extension .msstyles: aero\aero.msstyles and aero\aerolight.msstyles. Further experiments with installing and switching between different themes under Windows shows that regardless of current active theme the call uxtheme.GetCurrentThemeName() always returns "C:\WINDOWS\resources\themes\Aero\Aero.msstyles". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10042

3 4

[PATCH 0/1] MR9854: cmd: Add '/' to delimiters for tab-completion support.
by Thomas Csovcsity (＠thc13) 06 Feb '26

06 Feb '26

**Improvement:** Since 'cd ../' works in wineconsole, tab completion should too. - This not like **win10 cmd**, because 'cd ../' fails there. Interestingly tab completion for 'cd ../' shows results for actual path and not for the parent folder. It fails only after enter like cd command does for using '/' instead of '\'. - wineconsole behaves more like **PowerShell on win10**, which accepts '/' as delimiter, but it replaces '/' with '\' on completion. **Before:** ![wineconsole-slash-delimiter-not-working](/uploads/45ff9b1f69ec9c5c77ddd2601910ec25/wineconsole-slash-delimiter-not-working.gif){width=600 height=380} **After:** ![wineconsole-slash-delimiter-working](/uploads/1c0b77121ee37cb62d9c727ede85744f/wineconsole-slash-delimiter-working.gif){width=600 height=380} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9854

3 9

[PATCH v3 0/3] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

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) -- v3: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

3 5

[PATCH v2 0/2] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

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) -- v2: 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 2

[PATCH 0/1] MR10039: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

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) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10039

4 7

[PATCH 0/2] MR10038: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

Logs: When CreateDIBSection does not return a valid hbitmap, the source image is lost that only masked icon is shown in imagelist. Signed-off-by: Kun Yang <yangkun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10038

3 7

[PATCH 0/1] MR10040: inkobj: Correct install path.
by Alistair Leslie-Hughes (＠alesliehughes) 06 Feb '26

06 Feb '26

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

2 1

Re: [PATCH v2 0/1] MR10034: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. - closed
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

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

1 0

[PATCH v5 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v5: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 3