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/518e394794160818ffe6826c874ff2f55...
One of our developers has proposed a patch which reverts this behavior here: https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12f...
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@winehq.org/messa...
Thanks kindly for your time,
-Tres
- Tres.Finocchiaro@gmail.com
On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro tres.finocchiaro@gmail.com wrote:
- Would winehq be receptive to a winebuild flag that allows the old
behavior?
Probably not. Wine's goal is first and foremost emulation of Windows
userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
- 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?
- 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@winehq.org/messa...
Yes, ideally you're supposed to not rely on specific address of DLLs. If
you want to call Unix-specific APIs, the most up-to-date way to do is to use something called *unixlibs*.
I'm not aware of any documentation or tutorial, but you can consult existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL).
Wine's goal is first and foremost emulation of Windows userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
Hi,
I'm not sure I understand this stance since both mingw and msvc provide full control over the DYNAMICBASE flag at compile time. In our case, we MUST be able to control this flag for compatibility with older DLLs to maximize compatibility with our software, otherwise the non-Windows versions of LMMS would have an artificially imposed regression/limitation over versions targeting Windows directly. In practice, this means that a large percentage of older VST plugins will just stop working overnight, simply because we used a modern version of wineg++ to compile our bridge.
I'm not aware of any documentation or tutorial, but you can consult
existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL).
Thanks for the pointer. Depending on how successful (or more specifically, lack thereof), we may need to build a custom winebuild for the foreseeable future. We already plan to do this for the short-term, but as other wineg++ apps run into crashes when ASLR/DYNAMICBASE is enabled, this is likely to be requested again in the future.
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.
On Monday, 7 July 2025 17:45:55 CDT Jinoh Kang wrote:
On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro tres.finocchiaro@gmail.com wrote:
- Would winehq be receptive to a winebuild flag that allows the old
behavior?
Probably not. Wine's goal is first and foremost emulation of Windows userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
It's also rather worth investigating why this happens...
- 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@winehq.org/messa...
Yes, ideally you're supposed to not rely on specific address of DLLs. If you want to call Unix-specific APIs, the most up-to-date way to do is to use something called *unixlibs*.
I'm not aware of any documentation or tutorial, but you can consult existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL).
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.)
If you're able to deal with the instability, I've written up some instructions here:
Elizabeth Figura zfigura@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 -
Elizabeth Figura -
Jinoh Kang -
Tres Finocchiaro