Hello wine-devel,
after stumbling across bug 47120, I wonder - Why are builtin dlls preferred in the first place? Isn't it windows behavior to be able to provide a thunk (or similar) for a dll and having it preferred over the system dll?
Regards, Fabian Maurer
In the case of gdiplus, the native dll has a critical bug that is not present in builtin (crashing when encountering certain fonts). I also remember there were regressions reported when we switched to preferring builtin. The default did matter for people who didn't intentionally install the native dll.
For d3d8, if anything installs native in a system location, that can't work and we have to prefer builtin. (I can't verify right now, but I'd guess that directx installers, which are run often especially on steam, do that.)
In general, builtin is the better tested (with the rest of wine) and more easily debugged path.
That said, we do prefer native for many libraries, particularly when adding a new stub dll.
For d3d8, if anything installs native in a system location, that can't work and we have to prefer builtin. (I can't verify right now, but I'd guess that directx installers, which are run often especially on steam, do that.)
I see, but what about programs that ship their down d3d8 layer? Maybe it would be possible to only prefer native dlls not inside system32/syswow64, aka only those in the application directory?
Regards, Fabian Maurer
Sometimes applications ship MS dll's in their own directory, so I don't think it would cover all cases.
Does the version resource say "Microsoft"? Maybe we could use that to tell the difference.
-
Fabian Maurer -
Vincent Povirk (they/them)