On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro <tres.finocchiaro@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@winehq.org/message/5PBWZ4ACVLLL4B43WFHBJYMZ7WB5POGF/
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