December 2025 - Wine-Devel - list.winehq.org

Re: Handling page faults in syscalls

by Stefan Dösinger

> Am 23.12.2025 um 10:41 schrieb tblodt(a)icloud.com: > I think I think of it like, the responsibility for fixing this kind of problem is on the packager, and it would be much better to fail noisily so it can be caught earlier by the people who should be fixing it. On Linux external libraries are usually provided by the distribution. I think a concern is that we don't want so spam the user if e.g. the 32 bit LDAP library fails to load. For things like GL/Vulkan/d3d there is usually a more obvious message if the application does try to make use of it rather than just accidentally linking to ddraw. That said, I am not the one who wrote the syscall infrastructure, so I am just guessing here.

Dec. 27, 2025

Wine staging 11.0-rc4 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.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.

Dec. 27, 2025

Re: Question about AI-generated code policy

by mcm＠etersoft.ru

The main concern to contributing LLM-generated code I see is that such code cannot be checked for its primary source, and so for its license as a consequence, which would likely conflict with Clean Room Guidelines [1] and actually violate the Developer Certificate of Origin. [1] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines

Dec. 25, 2025

Question about AI-generated code policy

by mcm＠etersoft.ru

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

Dec. 23, 2025

Re: Handling page faults in syscalls

by tblodt＠icloud.com

> Some of the unexpected syscall faults I debugged happened because of > incorrectly set up host libraries - libGL segfaulting when trying to create a > context, gnutls or kerberos crashing when trying to load them. It turned out that the thing I was chasing originally was actually such a case (I pointed DYLD_LIBRARY_PATH at homebrew, which somehow made macos frameworks load a homebrew library instead of the framework's, which was missing some symbols it depended on, and... https://github.com/apple-oss-distributions/dyld/blob/3d96227e8b4626b8e6aa4b…) I would really have preferred if it crashed out. I think I think of it like, the responsibility for fixing this kind of problem is on the packager, and it would be much better to fail noisily so it can be caught earlier by the people who should be fixing it. > On the other hand, a Windows-side STATUS_ACCESS_VIOLATION also won't print > anything by default, there are many applications that generate a ton of them > in their normal operation. Do you mean the analog of EFAULT, or installing a SIGSEGV handler, or something else? Those are indeed "normal" and shouldn't report as a problem but also not what i'm talking about :p ~Theodore

Dec. 23, 2025

Re: Handling page faults in syscalls

by Stefan Dösinger

Am Dienstag, 23. Dezember 2025, 02:12:57 Ostafrikanische Zeit schrieb tblodt--- via Wine-devel: > 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. Some of the unexpected syscall faults I debugged happened because of incorrectly set up host libraries - libGL segfaulting when trying to create a context, gnutls or kerberos crashing when trying to load them. Those are not necessary for the base functionality of Wine, so we don't want to crash and burn due to it. I don't know if that's the real reason for the silent swallowing of SIGSEGVs. It is something to keep in mind though when changing the behavior. I ran into cases myself where I wish I had gotten more obvious notifications. The Vulkan code has assert(!status) after most calls after basic initialization, which will make a syscall sigsegv fatal. On the other hand, a Windows-side STATUS_ACCESS_VIOLATION also won't print anything by default, there are many applications that generate a ton of them in their normal operation.

Dec. 23, 2025

Handling page faults in syscalls

by tblodt＠icloud.com

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

Dec. 22, 2025

Wine staging 11.0-rc3 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.0-rc3 (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.

Dec. 21, 2025

Wine staging 11.0-rc2 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.0-rc2 (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: * vkd3d-latest 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.

Dec. 13, 2025

Re: Introducing the list.winehq.org domain

by Alexandre Julliard

"Alexandre Julliard" <julliard(a)winehq.org> writes: > We are now ready for the second phase of the Wine mailing lists > migration, where we will move the lists to a different server. We have > selected mailmanlists.net to host our lists. > > The plan is for the migration to happen on Monday December 8. There may > be a downtime of a few hours while we get everything settled. OK, https://list.winehq.org is now our new server, and everything should be back in working order. There have been quite a few glitches during the transition, thank you all for bearing with us during that process. And many thanks to Jeremy Newman for taking care of everything! As noted, you now have to use the @list.winehq.org address to post to the lists. The List-Id header has changed and matches the list name, so for instance, for wine-devel(a)list.winehq.org the List-Id will be <wine-devel.list.winehq.org>. Also as mentioned, subscriptions have been transferred, but not individual user accounts, so if you had created an account on the old server to change your preferences, you'll need to create a new one at https://list.winehq.org. The mailing list archives are up and running at a new URL: https://list.winehq.org/archives. We are hoping to get a redirect in place from the old URL shortly. If you find any other issues with the new server please let me know, -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2025