https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #17 from Zeb Figura z.figura12@gmail.com --- (In reply to stormtrackertony from comment #15)
That's what is yet to be determined. It's clear now that some AVX instructions have found their way into this software that aren't supposed to be there. But we're yet to see how Windows handles the situation when AVX is not supported. If, by chance, Windows is able to work around it and keep the software going, then WINE, AWS EC2, etc. need to be programmed to perform that same work-around.
That's not how it works I'm afraid. AVX is a processor-level feature. If Windows were to "handle" it, it would need to embed an AVX emulator (like Linux's x87 emulator of yore), but Windows does not do that. (And if Windows embedded an AVX emulator, it would work on the AWS virtualization environment.)
More plausible is that AWS is performing CPU emulation of a processor that doesn't support AVX on a processor that does, and that emulation is buggy somehow. I'm not sure I find this particularly likely either, though.
Unfortunately I don't have access to any bare-metal Windows that's old enough to not support AVX but also new enough to support Vista.
By all evidence, the developer has attempted to target SSE2, and it's true that none of the statically disassembled code in the executable uses AVX instructions, but somehow some other component is using AVX instructions anyway.
(In reply to stormtrackertony from comment #16)
May be getting somewhere now! You wouldn't happen to know which .text section (or something I could share with the developer to point him in the right direction)?
It's just ".text". The actual entry point and statically available disassembly is in a section ".text1".
I wouldn't necessarily expect the developer to know the binary details of what's going on under the hood there, but possibly more helpful is: the contents of the .text section seem to be written from another jitted memory area dynamically allocated at runtime, and the contents of *that* memory area are written somewhere around 0x733759 [at least, that's where the VirtualProtect() is.]