[RFC PATCH 0/5] XAudio PE conversion.

[Zebediah Figura (she/her)]

On 9/3/21 3:26 AM, Alexandre Julliard wrote:
> "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. 

The distinguishing factor I was thinking of is that if it's a system lib 
or linked to by a system lib, it's marked as a system lib. That doesn't 
work for libraries loaded dynamically, and there we have the extra 
caveat that we don't want to mark every dynamically loaded library as a 
system lib, so I think we'd need an internal flag to LoadLibraryExW().

Presumably Wine and system libs shouldn't do import resolving by hand.

> And somehow you
> need to differentiate them from the exact same DLLs being shipped by an
> app...

Sorry, I'm not sure what you mean by this, that's different from what I 
described above?