https://bugs.winehq.org/show_bug.cgi?id=56912
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #20 from Zeb Figura z.figura12@gmail.com --- This is the disassembly around the faulting instruction:
0x43a515: mov 0xc(%ebx),%edi 0x43a518: mov %esi,%ecx 0x43a51a: sub %eax,%ecx 0x43a51c: xorps %xmm5,%xmm5 0x43a51f: xorps %xmm4,%xmm4 0x43a522: xorps %xmm6,%xmm6 0x43a525: xorps %xmm7,%xmm7 0x43a528: nopl 0x0(%eax,%eax,1) 0x43a530: movups (%edi,%edx,4),%xmm1 => 0x43a534: vcmpgtps %xmm0,%xmm1,%xmm2 0x43a539: movaps %xmm2,%xmm0 0x43a53c: andps -0x40(%ebp),%xmm2 0x43a540: andps %xmm1,%xmm0 0x43a543: paddd %xmm2,%xmm5
(Note "vcmpgtps ..." is an alternate mnemonic for "vcmpps $0x0e, ...")
It's not garbage.
It's also not the same code that's written in the non-updated version, or if it is, it's written to a different place and I can't find it.
If the copy-protection hasn't changed between versions, then my only guess is that it's querying the CRT, which is apparently statically linked, and the CRT is somehow giving an indication that AVX is available. This is difficult to explain if the CRT is explicitly configured not to do that, but maybe the copy-protection is badly implemented and assumes AVX based on the CRT version or something.
I'm pretty convinced that the copy protection is requiring AVX and will fail on any processor that doesn't support it. Ultimately I am guessing that the developer is only going to be convinced if the program is tested on bare metal, and I don't have the time or equipment for that. This is my best ability to describe the problem and offer hypotheses.
Until there's good evidence that Wine is at fault I'm resolving this INVALID.