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.