On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro <tres.finocchiaro(a)gmail.com> wrote:
1. 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.
1. 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?
1. 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/mes...
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). -- Jinoh