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

Travels

by Alexandre Julliard

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

July 21, 2025

Upcoming vkd3d 1.17 release

by Henri Verbeet

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

July 17, 2025

Re: How to use AddressSanitizer with Wine? (80% PE approach)

by Bernhard Übelacker

Hello, I rebased the current state of the this ASan experiment here [1]. It no longer uses the mingw wrappers of clang. Unfortunately this made a few other modifications necessary to initialise ASan. Results of running the conformance tests with this branch can be found in [2] [3]. Thanks to the efforts of Yuxuan Shui to actually fixing those the list got already much shorter. [1] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-07-04_wine-10.… [2] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-07-04_wine-10.… [3] https://gitlab.winehq.org/bernhardu/wine/-/tree/asan-pe_2025-07-04_wine-10.… Kind regards, Bernhard

July 13, 2025

Wine staging 10.12 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 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.

July 12, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Tres Finocchiaro

Bug report filed here: https://bugs.winehq.org/show_bug.cgi?id=58480 >

July 9, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Tres Finocchiaro

> > Disabling the flag may or may not be the right solution, but the first > thing is to understand exactly why that flag is breaking your app. Filing a > bug would be a good first step. Disabling the flag is how we need to fix this for older DLLs on MSVC and mingw. Can you help me understand what the purpose of a bug report to winehq is? I certainly don't mind writing one, but this issue is "solved" for other DLL compilers. Quoting the PR-thats-leading-to-burnout from our gracious user: > "Address Space Layout Randomization (ASLR) is a security technique that > randomizes the location of several key memory areas in order to make it > harder to use memory corruption exploits (Wikipedia). Sadly, several old > VST dlls crash when ASLR is in use (see bug #7830). This PR adds linker > flags to disable ASLR when building RemoteVstPlugin Windows executables. > The main program (lmms.exe) is still built with ASLR enabled" Note that this regression aligns with both mingw AND wine addition of DYNAMICBASE features. Finding this regression actually FINALLY allows these VST plugins to work with MSVC which they never have before, so we're actually very excited about this flag. What's hard for me to speak on behalf of -- please accept my apologies here -- is that I'm not a very "good" C/C++ developer despite my tenure on the LMMS project -- so, if this crash could be avoided through other means I'm not sure, however I'm also not sure how far down the rabbit hole we would need to (or should?) go for this to be properly explained (nor whether or not I'm qualified to understand or explain this). LMMS has an external plugin system, we load a plugin for handling the IPC stuff and that plugin -- which we call RemoteVstPlugin[32|64].exe -- is responsible for starting and interacting with the DLL. In the case of the Synth1 instrument mentioned in an earlier email, the plugin plays a single note fine, but crashes when a second note is played. Using a debugger on this is difficult due to the the lmms --> remote plugin --> vst plugin, however as a project maintainer, I trust and follow the findings of this musician/developer helping. The TL;DR of this is in our Discord #dev-forum thread here: https://discord.com/channels/203559236729438208/1383830615429877851 (invite link available via https://lmms.io/chat) where the OP and I have spent weeks trying various things to isolate this regression. Mingw even mentions the possibility of this breaking things in their changelog, quoting: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default > 2021-01-31 - ASLR enabled by default > > About 5 months ago we started backporting patches to our binutils 2.35 to > allow enabling ASLR support via various flags. We also enabled these flags > in our build system, so any package in our repo that was updated in the > last 5 months has ASLR support enabled. > > > We've now updated to 2.36 which has ASLR enabled by default. Ideally you > shouldn't notice any changes, but in case this leads to problems all of it > can be disabled/reverted via linker flags: > > > mingw64: > -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low > > mingw32: -Wl,--disable-dynamicbase > > Note that this is only a temporary workaround and some of these flags > will not be available forever, so you should either fix your code or file a > bug in case you suspect a toolchain issue. As an argument AGAINST this flag for winebuild, mingw DOES warn against this flag as being a candidate for future removal, however since MSVC makes no mention of removing this build option on the Windows-side, I'm hopeful that mingw mimics Microsoft's lead on this platform. https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase I'd be happy to write-up a bug report if you think it's helpful, but I'm not certain I'll have PE (or even LMMS code) knowledge needed to "explain why this flag is breaking our app" aside from the high-level fact that these DLLS we talk to are often older than Vista when this feature was added.

July 9, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Alexandre Julliard

Tres Finocchiaro <tres.finocchiaro(a)gmail.com> writes: > There are no plans to remove that ability. It's true that there's > currently no stable, supported way to build external PE dlls with a Unix > side, but that's mostly because there's > > So would it be inappropriate for me to ask again, why adding a flag to winebuild to influence the PE section of a Unix SO -- specifically for > compatibility with older, 3rd-party DLLs that we don't have the ability or interest modifying -- would be frowned upon? (particularly as opposed > to the seemingly more complex WINE_UNIX_CALL approach) Disabling the flag may or may not be the right solution, but the first thing is to understand exactly why that flag is breaking your app. Filing a bug would be a good first step. > Searching for 'winebuild', 'winegcc' or 'wineg++' in SCMs like GitHub show a very short list of results (many of which are simply wine mirrors). > Doing the same on stackoverflow yields 65 results for all three keyworks combined, which makes it hard to gauge the importance or longevity > of a tool. > > At the end of the day, what LMMS hopes for is a way to run a DLL file at maximum compatibility from a native *nix app. I don't know much > about the inner workings, but it's a feature we'll keep in the software for as long as we can maintain it. I've even added experimental support to > our ARM64 Linux versions (not yet working) and I would like to eventually add support to our macOS versions as well (missing winegcc). I > digress. Not that both ARM64 and macOS will require a PE build. There's no way to make a .so dll work on these platforms because their Unix ABI is not compatible with the Windows one. -- Alexandre Julliard julliard(a)winehq.org

July 9, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Tres Finocchiaro

> > There are no plans to remove that ability. It's true that there's > currently no stable, supported way to build external PE dlls with a Unix > side, but that's mostly because there's > So would it be inappropriate for me to ask again, why adding a flag to winebuild to influence the PE section of a Unix SO -- specifically for compatibility with older, 3rd-party DLLs that we don't have the ability or interest modifying -- would be frowned upon? (particularly as opposed to the seemingly more complex WINE_UNIX_CALL approach) > "nobody who cares enough about it to invest time into designing and > implementing that support." I feel this. LMMS is a project that's forever been barely held together by a shoestring team of bug hunters. The wine bridge that it uses -- specifically --- has long been a mystery to the team and troubleshooting issues with it often turn to burn-out. We're fortunate to have had a musician step in to deep-dive on this crash, but this is without consequence... quoting: > "(potentially off-topic but relevant to the pace of this work: day before > yesterday I kinda collapsed after opening PR #7987 . I took a break > yesterday and am feeling somewhat better today, but my body is telling me > in no uncertain terms that I need to put less pressure on myself working on > all this. I'm gonna try to take it slower, but I'm not sure how much I'll > be able to get done in the near future, especially if things escalate into > a lot of extra complexity)" Searching for 'winebuild', 'winegcc' or 'wineg++' in SCMs like GitHub show a very short list of results (many of which are simply wine mirrors). Doing the same on stackoverflow yields 65 results for all three keyworks combined, which makes it hard to gauge the importance or longevity of a tool. At the end of the day, what LMMS hopes for is a way to run a DLL file at maximum compatibility from a native *nix app. I don't know much about the inner workings, but it's a feature we'll keep in the software for as long as we can maintain it. I've even added experimental support to our ARM64 Linux versions (not yet working) and I would like to eventually add support to our macOS versions as well (missing winegcc). I digress. Help is welcome. I can offer a patch to add this feature to winebuild, but since this offer was initially shot down, I'm not sure the best way to proceed. I understand by maintaining other FOSS projects, adding a flag isn't the same as "helping" a project and I don't want to escape obligation here, but we too are struggling with help on the LMMS side and I hope that my request is seen as a humble ask and not as demanding or needy. We'd like to support these older DLLs for the short-term using a technique we know works and long-term a technique we would expect to eventually work and were receptive to change but also extremely limited on "help". <3

July 9, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Alexandre Julliard

Elizabeth Figura <zfigura(a)codeweavers.com> writes: > Building split PE DLLs outside of the Wine build system is a lot less > trivial, and while there's been basically no communication from the > Wine project about deprecation or API stability, I'm inclined to > believe there's no stable way to do it. (Frankly, as far as I can > tell, the Wine project intends to simply deprecate and remove the > ability to build external DLLs due to perceived lack of use.) There are no plans to remove that ability. It's true that there's currently no stable, supported way to build external PE dlls with a Unix side, but that's mostly because there's nobody who cares enough about it to invest time into designing and implementing that support. Help is welcome. -- Alexandre Julliard julliard(a)winehq.org

July 8, 2025

Re: Add option to winebuild to disable ASLR/dynamicbase

by Tres Finocchiaro

> > We've recently updated our build tools and noticed that some of our older > 64-bit VSTs fail to load. Sorry if this initial statement was ambiguous, but for clarification, LMMS doesn't actually build any VST DLLs. Instead, these are 3rd-party VST DLLs (usually music instruments and audio effects) that have been created over the past 25 years (largely for commercial software like FLStudio, Ableton, Acid, etc) that LMMS also tries to be compatible with. Since they're loaded with our LMMS-wine-bridge (RemoteVstPlugin.so.exe), we're directly impacted by the addition of DYNAMICBASE of this executable. Our unit-testing is using the Synth1 DLL which was created in 2014 https://daichilab.sakura.ne.jp/softsynth/index.html. >

July 8, 2025