Request for discussion: Using PE libraries for Wine dependencies

[Rémi Bernon]

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.


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.

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