[PATCH] d3dcompiler/tests: Fix some d3dcompiler_47 test failures on Windows 8.
Signed-off-by: Sven Baars <sven.wine(a)gmail.com> --- dlls/d3dcompiler_43/tests/reflection.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/dlls/d3dcompiler_43/tests/reflection.c b/dlls/d3dcompiler_43/tests/reflection.c index fb117fd6a9..2dcee6d945 100644 --- a/dlls/d3dcompiler_43/tests/reflection.c +++ b/dlls/d3dcompiler_43/tests/reflection.c @@ -106,10 +106,12 @@ static void test_reflection_references(void) expected = E_NOINTERFACE; #endif hr = pD3DReflect(test_reflection_blob, test_reflection_blob[6], &IID_ID3D10ShaderReflection, (void **)&ref10); - ok(hr == expected, "D3DReflect failed, got %x, expected %x\n", hr, expected); + ok(hr == expected || broken(hr == E_NOINTERFACE) /* Windows 8 */, + "D3DReflect failed, got %x, expected %x\n", hr, expected); hr = pD3DReflect(test_reflection_blob, test_reflection_blob[6], &IID_ID3D10ShaderReflection1, (void **)&ref10_1); - ok(hr == expected, "D3DReflect failed, got %x, expected %x\n", hr, expected); + ok(hr == expected || broken(hr == E_NOINTERFACE) /* Windows 8 */, + "D3DReflect failed, got %x, expected %x\n", hr, expected); hr = pD3DReflect(NULL, test_reflection_blob[6], &IID_ID3D10ShaderReflection1, (void **)&ref10_1); ok(hr == D3DERR_INVALIDCALL, "D3DReflect failed, got %x, expected %x\n", hr, D3DERR_INVALIDCALL); -- 2.17.1
Signed-off-by: Matteo Bruni <mbruni(a)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?)
On 14-11-19 21:04, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni <mbruni(a)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? Best, Sven
On Thu, Nov 14, 2019 at 9:17 PM Sven Baars <sven.wine(a)gmail.com> wrote:
On 14-11-19 21:04, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni <mbruni(a)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!
participants (3)
-
Matteo Bruni -
Matteo Bruni -
Sven Baars