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,