"Zebediah Figura (she/her)" zfigura@codeweavers.com writes:
On 9/3/21 3:26 AM, Alexandre Julliard wrote:
"Zebediah Figura (she/her)" zfigura@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().
I don't see how this would work. All such libraries will import msvcrt or kernel32, but you can't have these end up in a separate namespace.
And how do you define a "system lib"? Do you somehow tell the PE loader the actual Unix path that the dll was loaded from? What if the distro installs the Wine DLLs in the same dir?
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?
Well, you'll need to copy, say, zlib1.dll into the prefix. How do you know this is the zlib1.dll from the system package, and not one installed by an app? Do you add the builtin flag, altering the binary when copying it?