On Fri Jan 19 21:42:38 2024 +0000, Alexandre Julliard wrote:
We don't want to expose the internal path, the app shouldn't be aware that the dll was replaced by a builtin.
Why exactly is that? It seems a bit weird that there is that discrepancy between unix and nt path. It also means that Wine itself can't rely on the nt path, which causes issues like the issue with MR 4518 I mentioned. Won't this also cause issues with anti cheat that validate the dll hasn't been tampered with, since the in memory dll is a different one from what the programsees on disk?