Re: Add option to winebuild to disable ASLR/dynamicbase

On Monday, 7 July 2025 17:45:55 CDT Jinoh Kang wrote:
> On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro <[email protected]>
> 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.

It's also rather worth investigating why this happens...

> >    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/[email protected]/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).

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:

https://bugs.winehq.org/show_bug.cgi?id=58377#c6