Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

On 4/13/20 1:15 PM, Rémi Bernon wrote:
> On 4/13/20 5:02 PM, Zebediah Figura wrote:
>>>
>>> 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.
>>
> 
> Sure, statically linking can also solve most issues here, assuming these 
> dependencies do not require being dynamically linked.
> 
> 
> But in the dynamic linking scenario, IIUC Wine currently offers only one 
> choice: loading the builtin vs native version of a given DLL.
> 
> For instance, to illustrate, I understand that to properly manage SDL2 
> without conflict with an application shipping its own incompatible 
> version of it, we would have to load these:
> 
>    application.exe
>      -> SDL2.dll (native)
>      -> xaudio2_7.dll (builtin)
>          -> FAudio.dll (builtin)
>              -> SDL2.dll (builtin)
> 
> So we would have to decide whether to load SDL2 as builtin or native 
> depending in which context it is loaded.
> 
> Then maybe I'm wrong but I understand that, currently, wine only handles 
> the builtin vs native by always loading the requested version of the 
> DLL, wherever it's loaded from, so would this contextual loading also 
> apply to all libraries, or just the dependencies somehow?
> 
> Would it be something like a third possible option to native/builtin 
> choice, like "load builtin if from a builtin / native if from native" 
> setting? It seems a little bit convoluted to me to be honest when we can 
> just rely on the existing mechanism and custom wine libraries.

What I'm imagining is that the default—when no explicit overrides are 
set in the registry or on the command line—is "builtin if from builtin, 
native if from native"; otherwise we just respect the override. This 
seems like a potentially reasonable approach to me in general, even for 
PE builtins (like d3dx*). But I'm not as married to it as I am to the 
question of how we build and distribute the libraries.

> A more troublesome issue I can think of with this approach: when 
> investigating Denuvo protection, I could see that the DRM did some 
> consistency checks for some selected libraries. And it did these checks 
> by name, not caring about where the libraries were loaded from, but 
> checking their contents against disk.
> 
> Now, pure guess here, but I can imagine that having two different DLLs 
> loaded with the same name, and with a name that's possibly one of the 
> selected libraries to check could cause some confusion and undesired 
> trouble. Having internal wine dependencies live under a fake name could 
> prevent future pain IMHO, especially when passing DRM checks is the main 
> purpose for all this.
> 

If that is a problem, I think it's something we could get around with 
sxs, or indeed renaming the library. Though the latter may cause some 
pain regarding building. But given that sxs exists, I don't know that we 
necessarily need to assume it's a problem.