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).