- Wine-devel - list.winehq.org

UnixLib
by imichaelost＠gmail.com 19 Jan '26

19 Jan '26

1 0

Availability of wine-devel/wine-gitlab archives
by Dmitry Timoshkov 18 Jan '26

18 Jan '26

Hi all, recently I tried to lookup some previously discussed things in wine-devel archives and was surprised that neither winehq.org nor archive.org provide something useful, all the links I tried don't work. The things get a bit more complex due to transition from pipermail to hyperkitty and current system. Is it possible to make old archives available again and fix access to current wine-devel/wine-gitlab archives? Thanks. -- Dmitry.

4 7

Upcoming vkd3d 1.19 release
by Henri Verbeet 15 Jan '26

15 Jan '26

Hi all, The planned release date for vkd3d 1.19 is Thursday February 19. That means the public API will become frozen next week on January 22, and features will be frozen two weeks before the release, on February 5. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure that any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 2.0 is Thursday May 21. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

1 0

Wine staging 11.0 release
by Alistair Leslie-Hughes 13 Jan '26

13 Jan '26

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.0 (252 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: * None 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

List unsubscribe.
by Philippe Groarke 13 Jan '26

13 Jan '26

4 3

11.0 release notes (please review)
by Alexandre Julliard 12 Jan '26

12 Jan '26

Folks, Here are the tentative release notes for 11.0. Please review them and let me know if anything is incorrect or missing. Many thanks to Esme, Jacek, Michael, Piotr, Rémi, Vibhav and Zeb for their contributions! I'm planning to release the final 11.0 tomorrow. -- Alexandre Julliard julliard(a)winehq.org

3 3

Wine staging 11.0-rc5 release
by Alistair Leslie-Hughes 09 Jan '26

09 Jan '26

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.0-rc5 (252 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: * None 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

Handling page faults in syscalls
by tblodt＠icloud.com 27 Dec '25

27 Dec '25

I just had a bit of a frustrating moment debugging why winecfg was crashing in my freshly built tree, and discovered something that many of you probably already know but is new to me: Wine swallows page faults that happen inside a syscall and just unwinds the stack to the caller returning an error, with only a trace level log. This seems surprising - normally page faults indicate a bug and need to be reported. And also scary - the code behind the syscall boundary can be anything, not necessarily part of the wine project, possibly even platform libc, and therefore not safe to unwind. My guess is these are caught instead of killing the process because that's the expected behavior of an NT syscall when you pass a bad pointer to it - that a bad dereference of a userspace pointer would be handled and turned into returning an fault error code. Is this right? But then what would actually make sense is to write separate functions for safely dereferencing user pointers, like Linux has. What should ideally be happening here? ~Theodore

2 3

Wine staging 11.0-rc4 release
by Alistair Leslie-Hughes 27 Dec '25

27 Dec '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.0-rc4 (252 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: * None 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

Question about AI-generated code policy
by mcm＠etersoft.ru 25 Dec '25

25 Dec '25

Hello everyone, I would like to raise a question about Wine's policy on code generated by Large Language Models (LLMs). Several large open-source projects, including NetBSD, QEMU, and Gentoo, have already stated their strict position about contributing such code [1] [2] [3], but I found no results related to this topic in either the Wine Developer's Guide [4] or wine-devel archives [5]. Would it make sense to formalize a clear code policy regarding code generated by LLM and add it to the Developer's Guide? This would be relevant for both the main Wine tree and the tests subsystem. Best regards, Y. Osipov [1]: https://www.netbsd.org/developers/commit-guidelines.html#tainted [2]: https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-gener… [3]: https://wiki.gentoo.org/wiki/Project:Council/AI_policy [4]: https://gitlab.winehq.org/wine/wine/-/wikis/Wine-Developer%27s-Guide [5]: https://list.winehq.org/archives/search?mlist=wine-devel%2540list.winehq.org

1 1