April 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

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

Announcing WineConf 2025
by Alexandre Julliard 24 Apr '25

24 Apr '25

Folks, It's been a while, so it's time for another WineConf! Given that a large proportion of the Wine devs are working for CodeWeavers, we thought that we'd do WineConf right after our annual company meeting, to take advantage of most people being in town already. So the plan is to hold WineConf on Saturday September 27, 2025. The location is The Hague, Netherlands. In fact it will be the exact same venue as WineConf 2018, which I'm sure many of you remember fondly ;-) You can find all the details here: https://gitlab.winehq.org/wine/wine/-/wikis/WineConf/WineConf-2025 Please note that we ask people to register so that we can get a headcount for the hotel. Attending is free of charge, and travel sponsorship is available. Looking forward to seeing many of you there! -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine staging 10.6 release
by Alistair Leslie-Hughes 21 Apr '25

21 Apr '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.6 (333 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * user32: Call UpdateWindow() during DIALOG_CreateIndirect. * Send WM_NCPOINTERUP on focus regain. * cryptext: Implement CryptExtOpenCER. Removed (No longer required). * d3dx9_36-DDS (fixed upstream) Added: * None Updated: * vkd3d-latest * odbc32-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.

1 0

Upcoming vkd3d 1.16 release
by Henri Verbeet 15 Apr '25

15 Apr '25

Hi all, The planned release date for vkd3d 1.16 is May 20. That means the public API will become frozen a week from now on April 22, and features will be frozen two weeks before the release, on May 6. This (of course) does not mean that development should slow down or stop; 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.17 is August 21. Regards, Henri

1 0

Apple Silicon compilation
by robert lippmann 09 Apr '25

09 Apr '25

Hi all, I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through. Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies So: brew install lld Then: PATH=`brew —prefix llvm`/bin:`brew —prefix bison`/bin:$PATH Then everything compiles. You probably don’t even need Xcode. And you probably should have Rosetta2 installed. I haven’t actually been able to get it to run yet, though… — Rob

5 8

Wine staging 10.5 release
by Alistair Leslie-Hughes 05 Apr '25

05 Apr '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.5 (336 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Add support for _NET_ACTIVE_WINDOW. * user32: Before asking a WM to activate a window make sure that the window is in foreground and not minimized. * shell32: Added stub for IEnumObjects interface. * shell32: Added stub for IObjectCollection interface. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * ntdll-Syscall_Emulation * ntdll-ForceBottomUpAlloc 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

Re: Troubleshooting openSUSE's packaging process
by Alexander Leithner 05 Apr '25

05 Apr '25

Am 04.04.25 um 15:44 schrieb Alexandre Julliard: > Alexander Leithner <aleithner(a)level101.at> writes: >> Shouldn't GCC provide support for -mabi=ms out of the box? > > Yes, there must be something else going on. Is the config.log file > available? OK, I've managed to extract config.log from a local OBS build. The section relevant to -mabi=ms reads: configure:20674: checking for working -mabi=ms configure:20693: gcc -m64 -c -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -mabi=ms conftest.c >&5 conftest.c: In function 'a': conftest.c:165:79: error: control reaches end of non-void function [-Werror=return-type] 165 | int a(int b, ...) { __builtin_ms_va_list list; __builtin_ms_va_start(list,b); } | ^ cc1: some warnings being treated as errors configure:20693: $? = 1 Indeed, the build script on OBS exports a bunch of additional flags before configuring Wine as seen above, including setting -Werror=return-type. Running configure with CFLAGS='-Werror=return-type ' also is enough to reproduce OBS' config.log output locally on my machine. Is this a bug in -mabi=ms detection or should OBS not set -Werror=return-type? As a side note, OBS also enables Fortify. Isn't this subsequently disabled by configure anyway? If so, I imagine OBS could just not enable it in the first place, right? Thanks for your help! Best, Alexander Leithner

2 2

Wine with 64 bit prefix and databases
by Ilya Sokolov 04 Apr '25

04 Apr '25

Hello It may be not the best place to send the question to this list, but I have tried it on different forums and got no answer. I have a windows C++ application, which should be run in x64 environment due to a memory consumption. One of users of the application requires it run on Linux. The application is rather big and uses some windows-specific features, like COM interfaces, so it would be hard to make it cross-platform. Therefore it was decided to try running the application under Wine. The application uses an MS Access database , which contains some parameters and settings for calculations. The application successfully runs under WINE until it tries to connect to the database, because there is no ADO data provider available. I have tried installing MDAC via winetricks, downloading and installing Access Runtime 2010 and 2016, but all with ho success. Could you tell me what is the proper way of setting up the access ADO driver in WINE in x64? If it is not possible now, could you tell me if any database works on wine in 64 bit prefix, so I will change the database type in the application. Thank you! Best Regards, Ilia Sokolov

2 1

Troubleshooting openSUSE's packaging process
by Alexander Leithner 03 Apr '25

03 Apr '25

Hi all, back in October [1] I asked for advice on building Winelib DLLs because I was unable to compile 64-bit DLLs on my openSUSE Tumbleweed machine. I've since opened bug 1231820 [2] on openSUSE's Bugzilla that has yet to be resolved (which I understand, given that developing Wine-only applications is pretty niche, I reckon). While I can now (with Wine 10.0 from openSUSE's repositories) compile 32-bit Winelib DLLs without having to explicitly specify the library search path, 64-bit DLLs still don't work. This is because the packages are missing the relevant archive files (*.a) for 64-bit ELF; that is, all the libraries (*.so) are present in /usr/lib64/wine/x86_64-unix, but the corresponding *.a files are not. I was trying to troubleshoot this earlier today but I'm now lost (since I cannot, for the life of me, reproduce the build process behaviour) and would be grateful for any discussion of what I might be misunderstanding/doing wrong or what might be going wrong with the packaging process. The first noteworthy observation is that the RPM spec file [3, see lines 367-449] excludes all archive files when the package built is not the "-devel" variant, which is fine, but only includes the i386-unix archives when "-devel" is built. That is probably an oversight, but not the main problem, I reckon. Namely: The x86_64-unix *.a files do not show up in the build logs [4] at all (Ctrl-F for "unix/libwinecrt0.a", for example). Even more, RPM itself complains that the files it should exclude are not found when building the non-devel variant of the package (Ctrl-F for "not found", messages around the 999s mark). This, to me, indicates that the files aren't even built. As can be seen in the logs, openSUSE uses the following ./configure command line to build 64-bit Wine: ../configure --host=x86_64-suse-linux --build=x86_64-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --enable-win64 --verbose (I've omitted prefix- and dir-related switches). I've built Wine from source with the following command line: ../configure [...] --build=x86_64-suse-linux --build=x86_64-suse-linux --enable-win64 (I've omitted --prefix only here). This produces an environment which can correctly build both 32-bit as well as 64-bit Winelib DLLs (without needing to set -L explicitly, as expected). I can see install-sh calls, as expected, for the *.a files in lib64/x86_64-unix, which are absent from the OBS build logs. My commandline generates lib64/x86_64-unix and lib64/x86_64-windows. On the other hand, the openSUSE build log for wine-devel-32bit [5] shows the i386-unix archive files being generated and installed. For 32-bit, they're using: ../configure --host=i586-suse-linux --build=i586-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --verbose Since I don't expect --with-x --with-wayland --with-gstreamer --verbose to change anything on whether archive files are built, how come the 64-bit build on OBS is not providing these *.a for x86_64-unix? I posted some more commandlines which don't seem to work correctly to the linked Bugzilla issue [2] back in December. I'm unsure if any of those I've tried there should be expected to produce correct results, so I'm focused on understanding of what's wrong with the 64-bit OBS build. Thanks for any insight, advice, pointers, or corrections you might have for me. Regards, Alexander Leithner [1]: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/th… [2]: https://bugzilla.opensuse.org/show_bug.cgi?id=1231820 [3]: https://build.opensuse.org/projects/openSUSE:Factory/packages/wine/files/wi… [4]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/wi… [5]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/i586/wine…

2 1