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

wine staging 11.12 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.12 (289 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * tiptsf: Add dll * tiptsf: Add ITextInputPanel interface stub * rtscom: New dll * rtscom: Add RealTimeStylus stubbed interface. Removed (No longer required). * winex11-ime-check-thread-data Added: * [55138] ntdll: Add read and write to new guard pages. Updated: * vkd3d-latest * comctl32_animate_avi (warning fixes) * windowscodecs-TIFF_Support (warning fixes) * mmsystem.dll16-MIDIHDR_Refcount (warning fixes) Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

June 29, 2026

Clean-Room guidelines + some general questions

by Hudson Finn

Hi guys, I just started looking around the codebase, and reading the wiki. This is my first time working with "Windows", as I've been daily-driving Linux for a long time. I have a few questions: - Do you guys have general recommendations for looking at Windows documentation/finding information about various Windows components and such? What's the deal with MSDN beyond it being sometimes wrong? Are there other things here to know about? - When debugging a problem with the Wayland driver, will running wine normally work? I use XWayland for a few apps that I use. Are there flags I should pass to ensure that I'm on native Wayland? Thanks guys! I'm looking forward to being able to contribute in the future!

June 26, 2026

Project creation permission request

by павел

Hello,I recently created an account on gitlab.winehq.org (my username is PavelCheloveckov)and would like to contribute a patch. However, I cannot fork thewine repository due to the project creation limit on new accounts.Could you please grant my account permission to create projects so I cansubmit a merge request?Thank you,Pavel

June 22, 2026

Re: [RFC] server: report a stream socket writable while its send buffer has room

by wine-devel＠forryan.co.uk

Good question. Short answer: on Linux, curl doesn't grow SO_SNDBUF itself; it leaves the send buffer to the kernel's autotuning. It's on Windows that libcurl actively grows it: because Windows doesn't autotune the send buffer the same way, libcurl periodically queries the ideal send backlog (SIO_IDEAL_SEND_BACKLOG_QUERY) and sets SO_SNDBUF from that. (That came out of curl's "Upload speed in Windows may be diminished", issue #2224.) But I don't think buffer size is the actual variable here; the stall is about writability reporting, and it reproduces independently of SNDBUF tuning. That's what the conformance test isolates: pure ws2_32 sockets, no curl, default buffers, just the invariant "select() reports writable iff send() would still accept data." Windows holds that invariant; unmodified Wine breaks it once the send queue passes ~2/3 of SO_SNDBUF (the Linux POLLOUT threshold), reporting not-writable while sends keep succeeding. Growing SNDBUF only moves that boundary to a larger absolute size; it doesn't close the gap. As for why native Linux curl never hits it: its multi loop waits with poll(), which is level-triggered, so it's woken the moment the socket is writable again, the Linux threshold just means it wakes slightly later, not that it stalls. The path that stalls is the Windows backend, which waits on WSAEventSelect/FD_WRITE (edge-triggered) behind a select() writability pre-check (curl #6146). Under Wine, that pre-check returns the wrong answer, so curl falls through to a full ~1s WSAWaitForMultipleEvents per burst. Making Wine's select() match Windows is what lets curl's existing pre-check work as designed. (Happy to also check whether Wine even implements SIO_IDEAL_SEND_BACKLOG_QUERY. If it doesn't, curl can't grow the buffer under Wine at all, but that'd be an orthogonal gap; the reporting fix stands either way, per the test.) Martyn

June 20, 2026

Re: [RFC] server: report a stream socket writable while its send buffer has room

by Elizabeth Figura

On Friday, 19 June 2026 22:56:09 CDT wine-devel--- via Wine-Devel wrote: > Hi all, > > Before I open a merge request, I’d like feedback on the approach, as it has a portability angle I’m unsure about. > > Question up front: the fix relies on TIOCOUTQ to query the amount of unsent data in a socket’s send buffer. That is Linux-specific. Is gating it on #ifdef TIOCOUTQ (leaving current behaviour unchanged elsewhere) acceptable, or would you prefer a different mechanism, or a different layer than poll_socket()? I’d rather hear that now than in review. > > On Windows, select() reports a connected stream socket writable whenever a send() would still accept data into the send buffer. Wine derives writability from the host poll(); on Linux POLLOUT is only set once the send queue has drained below roughly 2/3 of SO_SNDBUF. So while the buffer is between ~2/3 full and full, Windows says “writable” but Wine says “not writable” even though send() still succeeds. > > The common application pattern is a non-blocking select() writability check before waiting on an FD_WRITE event. libcurl’s multi loop does exactly this. Under Wine, an app-limited sender (sends keep succeeding, never hitting WSAEWOULDBLOCK) sees “not writable” while it still has room, and since FD_WRITE is edge-triggered and not re-recorded until a send fails, it waits out its full poll timeout (typically 1s) between bursts. Single-stream uploads end up throttled to ~140 KB/s. I found this with a libcurl-based backup client whose uploads could not finish within their timeout under Wine. > > Proposed fix: In poll_socket(), when the immediate poll() does not report POLLOUT for a connected stream socket that still has send-buffer room (TIOCOUTQ < SO_SNDBUF), report it writable. One small block, #ifdef TIOCOUTQ. This seems reasonable to me, probably, though I have to ask, what does curl do on linux? Does it adjust SNDBUF to be bigger? --Zeb

June 20, 2026

[RFC] server: report a stream socket writable while its send buffer has room

by wine-devel＠forryan.co.uk

Hi all, Before I open a merge request, I’d like feedback on the approach, as it has a portability angle I’m unsure about. Question up front: the fix relies on TIOCOUTQ to query the amount of unsent data in a socket’s send buffer. That is Linux-specific. Is gating it on #ifdef TIOCOUTQ (leaving current behaviour unchanged elsewhere) acceptable, or would you prefer a different mechanism, or a different layer than poll_socket()? I’d rather hear that now than in review. On Windows, select() reports a connected stream socket writable whenever a send() would still accept data into the send buffer. Wine derives writability from the host poll(); on Linux POLLOUT is only set once the send queue has drained below roughly 2/3 of SO_SNDBUF. So while the buffer is between ~2/3 full and full, Windows says “writable” but Wine says “not writable” even though send() still succeeds. The common application pattern is a non-blocking select() writability check before waiting on an FD_WRITE event. libcurl’s multi loop does exactly this. Under Wine, an app-limited sender (sends keep succeeding, never hitting WSAEWOULDBLOCK) sees “not writable” while it still has room, and since FD_WRITE is edge-triggered and not re-recorded until a send fails, it waits out its full poll timeout (typically 1s) between bursts. Single-stream uploads end up throttled to ~140 KB/s. I found this with a libcurl-based backup client whose uploads could not finish within their timeout under Wine. Proposed fix: In poll_socket(), when the immediate poll() does not report POLLOUT for a connected stream socket that still has send-buffer room (TIOCOUTQ < SO_SNDBUF), report it writable. One small block, #ifdef TIOCOUTQ. Conformance: I have a ws2_32:sock test (the invariant: select() reports writable exactly while send() accepts data). On the same test binary: * real Windows pass (0 violations) * Wine, unpatched fail (~230 of ~660 sends report not-writable yet send ok) * Wine, patched pass (0 violations) I’ll submit the test as a todo_wine commit ahead of the fix. One thing I tried and dropped: I first also changed FD_WRITE to re-arm on every send. A conformance test on real Windows showed Windows does NOT re-arm FD_WRITE after a successful send (only after WSAEWOULDBLOCK, matching MSDN), so that change would have diverged from Windows. The writability fix alone is sufficient and is the Windows-conforming part. For background, curl’s issue #6146 (https://github.com/curl/curl/issues/6146) documents this same select/FD_WRITE behaviour on Windows; curl’s workaround is the select()-before-wait pre-check in commit a69d1a4 (PR #5634, “multi: implement wait using winsock events”). That pre-check is exactly the path this fix unblocks under Wine. Bug: https://bugs.winehq.org/show_bug.cgi?id=59893 Happy to adjust the mechanism based on what you’d prefer here. Thanks, Martyn Forryan

June 20, 2026

Wine staging 11.11 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.11 (289 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * dcomp-DCompositionCreateDevice2 Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

June 13, 2026

Re: Multiple test failures in Gitlab's CI

by Barath Rk

However, I still have 4 failures in webservices/tests/writer.c where there are a few one-off failures(Opened a new MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/11094) From what I can tell, there is no call that goes to type. so it seems like it isn't a failure from my side. Am I missing something? On Tue, Jun 9, 2026 at 12:48 PM Barath Rk <barathrk11(a)gmail.com> wrote: > Thanks, I fixed the cmd test failures locally, added a new test and pushed > the changes. > > > On Mon, 8 Jun, 2026, 8:11 am Zhiyi Zhang, <zzhang(a)codeweavers.com> wrote: > >> It looks like those CI test failures are related to your changes. So you >> should fix them. >> >> On 6/8/26 09:53, Barath Rk via Wine-Devel wrote: >> > I recently created this MR in Gitlab: >> https://gitlab.winehq.org/wine/wine/-/merge_requests/11079 which had 52 >> test failures in the CI. >> > >> > However, some other merged requests appear to similarly have many >> failures. My question is, should I attribute these test failures to a flaky >> CI and just wait for review, or try to resolve it on my end? >> > >> > Thanks in advance. >> >>

June 9, 2026

Re: Multiple test failures in Gitlab's CI

by Barath Rk

Thanks, I fixed the cmd test failures locally, added a new test and pushed the changes. On Mon, 8 Jun, 2026, 8:11 am Zhiyi Zhang, <zzhang(a)codeweavers.com> wrote: > It looks like those CI test failures are related to your changes. So you > should fix them. > > On 6/8/26 09:53, Barath Rk via Wine-Devel wrote: > > I recently created this MR in Gitlab: > https://gitlab.winehq.org/wine/wine/-/merge_requests/11079 which had 52 > test failures in the CI. > > > > However, some other merged requests appear to similarly have many > failures. My question is, should I attribute these test failures to a flaky > CI and just wait for review, or try to resolve it on my end? > > > > Thanks in advance. > >

June 9, 2026

Re: Multiple test failures in Gitlab's CI

by Zhiyi Zhang

It looks like those CI test failures are related to your changes. So you should fix them. On 6/8/26 09:53, Barath Rk via Wine-Devel wrote: > I recently created this MR in Gitlab: https://gitlab.winehq.org/wine/wine/-/merge_requests/11079 which had 52 test failures in the CI. > > However, some other merged requests appear to similarly have many failures. My question is, should I attribute these test failures to a flaky CI and just wait for review, or try to resolve it on my end? > > Thanks in advance.

June 8, 2026