- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) March 26, 2026

March 26, 2026

On Thu Mar 26 12:51:57 2026 +0000, Rémi Bernon wrote: > Well arguably we have years of testing showing that exposing these > extensions do not break the applications *which are currently working*. > It says nothing about applications that don't work or that weren't > tested. I've recently fixed some compatibility issue caused by passing > through host GL_RENDERER string as is, which broke an application in > some cases, as it was expecting a shorter string than what we returned. > Anyway, I don't mind too much adding support for registered extensions, > although I think we should argue whether it does fix anything, rather > than whether not exposing them breaks something, but I don't think we > should be hardcoding extensions which aren't in the registry. There's no > reason to list Mesa extensions more than other vendors, and we have a > general policy in Wine not to add vendor or backend specific workaround > unless proven necessary, ie: that it *is* native behavior and that doing > it fixes some application. > If ARM Windows uses Mesa for its OpenGL implementation, and if some > application depends on a Mesa specific extension in such situation, we > could *then* consider adding them in such case, but that actually would > need to be done regardless of the host GL implementation because Wine on > ARM isn't always going to run with Mesa. Note that this probably means > that we would be better off with PE Zink in such case anyway, because > otherwise we might end up being simply unable to implement the missing > extension if the host cannot do it for us. Again, it's not about fixing anything. It is about not changing behavior that do not need to be changed in an MR that is already very invasive. We expose it today, and we have no evidence that it is harmful. And again, removing it on top of this MR is trivial and better for bisectability than doing it here. Anyway, I think it is time to agree to disagree. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133867

1 0

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Rémi Bernon (＠rbernon) March 26, 2026

March 26, 2026

On Thu Mar 26 11:12:56 2026 +0000, Jacek Caban wrote: > On ARM Windows, OpenGL is implemented on top of Mesa’s D3D12 backend, so > all extensions exposed by Mesa can potentially be present on actual > Windows. Filtering them therefore seems counterproductive, unless we > want to filter based on vendor or something similar, which sounds > brittle and would require a strong justification. > We are currently exposing all of those extensions, and we have years of > testing showing that they do not cause problems (at least for the > applications we already support). As such, exposing them should not > introduce regressions. The intention behind adding those entries is to > limit the impact of the patch that tokenizes extensions. Hypothetically, > if we do have a reason to filter any of them after all, I think it would > be better to remove them from make_opengl in a separate change, so that > a potential bisect clearly points to the filtering change rather than to > a commit whose primary purpose is tokenization. That said, even for > extensions currently not exposed by Windows drivers, I believe filtering > would be counterproductive and not forward-compatible by definition, as > future Windows drivers may start exposing them at any time. > Perhaps we should consider adding even more of them to make_opengl. I > initially added the ones observed on my drivers, which seemed like a > reasonable compromise. Well arguably we have years of testing showing that exposing these extensions do not break the applications *which are currently working*. It says nothing about applications that don't work or that weren't tested. I've recently fixed some compatibility issue caused by passing through host GL_RENDERER string as is, which broke an application in some cases, as it was expecting a shorter string than what we returned. Anyway, I don't mind too much adding support for registered extensions, although I think we should argue whether it does fix anything, rather than whether not exposing them breaks something, but I don't think we should be hardcoding extensions which aren't in the registry. There's no reason to list Mesa extensions more than other vendors, and we have a general policy in Wine not to add vendor or backend specific workaround unless proven necessary, ie: that it *is* native behavior and that doing it fixes some application. If ARM Windows uses Mesa for its OpenGL implementation, and if some application depends on a Mesa specific extension in such situation, we could *then* consider adding them in such case, but that actually would need to be done regardless of the host GL implementation because Wine on ARM isn't always going to run with Mesa. Note that this probably means that we would be better off with PE Zink in such case anyway, because otherwise we might end up being simply unable to implement the missing extension if the host cannot do it for us. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133862

1 0

[PATCH v2 0/2] MR10451: comctl32/treeview: Implemented TVN_ITEMCHANGING
by Piotr Pawłowski (＠DEATH) March 26, 2026

March 26, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59456 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55707 -- v2: comctl32/treeview: Implemented TVN_ITEMCHANGING & TVN_ITEMCHANGED comctl32/tests: Enabled test_select() for comctl32 v6, made test for TVN_ITEMCHANGING & TVN_ITEMCHANGED https://gitlab.winehq.org/wine/wine/-/merge_requests/10451

2 2

[PATCH 0/5] MR10163: server: Create the new process first thread in new_process request.
by Rémi Bernon March 26, 2026

March 26, 2026

In preparation for doing something like https://gitlab.winehq.org/wine/wine/-/merge_requests/10058, this also saves one wineserver request on process creation by creating the first thread in new_process. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10163

3 8

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) March 26, 2026

March 26, 2026

> GLSL extensions aren't supposed to be exposed there, unless they have a matching GL extension to add tokens / commands or change GL behavior. This one doesn't do any of that on the GL side, and I believe it is not meant to be exposed in GL_EXTENSIONS. Well, it's exposed by Mesa's `GL_EXTENSIONS`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133858

1 0

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) March 26, 2026

March 26, 2026

On Tue Mar 24 13:37:32 2026 +0000, Rémi Bernon wrote: > The issue I see is that exposing extensions that aren't expected to be > there by applications have a chance of confusing them. It's possible for > instance that an application check for GL_ANGLE extension and decide to > enable some ANGLE specific rendering mode. On Windows the AMD drivers do > not support those extensions, but on Wine most of the time Mesa is used > for AMD GPUs and they would be exposed. > The same logic applies to platform specific extensions like GL_APPLE or > other platform extensions that are currently filtered out. Sure > `make_opengl` could support some of them, and sure, GL extensions aren't > restricted and some other driver could implement them including on > Windows, but it's not the case in practice and passing them through > creates a runtime environment that differ from any possible native > environment Windows applications have been developed for. > Filtering out extensions which aren't, or very rarely, there on Windows > is less likely to break anything, because no application is expected to > benefit from them anyway. On ARM Windows, OpenGL is implemented on top of Mesa’s D3D12 backend, so all extensions exposed by Mesa can potentially be present on actual Windows. Filtering them therefore seems counterproductive, unless we want to filter based on vendor or something similar, which sounds brittle and would require a strong justification. We are currently exposing all of those extensions, and we have years of testing showing that they do not cause problems (at least for the applications we already support). As such, exposing them should not introduce regressions. The intention behind adding those entries is to limit the impact of the patch that tokenizes extensions. Hypothetically, if we do have a reason to filter any of them after all, I think it would be better to remove them from make_opengl in a separate change, so that a potential bisect clearly points to the filtering change rather than to a commit whose primary purpose is tokenization. That said, even for extensions currently not exposed by Windows drivers, I believe filtering would be counterproductive and not forward-compatible by definition, as future Windows drivers may start exposing them at any time. Perhaps we should consider adding even more of them to make_opengl. I initially added the ones observed on my drivers, which seemed like a reasonable compromise. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133857

1 0

[PATCH 0/1] MR10424: services: Cancel overlapped IO after timeout.
by Yuxuan Shui (＠yshui) March 26, 2026

March 26, 2026

Though WaitForSingleObject timed out, the IO operation is still running in the background. After the function process_send_command returns, the OVERLAPPED object referenced by this IO operation becomes invalid. Later, when this IO finally completes, server_select will use invalid stack memory. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10424

4 8

[PATCH 0/1] MR10456: vbscript: Implement DatePart built-in function.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Implement DatePart(interval, date [, firstdayofweek [, firstweekofyear]]) with support for all interval types: yyyy, q, m, y, d, w, ww, h, n, s. The week-of-year ("ww") calculation handles all three firstweekofyear modes (vbFirstJan1, vbFirstFourDays, vbFirstFullWeek) including the edge case where dates before week 1 belong to the last week of the previous year. Uses VarUdateFromDate for day-of-year information. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10456

2 1

[PATCH v43 0/2] MR10291: Fix GetModuleFileName string termination
by Trent Waddington (＠trent.waddington) March 26, 2026

March 26, 2026

After Windows XP the string termination behavior of GetModuleFileName was changed to always terminate the path returned, even if the buffer is insufficient to contain the null terminator. -- v43: kernel32: Fix string termination of GetModuleFileName. https://gitlab.winehq.org/wine/wine/-/merge_requests/10291

3 10

[PATCH 0/1] MR10454: vbscript: Return DISP_E_TYPEMISMATCH when indexing non-array variables.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Indexing or assigning to a non-array, non-dispatch variable (e.g. Integer, String, Boolean, Empty, Null, Double, Date) with variant_call() returned E_NOTIMPL. Windows returns DISP_E_TYPEMISMATCH (error 13). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10454

2 1

[PATCH 0/2] MR10453: winhttp: Always buffer response data.
by Hans Leidekker (＠hans) March 26, 2026

March 26, 2026

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

2 2

[PATCH 0/4] MR10138: Draft: imm32: Only load IME with IME HKLs.
by Rémi Bernon March 26, 2026

March 26, 2026

@mzent @bsjeon I'm thinking about doing something like that, bypassing IME entirely as we should if HKL isn't an IME one, instead of checking whether host IME needs to be fed input in ImeProcessKey, it's a bit untested though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10138

3 8

[PATCH v6 0/1] MR10404: Draft: vbscript: Reject arguments on Class_Initialize and Class_Terminate.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Windows returns error 1053 when Class_Initialize or Class_Terminate are declared with arguments. Add the same check in compile_class() and store source location in function_decl_t for accurate error reporting. -- v6: vbscript: Reject arguments on Class_Initialize and Class_Terminate. https://gitlab.winehq.org/wine/wine/-/merge_requests/10404

2 1

[PATCH v14 0/4] MR10386: vbscript: Return proper error codes for compile errors.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Add error_code field to parse error tests, using negative values for codes that Wine does not yet return correctly (todo_wine), matching the existing pattern for error_char. Return MAKE_VBSERROR with proper error codes instead of E_FAIL for name redefinition, invalid exit statements, and invalid parenthesized call statements. -- v14: vbscript: Improve some error codes in the parser. vbscript: Improve some error codes in the lexer. vbscript: Improve some error codes in the compiler. vbscript/tests: Add error code tests for compile errors. https://gitlab.winehq.org/wine/wine/-/merge_requests/10386

2 5

[PATCH v16 0/1] MR10244: vbscript: Fix Sub first argument parentheses handling.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54177 Fix parsing of expressions like `Sub (i - 20) * 8,y` where a space-separated parenthesized expression followed by a binary operator(*` /` \` ^` &`) was incorrectly treated as call argument parentheses instead of expression grouping. If you look at all the extra test cases in `lang.vbs` you will see which parentheses related issues this solves. I have been testing with a repo full of scripts: https://github.com/sverrewl/vpxtable_scripts There are still quite some compiler issues left but this addresses the biggest parser issues. -- v16: vbscript: Fix Sub first argument parentheses handling. https://gitlab.winehq.org/wine/wine/-/merge_requests/10244

2 1

[PATCH 0/2] MR10452: Comctl32/test print WM_NOTIFY codes on failure
by Piotr Pawłowski (＠DEATH) March 26, 2026

March 26, 2026

Makes debugging of WM_NOTIFY message sequence errors much easier. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10452

2 2

[PATCH v15 0/1] MR10244: vbscript: Fix Sub first argument parentheses handling.
by Francis De Brabandere (＠francisdb) March 26, 2026

March 26, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54177 Fix parsing of expressions like `Sub (i - 20) * 8,y` where a space-separated parenthesized expression followed by a binary operator(*` /` \` ^` &`) was incorrectly treated as call argument parentheses instead of expression grouping. If you look at all the extra test cases in `lang.vbs` you will see which parentheses related issues this solves. I have been testing with a repo full of scripts: https://github.com/sverrewl/vpxtable_scripts There are still quite some compiler issues left but this addresses the biggest parser issues. -- v15: vbscript: Fix Sub first argument parentheses handling. https://gitlab.winehq.org/wine/wine/-/merge_requests/10244

2 1

[PATCH 0/2] MR10451: comctl32/treeview: Implemented TVN_ITEMCHANGING
by Piotr Pawłowski (＠DEATH) March 26, 2026

March 26, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59456 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55707 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10451

2 2

[PATCH 0/5] MR10423: dsound: Speed up resampling, part 5
by Anton Baskanov (＠baskanov) March 26, 2026

March 26, 2026

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

4 9

Re: [PATCH v10 0/1] MR10370: Silence noisy test - closed
by Trent Waddington (＠trent.waddington) March 26, 2026

March 26, 2026

This merge request was closed by Trent Waddington. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10370

1 0

Re: [PATCH v23 0/2] MR10295: Fix ImageGetDigestStream
by Trent Waddington (＠trent.waddington) March 25, 2026

March 25, 2026

@epo I don't know how to todo_wine this one. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10295#note_133809

1 0

Re: [PATCH v42 0/2] MR10291: Fix GetModuleFileName string termination
by Trent Waddington (＠trent.waddington) March 25, 2026

March 25, 2026

On Wed Mar 25 23:26:00 2026 +0000, eric pouech wrote: > what's strange at first glance is that first commit (the one which add > tests) doesn't show any todo_wine marks > we expect every commit to run the regression suite without errors, so > that we can safely do binary search in the git tree for CI failures > so either: > * you didn't run the non regression tests on the first commit, and > forgot to mark the failing tests as todo_wine > * or current kernel32/kernelbase code behaves correctly, and this MR is > pretty useless Ahh, I am learning! First commit now has todo_wine marks and I confirmed these appear as "Test marked todo" in the test output. Second commit fixes the code and removes the todo_wine marks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10291#note_133807

1 0

[PATCH 0/1] MR10445: tomcrypt: Treat FreeBSD like Linux
by Gerald Pfeifer (＠gerald) March 25, 2026

March 25, 2026

We are currently seeing ``` libs/tomcrypt/mpi.c:5785:24: error: implicit declaration of function ‘arc4random’ [-Wimplicit-function-declaration] 5785 | d |= ((mp_digit) arc4random()); | ^~~~~~~~~~ ``` even if including <stdlib.h> and setting various standard defines, so simply don't treat FreeBSD specially and go with the Linux code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10445

3 3

Re: [PATCH v7 0/1] MR10312: vbscript: Fix dot member access after line continuation. - approved
by Alexandre Julliard (＠julliard) March 25, 2026

March 25, 2026

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

1 0

Re: [PATCH v5 0/1] MR10384: vbscript: Allow hex literals with excess leading zeros. - approved
by Alexandre Julliard (＠julliard) March 25, 2026

March 25, 2026

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

1 0