Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

On 4/13/20 3:01 AM, Rémi Bernon wrote:
> 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.

Sure, I can see why it's reasonable to always use builtin DLLs for 
dependencies of Wine builtins, and I'm not suggesting anything different...

> 
> 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.

...but I don't see how that implies that we can't use this approach for 
building and distributing them. Frankly, I can't see how it applies any 
approach. It does mean we have to do a bit of work to tweak the loader 
if we don't just statically link everything, but I don't think it'd end 
up being very much work.

> 
> 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.

I'm not sure I understand: we wouldn't be managing dependencies for 
Windows software any more than we already are; we'd only be managing 
dependencies for Wine itself.l

> 
> Cheers,