Request for discussion: Using PE libraries for Wine dependencies

[Rémi Bernon]

On 4/13/20 4:13 AM, Zebediah Figura wrote:
> On 4/12/20 8:56 PM, Esme (they/them) wrote:
>>> I guess it's not obvious to me there's a difference between "builtin"
>>> and "distro" (though we'd presumably not go putting the Wine builtin
>>> flag in mingw libraries). But yeah, I guess we'd want to vary load order
>>> depending on whether the library is a dependency of a PE builtin or not,
>>> in some way.
>>
>> I was thinking about the possibility of a distro shipping a dll that's
>> also a Wine builtin. But, we could probably resolve that case by
>> saying "builtin" searches for wine builtins before distro libraries.
>>
>> I guess we'd want the load order to be something like:
>>   * If explicitly set in registry or environment, use that.
>>   * If Wine builtin, use preattach.
>>   * If dependency of Wine builtin that exists in distro search path,
>> builtin,native.
>>   * If dependency of a dll in distro search path (but not a Wine
>> builtin), builtin,native.
>>   * Otherwise, native,builtin or maybe even native only (should Wine
>> ever use a distro library to resolve dependencies of the
>> application?).
>>
> 
> This last one is a good question. Would we necessarily expect an 
> application-provided PE library to differ from a distro mingw library? 
> (Maybe because of a lack of backwards compatibility?) To a degree it 
> feels much like preferring builtin d3dx9 when the application provides 
> its own.
> 
> It also kind of ties into bugs like 14980, 20777, 25373, 43472, 45551, 
> 47053, 47120, 48275 where preferring builtin DLLs break applications. I 
> recall that always preferring native breaks other applications, though I 
> don't know any concrete examples... but since I have yet to hear a 
> solution to this problem, I have to wonder if it would be better in 
> general to use native,builtin for all direct dependencies of native DLLs.
> 
> (Presumably we'd want native,builtin rather than native only in any 
> case. The number of cases where applications import DLLs but don't ship 
> them is pretty small, in my experience? Though that doesn't include 
> dynamically loading...)
> 

I think it's a bit risky to assume that application provided DLL aren't 
going to collide with Wine dependencies expectations. As long as it's 
Windows DLL breakage, we can imagine that it's Wine's job to make it 
work, but third party DLLs is another story.

I think the idea of having Wine's internal dependencies isolated and not 
used for external dependencies resolution is a good thing. It's like the 
host dependencies -although they are provided by distributions- they 
stay invisible from the PE world.

So I think that although it could be seen as the architecturally 
"correct" approach, relying on distributions -or redistributed packages- 
to provide pristine PE versions of the dependencies is not going to work 
out.

Linux distributions already have quite a hard time factoring the 
dependencies and keeping all the Linux software working together nicely, 
and I think that doing the same for Windows software that was never 
written with such a setup in the first place -every application ships 
its with own dependencies isolated from the others- may be more painful 
than expected.

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>