https://bugs.winehq.org/show_bug.cgi?id=52393
--- Comment #49 from labre@posteo.de --- (In reply to Piotr Caban from comment #48)
The mxcsr register is set on process startup so it's not something that can be preset with another application. In order to fix the bug it will be needed to find what and why sets it to incorrect value.
Scraping my basic OS knowledge together, I figured this too in the meantime. Due to this being an illegal OS operation, it would cause a segmentation fault and because of that require an exploit to work; thus this is not an option.
Probably the first step is to find why the game doesn't work in current wine (it works for me). You can try to find what patch is breaking it again after setting control word in scanf/make_double.
I’ll try bisecting with the _control86_2 patch after looking for openal related causes.
Another option is to run with attached patch and WINEDEBUG=relay. The patch prints if _DN_FLUSH is set. The trace look like this: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=0 After mxcsr is changed it will look like: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=1 Hopefully it will help find what is setting the _DN_FLUSH flag.
Could be openal. 0009:Call openal32.alcGetString(00000000,00001013) ret=027d614d mxcsr=0 0009:Ret openal32.alcGetString() retval=f5cd7a58 ret=027d614d mxcsr=1 … 0009:Call openal32.alcOpenDevice(0032e590 "JACK Default") ret=027d6824 mxcsr=1 0009:Ret openal32.alcOpenDevice() retval=f3305010 ret=027d6824 mxcsr=1 Could be related to it trying to open a Jack device. I have no pulseaudio support. Also I’m using pipewire, so the Jack server is actually the Pipewire Jack emulation, which could imply, that pipewire sets it. I’ll try recompiling openal with pulseaudio support, which might cause other code paths in pipewire.
versions (revisions indicate ebuild fixes or build patches): pipewire-0.3.44-r1 openal-1.21.1-r2