July 2025 - Wine-devel - list.winehq.org

Gitlab News
by Alexandre Julliard 15 Sep '25

15 Sep '25

Folks, As you may have noticed, now that the ARM64 support is done (just kidding), I've picked up the work on the Gitlab migration: 1. The Wiki has been moved to Gitlab, it's now at [1]. Existing URLs to the previous Wiki are redirected to the appropriate page. There are also separate Wikis for appdb, vkd3d and wine-staging, under their respective project pages. As part of the migration I've done some minor edits, but most of the Wiki is badly out-of-date, and could use some love. Help is welcome! Check the Writers page [2] for details on how to contribute. 2. We are now hosting the Mono project on the WineHQ Gitlab [3]. Please join me in welcoming the Mono developers to our community! 3. We have new hardware for the Gitlab server, which is now noticeably faster. Thanks to Jeremy Newman for setting this up! This also made it possible to enable robots.txt again so that our content is indexed. The next step will be to install new hardware for the Gitlab runners to offer more CI bandwidth. 4. The Gitlab issue tracker is currently disabled because it was attracting too much spam. I'm going to re-enable it, first for use by Mono, and then ultimately also for Wine itself. To fight the spam I'm planning to add an explicit user verification step, modelled along the procedure used by Freedesktop.org [4]. 5. As part of the new sign-up process, I think it would be a good idea to have an explicit Code of Conduct to spell out our expectations. Instead of reinventing the wheel, I propose that we adopt the Contributor Covenant [5] that many other projects (including Mono) are already using. Thoughts? Questions? Comments? [1]: https://gitlab.winehq.org/wine/wine/-/wikis [2]: https://gitlab.winehq.org/wine/wine/-/wikis/Writers [3]: https://gitlab.winehq.org/mono [4]: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home [5]: https://www.contributor-covenant.org/ -- Alexandre Julliard julliard(a)winehq.org

4 4

Travels
by Alexandre Julliard 21 Jul '25

21 Jul '25

Folks, Just a heads up that I'm going to be traveling for the next 3 weeks. I'm still going to review and commit MRs, but on a somewhat irregular schedule. Also there won't be a new release during that time, so Wine 10.13 will be out on August 15. -- Alexandre Julliard julliard(a)winehq.org

1 0

Upcoming vkd3d 1.17 release
by Henri Verbeet 17 Jul '25

17 Jul '25

Hi all, The planned release date for vkd3d 1.17 is Thursday August 21. That means the public API will become frozen a week from now on July 24, and features will be frozen two weeks before the release, on August 7. 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 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 1.18 is November 20. 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

How to use AddressSanitizer with Wine?
by Alex Henrie 13 Jul '25

13 Jul '25

Dear oenologists, I would like to use GCC's AddressSanitizer [1] to investigate a memory corruption bug in Wine. There must be a way to do it because I see multiple references to "ASan" in the Wine commit log in commits from this year.[2] I found some instructions on the WineHQ wiki,[3] but I get a myriad of linker errors when I try to follow them. What Linux distributions can successfully compile Wine with libasan? Are there special steps not mentioned in the wiki? Does AddressSanitizer work with MinGW, or only with non-PE builds? I'd love to get AddressSanitizer working myself, but even if I can't, thanks to Bernhard and Nikolay for using it to fix a lot of bugs already. -Alex [1] https://github.com/google/sanitizers/wiki/AddressSanitizer [2] https://gitlab.winehq.org/wine/wine/-/commits/master?search=ASan [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c…

2 5

Wine staging 10.12 release
by Alistair Leslie-Hughes 12 Jul '25

12 Jul '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.12 (292 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [52278] comctl32: Animate support AVI msvc codex. * [36686] msxml: Support ISAXXMLReader::putFeature normalize-line-breaks option Updated: * msxml3-element_props 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

Add option to winebuild to disable ASLR/dynamicbase
by Tres Finocchiaro 09 Jul '25

09 Jul '25

Hi, I'm a maintainer of LMMS and we use a wine bridge for loading 32-bit and 64-bit VST plugins into the Linux version of our software. We've recently updated our build tools and noticed that some of our older 64-bit VSTs fail to load. After a lot of back and forth, we've isolated the issue to the following wine commit: > Commit 518e394 julliard committed on Sep 25, 2023 > winebuild: Set ASLR-related dll flags by default. > https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f5… One of our developers has proposed a patch which reverts this behavior here: https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12… My questions are as follows: 1. Would winehq be receptive to a winebuild flag that allows the old behavior? 2. If acceptable, would you prefer LMMS author this patch, or is this change trivial enough/small enough that the winehq team would prefer to tackle it themselves? 3. Lastly, quoting a past mailing list convo, should we be doing our wine bridge differently? Currently we build RemovePluginVst64.so.exe. "[...] I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way [...]" Source: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/me… Thanks kindly for your time, -Tres - Tres.Finocchiaro(a)gmail.com

4 9