- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR10320: win32u/d3dkmt: Close the wait handle with NtClose() in NtGdiDdDDIAcquireKeyedMutex2(). - approved
by Alexandre Julliard (＠julliard) March 19, 2026

March 19, 2026

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

1 0

[PATCH v2 0/1] MR10386: Draft: vbscript: Add tests for specific compile error codes.
by Francis De Brabandere (＠francisdb) March 19, 2026

March 19, 2026

Add error code definitions and string resources for compile errors (1002-1057) and todo_wine tests to verify the error codes returned via OnScriptError. Currently Wine returns error code 0 (generic syntax error) for most cases instead of the specific codes Windows returns. -- v2: vbscript: Add tests for specific compile error codes. https://gitlab.winehq.org/wine/wine/-/merge_requests/10386

2 1

[PATCH v3 0/1] MR10369: mf: Handle ENDOFSEGMENT marker in SAR.
by Brendan McGrath (＠redmcg) March 19, 2026

March 19, 2026

Windows renders silence once the ENDOFSEGMENT marker is received. This allows the presentation time source to continue counting up at the end of an audio stream. This is required when the PTS of the last video sample is greater than the PTS of the last audio sample. -- v3: mf: Handle ENDOFSEGMENT marker in SAR. https://gitlab.winehq.org/wine/wine/-/merge_requests/10369

3 4

[PATCH v6 0/1] MR10368: Draft: vbscript: Implement Eval, Execute, and ExecuteGlobal.
by Francis De Brabandere (＠francisdb) March 19, 2026

March 19, 2026

Eval compiles the string as an expression and returns the result. ExecuteGlobal compiles and executes the string at global scope. Execute compiles and executes the string in the calling scope. When called from within a Sub or Function, Eval and Execute use the calling scope for variable resolution, accessing local variables and arguments. When called from global scope, they fall back to exec_global_code. ExecuteGlobal always executes in global scope. The calling scope is passed through script_ctx_t.caller_exec, which exec_script picks up and stores on exec_ctx_t.caller. The interpreter's lookup_identifier checks the caller's locals, arguments, and dynamic vars when running FUNC_GLOBAL code with a caller context set. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49908 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53962 -- v6: vbscript: Implement Eval, Execute, and ExecuteGlobal. https://gitlab.winehq.org/wine/wine/-/merge_requests/10368

2 2

[PATCH 0/1] MR10386: vbscript: Add tests for specific compile error codes.
by Francis De Brabandere (＠francisdb) March 19, 2026

March 19, 2026

Add error code definitions and string resources for compile errors (1002-1057) and todo_wine tests to verify the error codes returned via OnScriptError. Currently Wine returns error code 0 (generic syntax error) for most cases instead of the specific codes Windows returns. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10386

2 2

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

March 19, 2026

Rémi Bernon (@rbernon) commented about dlls/opengl32/make_opengl: > # - reference to an array of XML nodes giving the list of arguments (an empty array > # for a 'void' function). > # > -my %gl_extensions; > +# Initialize gl_extensions with known token-only extensions missing from the spec. > +my %gl_extensions = > + ( > + "GL_APPLE_packed_pixels" => 1, > + "GL_ATI_texture_compression_3dc" => 1, > + "GL_EXT_demote_to_helper_invocation" => 1, > + "GL_EXT_texture_edge_clamp" => 1, > + "GL_EXT_texture_rectangle" => 1, > + "GL_MESA_texture_signed_rgba" => 1, Some of these are indeed exposed by native drivers (and there are more), some without specs and others with unofficial specs. I don't really mind but I'm also not sure whether it's worth or a good idea to expose spec-less extensions as we simply cannot know whether they are supposed to add new commands or token or not. I also didn't see GL_EXT_demote_to_helper_invocation among them. It seems to be Mesa specific, and looks wrong to me. The extension is actually a shader extension, and I don't think it's supposed to be in the GL extension string, but rather included in GLSL #extension? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_132858

1 0

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

March 19, 2026

Rémi Bernon (@rbernon) commented about dlls/opengl32/make_opengl: > "EGL_QNX_" => 1, > "EGL_TIZEN_" => 1, > "GL_ANDROID_" => 1, > - "GL_ANGLE_" => 1, Why is this useful? None of the GL_ANGLE_ extensions are exposed by native drivers, except for GL_ANGLE_texture_compression_dxt3 / GL_ANGLE_texture_compression_dxt5 by Mesa (which is not a very common driver on Windows), and these two are mostly the same as GL_EXT_texture_compression_dxt1 / GL_EXT_texture_compression_s3tc anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_132857

1 0

[PATCH 0/1] MR10385: magnification: Add stub for MagInitialize.
by Louis Lenders (＠xe) March 19, 2026

March 19, 2026

This was reported at the forum for the game "War at Spain". Forum link: https://forum.winehq.org/viewtopic.php?t=42629 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10385

2 1

[PATCH v5 0/1] MR10368: vbscript: Implement Eval, Execute, and ExecuteGlobal.
by Francis De Brabandere (＠francisdb) March 19, 2026

March 19, 2026

Eval compiles the string as an expression and returns the result. ExecuteGlobal compiles and executes the string at global scope. Execute compiles and executes the string in the calling scope. When called from within a Sub or Function, Eval and Execute use the calling scope for variable resolution, accessing local variables and arguments. When called from global scope, they fall back to exec_global_code. ExecuteGlobal always executes in global scope. The calling scope is passed through script_ctx_t.caller_exec, which exec_script picks up and stores on exec_ctx_t.caller. The interpreter's lookup_identifier checks the caller's locals, arguments, and dynamic vars when running FUNC_GLOBAL code with a caller context set. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49908 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53962 -- v5: vbscript: Implement Eval, Execute, and ExecuteGlobal. https://gitlab.winehq.org/wine/wine/-/merge_requests/10368

2 1

[PATCH 0/1] MR10384: vbscript: Allow hex literals with excess leading zeros.
by Francis De Brabandere (＠francisdb) March 19, 2026

March 19, 2026

Windows allows any number of leading zeros in hex literals (e.g. &H000000031 = 49). Wine rejected literals with more than 8 hex digits regardless of value. Fix by skipping leading zeros before counting significant digits, so that only actual 32-bit overflow is rejected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10384

2 1