June 2026 - Wine-GitLab - list.winehq.org

[PATCH v4 0/1] MR10869: atl: Implement registering ATL window messages.
by Steven Don (＠shdon) June 8, 2026

June 8, 2026

The [documentation](https://source.winehq.org/WineAPI/AtlAxWinInit.html) for `AtlAxWinInit` states that it initialises ATL's control hosting code by registering window classes "_and some messages_". MSDN's documentation phrases this as "_plus a couple of custom window messages_", but Wine's implementation didn't register any custom window messages. Logging calls to `RegisterWindowMessage` showed that Visual Studio 2005, when going into Options -\> Projects and Solutions -\> VC++ Directories, calls this function to get the message IDs for custom messages name `WM_ATLGETCONTROL` and `WM_ATLGETHOST`. I've then registered those same messages in `AtlAxWinInit` and logged when they were called in `AtlAxWin_wndproc`. Since they were called with 0 for both `wParam` and `lParam`, the only sensible implementation would be routing the calls through `AtlAxGetControl` and `AtlAxGetHost` and returning the `IUnknown` pointer from the window procedure. This minor change now makes the VC++ Directories control in Visual Studio 2005 work as expected (and probably other stuff too). In that, it fixes one of the problems listed on the [Visual Studio 2005 AppDb page](https://appdb.winehq.org/objectManager.php?sClass=version&iId=4494), specifically as described in the comment "Building" posted by Dave on 2021-08-01. -- v4: atl: Implement registering ATL window messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/10869

3 2

[PATCH 0/1] MR11060: ddraw/tests: Remove extra backbuffer1 release in test_surface_attachment().
by Paul Gofman (＠gofman) June 8, 2026

June 8, 2026

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

3 3

[PATCH v31 0/2] MR10393: Draft: vbscript: Probe top-level declared names against the host dispatch.
by Francis De Brabandere (＠francisdb) June 8, 2026

June 8, 2026

Match native VBScript's pattern of probing top-level declared names against an `ISVISIBLE` named item's host `IDispatch` at parse time, and keep the probe IDispatch slot independent of the runtime cache. Why - **Wire-level compatibility.** Hosts that observe `GetIDsOfNames` calls see the same pattern they get on native. The probe result is discarded - it doesn't change shadowing - but the host gets notified of declared names. - **Correctness with rotating hosts.** Wine previously had a single `IDispatch` slot per named item; a Dim parse overwrote the runtime cache, misrouting subsequent qualified access. The patch keeps the probe slot (`dim_probe_disp`) separate. What's in it - Probe pass in `exec_global_code` for visible items, in native order: Subs/Functions -> Classes -> explicit Dims -> implicit declarations from bare top-level assignments. - Cross-parse deduplication: a name is probed at most once per named item across the script lifetime. - Two-slot independence; probe slot reused as runtime cache when no separate runtime fetch has happened yet. - Lazy runtime fetch via `ensure_named_item_disp`. Known divergence (follow-up) When an implicit-decl name is later read as RHS (`a = 1; b = a`), Wine still triggers one extra runtime `GetIDsOfNames` that native avoids. Native pre-creates implicit decls during parse; matching that needs compiler changes. Verified against native VBScript 5.812 with a raw-IDispatch probe harness. -- v31: vbscript: Probe top-level declared names against the host dispatch. vbscript/tests: Test probing of top-level declared names against the host dispatch. https://gitlab.winehq.org/wine/wine/-/merge_requests/10393

2 4

[PATCH 0/1] MR11085: webservices: Improve double tests.
by Bernhard Übelacker (＠bernhardu) June 8, 2026

June 8, 2026

The [test pattern page](https://test.winehq.org/data/patterns.html#webservices:writer) shows since yesterday failures for the linux 32-bit tests. In my debugging the `digit` variable holds a value of 10, therefore the `*(p++) = '0' + digit;` results in the wrong colon in `<t>:E-3</t>`. I could not reproduce the working state at my system of the previous commit round, therefore could not start a git bisect. What makes me wonder is, my [asan gitlab CI runs](https://gitlab.winehq.org/bernhardu/wine/-/jobs/229031#L4063) with llvm-mingw/clang started to show this issue already at 2026-02-13. Could probably the patch 508a30f0d3, "configure: Add -msse2 to default i386_EXTRACFLAGS.", made this issue to surface in the various test runs? However, this patch makes the failing tests succeed. Unfortunately I found some new values, which have rounding issues in 64 and 32 bits. [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=163276). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11085

3 4

[PATCH v7 0/9] MR10954: nsiproxy.sys: Reuse icmp sockets for multiple requests and support receiving error packets with Linux ping sockets.
by Paul Gofman (＠gofman) June 8, 2026

June 8, 2026

-- v7: nsiproxy.sys: Use compatible ICMP request id and seq numbers. nsiproxy.sys: Support ICMP error replies with ping sockets. nsiproxy.sys: Reuse icmp socket with matching parameters. nsiproxy.sys: Return ICMP ids from parse_icmp_hdr() instead of matching those. nsiproxy.sys: Poll all icmp sockets in a single thread. nsiproxy.sys: Manage ICMP listen threads on the Unix side. nsiproxy.sys: Contain all the reply data in struct icmp_reply_ctx. nsiproxy.sys: Rename icmp_listen into icmp_get_reply. nsiproxy.sys: Factor out icmp_socket structure. https://gitlab.winehq.org/wine/wine/-/merge_requests/10954

2 10

[PATCH 0/1] MR11088: bcrypt/tests: Avoid crash when BCryptSecretAgreement fails in test_ECDH_alg.
by Bernhard Übelacker (＠bernhardu) June 8, 2026

June 8, 2026

The test pattern page shows a bcrypt crash. I could reproduce it with a Debian Bookworm VM. It shows before the crash the error: ``` GnuTLS error: An unknown public key algorithm was encountered. bcrypt.c:3332: Test failed: L"ECDH_P256": got 0xc00000e5 ``` The crashes can be avoid by initializing the handles `secret` and `key2` to NULL. [Test pattern page bcrypt:bcrypt](https://test.winehq.org/data/patterns.html#bcrypt:bcrypt) [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=163281) <details> <summary>Backtrace of segfault</summary> ``` Thread 1 "bcrypt_test.exe" received signal SIGSEGV, Segmentation fault. 0x00006ffffd9a73dd in get_object (handle=handle@entry=0xc40009d7b41de826, magic=magic@entry=1396920916) at dlls/bcrypt/bcrypt_main.c:282 282 return obj; (gdb) bt #0 get_object (handle=handle@entry=0xc40009d7b41de826, magic=magic@entry=1396920916) at dlls/bcrypt/bcrypt_main.c:282 #1 get_secret_object (handle=0xc40009d7b41de826) at dlls/bcrypt/bcrypt_main.c:311 #2 BCryptDestroySecret (handle=0xc40009d7b41de826) at dlls/bcrypt/bcrypt_main.c:2696 #3 test_ECDH_alg (t=0xfffffffc0) at dlls/bcrypt/tests/bcrypt.c:3381 #4 test_ECDH () at dlls/bcrypt/tests/bcrypt.c:3525 #5 func_bcrypt () at dlls/bcrypt/tests/bcrypt.c:4921 #6 run_test (name=name@entry=0x7ffffe33c23f "bcrypt") at include/wine/test.h:780 #7 main (argc=<optimized out>, argv=<optimized out>) at include/wine/test.h:900 (gdb) ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11088

3 4

[PATCH v4 0/1] MR10594: Draft: vbscript: Log call stack trace on runtime errors.
by Francis De Brabandere (＠francisdb) June 8, 2026

June 8, 2026

Add WARN-level trace output showing the call chain when a runtime error propagates through nested function calls. This helps diagnose errors in ExecuteGlobal/Execute code where the reported error location has no context about which call chain led to it. ``` Example output for WINEDEBUG=warn+vbscript: error 0x80020012 in L"Broken", line 3 called from L"Wrapper", line 2 called from <global>, line 16 ``` -- v4: vbscript: Log call stack trace on runtime errors. https://gitlab.winehq.org/wine/wine/-/merge_requests/10594

2 3

[PATCH v15 0/3] MR10897: vbscript: Handle declaration scope in the parser.
by Francis De Brabandere (＠francisdb) June 8, 2026

June 8, 2026

ClassDeclaration was only accepted at the top SourceElement level, so a prior statement on the same line (e.g. Dim x : Class C) failed to parse instead of being accepted or, for a name collision, reported as err 1041. Make ClassDeclaration a SimpleStatement and register it as a class at compile time in source order. Sub, Function and Class declarations are only valid at script global scope. A global If/ElseIf/Else/Select block still hoists a Sub or Function to global scope, but a loop (For/For Each/While/Do) or With block does not, and a Class is never hoisted. Reject the disallowed cases during parsing, reporting the location native reports rather than failing later during bytecode emission. -- v15: vbscript/tests: Add tests for sub declaration scope. vbscript: Handle class declaration scope in the parser. vbscript/tests: Add tests for class declaration scope. https://gitlab.winehq.org/wine/wine/-/merge_requests/10897

3 4

[PATCH 0/2] MR10864: winegstreamer: Normalize PTS values so the stream starts at zero.
by Akihiro Sagawa (＠sgwaki) June 8, 2026

June 8, 2026

mpegpsdemux uses raw PTS values from the stream, which often start at a non-zero timestamp. To avoid an initial delay, we normalize the PTS by subtracting the first raw value so that the buffer timeline begins at zero. Without this adjustment, the first sample would not be presented until its original (non-zero) timestamp. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59565 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10864

4 10

Re: [PATCH v3 0/1] MR10502: oleaut32: Implement SLTG union type processing.
by Dmitry Timoshkov (＠dmitry) June 8, 2026

June 8, 2026

Looks good to me. https://gitlab.winehq.org/wine/wine/-/merge_requests/11089 fixes a problem I've found while testing this patch in 32-bit and 64-bit prefixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10502#note_142420

1 0