On Thu, Nov 14, 2019 at 9:17 PM Sven Baars sven.wine@gmail.com wrote:
On 14-11-19 21:04, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni mbruni@codeweavers.com
FWIW this test failure is suspicious, it implies that Windows 8's d3dcompiler_47 behaves differently from Windows 10's d3dcompiler_47 (since the hr shouldn't depend on anything external to the DLL itself... or maybe it does?)
Hey Matteo,
The version of d3dcompiler_47 on Windows 8 is reported as 6.3.9600.16384, the version on Windows 10 as 10.0.xxxxx.xxxxx. For d3dcompiler_43, both have version 9.29.952.3111.
These changed error codes also seem to be fairly common on Windows 10, even between different versions of Windows 10 (where dlls have the same major version). Many of the test failures on Windows 10 exist(ed) because of this. Is there a reason why this shouldn't be the case for d3dcompiler_47?
Basically, because originally the point for having those multiple suffixed versions of d3dcompiler was to make sure applications could depend on specific behavior that would not change by updating the OS or such. Which is a terrible idea (it turns out applications end up depending on what would otherwise be implementation details, see e.g. https://bugs.winehq.org/show_bug.cgi?id=31701) but, regardless, it sounds like they effectively reverted that decision with _47.
BTW, thanks!