- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10046: opengl32: Pass app's FBO to set_current_fbo().
by Paul Gofman (＠gofman) Feb. 6, 2026

Feb. 6, 2026

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

3 3

[PATCH v3 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon Feb. 6, 2026

Feb. 6, 2026

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v3: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

2 11

[PATCH 0/1] MR10044: server: Reset reported_events if socket gets reused.
by Bernhard Übelacker Feb. 6, 2026

Feb. 6, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53574 See details in the bug report. [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161764) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10044

1 1

[PATCH 0/5] MR10043: d2d1/tests: Add some more tests for geometry groups.
by Nikolay Sivov (＠nsivov) Feb. 6, 2026

Feb. 6, 2026

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

2 5

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

Feb. 6, 2026

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) Feb. 6, 2026

Feb. 6, 2026

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) Feb. 6, 2026

Feb. 6, 2026

**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) Feb. 6, 2026

Feb. 6, 2026

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) Feb. 6, 2026

Feb. 6, 2026

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) Feb. 6, 2026

Feb. 6, 2026

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