On Thu Sep 19 15:44:02 2024 +0000, Alexandre Julliard wrote:
What I don't understand is why do we need prefer builtin for most of
the dlls and deny loading the app's dll (whatever there is, just an app's dll with coinciding name or some deployed CRT runtime part)? Maybe the general solution is to switch native preference as default and only force builin when needed? Because if there's a problem with builtin we can fix it, but if there's a problem with native usually there's nothing we can do. Obviously the app shipping an incompatible native dll is a different case, and would maybe need a different mechanism than prefer-native, which is meant for stub dlls.
Feels like a tension between two kinds of "native"s:
1. Microsoft-signed Windows-native DLLs 2. Third party reimplementation of (1)
Once we are able to distinguish them (check digital signature), (1) should be replaced by builtin as julliard notes, but (2) should probably take priority over anything else.
I might have missed something, though.