but some apps then extract the (now obviously) negative value associated with those final 16 bits when parsing the individual UMD quad values. Hence we start seeing errors such as this:
which in this example was actually looking for at least UMD = 31.00.24027.1012.
The assignment should instead be something like:
pUMDVersion->QuadPart = ~0ull ^ (1ull << 63);
or:
pUMDVersion->QuadPart = ~(1ull << 63);
or:
pUMDVersion->QuadPart = 0x7FFFFFFFFFFFFFFF;
This would obviously lead to smaller values in the major element of the UMD quad, but.... will any of us ever see a driver version that large??
https://github.com/doitsujin/dxvk/blob/4333ee872dfbc26110a34267fdb22af23bc640dc/src/dxgi/dxgi_adapter.cpp#L132-L133
Above code sets a max-allowable 64bit unsigned int. Not only is this technically not to spec (signed int):
https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgiadapter-checkinterfacesupport
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-large_integer-r1
but some apps then extract the (now obviously) negative value associated with those final 16 bits when parsing the individual UMD quad values. Hence we start seeing errors such as this:
which in this example was actually looking for at least UMD = 31.00.24027.1012.
The assignment should instead be something like:
pUMDVersion->QuadPart = ~0ull ^ (1ull << 63);or:
pUMDVersion->QuadPart = ~(1ull << 63);or:
pUMDVersion->QuadPart = 0x7FFFFFFFFFFFFFFF;This would obviously lead to smaller values in the major element of the UMD quad, but.... will any of us ever see a driver version that large??