[RFC PATCH 0/5] XAudio PE conversion.

Alexandre Julliard julliard at winehq.org
Fri Sep 3 03:26:03 CDT 2021


"Zebediah Figura (she/her)" <zfigura at codeweavers.com> writes:

> Actually, an alternate solution occurred to me:
>
> If we are loading any library that is a dependency of a builtin
> library, always load it from a fixed path like /usr/lib/wine/ext/, and 
> essentially treat it as if we had loaded using an absolute path
> instead of a relative path, so as to skip existing DLLs loaded under
> that name.
>
> Mark that DLL with an internal flag, and don't consider it when
> searching for existing DLLs with that name, to avoid the other side.
>
> I know there are a lot of other things standing in the way of shared
> libraries, and that this would require some nontrivial loader work,
> but does it at least seem plausible? Are there snags I'm not noticing?

Sure, you can try to create a separate namespace for these without
actually changing their names. It's not clear to me how you are going to
determine which DLLs should go into that namespace, and how that's going
to work with apps that do import resolving by hand.

You'll also have to invent some mechanism to have Wine treat them as
builtins even though they don't have the builtin flag. And somehow you
need to differentiate them from the exact same DLLs being shipped by an
app...

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list