- Wine-Devel - list.winehq.org

Project creation permission request
by павел June 22, 2026

June 22, 2026

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

1 0

[RFC] server: report a stream socket writable while its send buffer has room
by wine-devel＠forryan.co.uk June 20, 2026

June 20, 2026

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

2 2

Wine staging 11.11 release
by Alistair Leslie-Hughes June 13, 2026

June 13, 2026

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.

1 0

Multiple test failures in Gitlab's CI
by Barath Rk June 9, 2026

June 9, 2026

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.

2 3

Spout2PW, Wine 11, and on GPU Shared Handles
by madalee＠ohlmeyers.com June 3, 2026

June 3, 2026

Hello All, I'm trying to adapt Lina's Spout2Pw to the new restrictions in Wine 11 and constantly failing. Am I right in understanding that there is no current method to pass a handle to GPU shared memory between the Wine/Linux barrier? I've proven out that I can do this with CPU accessible RAM, but every method I've tried with VRAM fails. I saw mention of KMT being supported in DXVK and maybe in Wine 11. I've tried using it, but, at least as of Proton 11, I think KMT doesn't work for sharing memory handles yet. Is there any method of doing this that anyone can suggest, for Wine 11, or any versions of Wine 11 that this should work with? Thanks, -Madalee

1 0

GitLab merge warnings
by Alex Henrie May 30, 2026

May 30, 2026

Hello Wine maintainers, Currently, unless a merge request is based on the absolute latest upstream master branch, GitLab displays the following warnings: ⛔ Merge blocked: 1 check failed ⛔ Fast forward merge is not possible. Please rebase. More than once, I've seen well-meaning contributors follow those instructions and rebase their merge requests every single day to resolve the warning. That adds pointless noise to the merge request and wastes time rerunning the test suite. GitLab 19.0 introduced a new feature to suppress those warnings, called "automatic rebase".[1] To enable it, a GitLab administrator needs to go to the project Settings, click "Merge requests", under "Fast-forward merge" check the box "Enable automatic rebase prior to merge", and click "Save changes". Can we please update gitlab.winehq.org to GitLab 19.0 and enable automatic rebase on all of the WineHQ projects? Since few people are allowed to merge MRs and none of you seem to actually do merges via the GitLab UI, the change should be purely cosmetic and not affect your workflow at all. -Alex [1] https://gitlab.com/gitlab-org/gitlab/-/work_items/895

3 2

Wine staging 11.10 release
by Alistair Leslie-Hughes May 30, 2026

May 30, 2026

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.10 (287 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [45364] - Frostpunk is very dark * [57980] - kernel32: Implement SetThreadpoolTimerEx. * [43703] - rtscom: Rebelle demo crashes when using "Microsoft Ink compatible" tablet * [31554] - inkobj: PDF Annotation crashes on second startup 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.

1 0

Feedback needed for a theme PR
by fatihbakal7＠protonmail.com May 27, 2026

May 27, 2026

I currently need feedback as to how to implement a theming improvement to wine. My recommendation is that all prefixes use $HOME/.config/wine.msstyle/.theme if possible. I was told this is the place to ask for feedback. Please see https://gitlab.winehq.org/wine/wine/-/merge_requests/10920

7 16

Re: GitLab merge warnings
by Alex Henrie May 27, 2026

May 27, 2026

On Tue, May 26, 2026 at 2:16 PM Esme Povirk <esme(a)codeweavers.com> wrote: > > If it matters, I actually do use the GitLab UI to do merges. > > However, the GitLab UI discourages using it for rebases, linking to this > page: > https://gitlab.winehq.org/help/ci/pipelines/merge_request_pipelines.html#ru… > > Therefore, I do not use the GitLab UI to do rebases. Does the new > version address this somehow? If I understand that page correctly, it's just saying that merge requests can introduce malicious code that is run as part of the test suite before the merge request is actually merged. GitLab is just trying to warn you to not do test runs on untrusted code, and warn you that you clicking "Rebase" will automatically trigger a test run even if the merge request's author does not have permissions to do a test run. If you want to rebase without doing a test run, there is a separate "Rebase without pipeline" button on the merge request. The "automatic rebase" option that I'd like to enable effectively clicks "Rebase without pipeline" for you when you click "Merge".[1] I think the new option would be perfect for your workflow. -Alex [1] https://docs.gitlab.com/19.0/user/project/merge_requests/methods/#automatic…

1 0

Reference terminal for writing conformance tests for console functions
by Barath Rk May 25, 2026

May 25, 2026

I am trying to implement the ReadConsoleInputExW function, and while writing tests for the same, realized that the behaviour of my test programs vary across consoles inside my Windows 10 VM. For example, the output is different when I use cmd to run the tests versus using MSYS2(which uses mintty) to run the tests. My question is: should the behaviour exhibited by the test program when run on cmd in Windows be taken as the canonical reference in this case? If so, then when testing my implementation on the programs using wine, is it enough for the output in wineconsole to be consistent with the cmd output? Thanks in advance.

3 6