On Thu, Dec 1, 2016 at 4:44 PM, Andrew Eikum aeikum@codeweavers.com wrote:
I don't know what else to do, you can read some more at https://bugs.winehq.org/show_bug.cgi?id=3930#c18
Huh, interesting. Either Windows has magic for this game, or it uses some other heuristic to determine whether to use the old behavior.
It would not be the first time Windows circumvents games problems. My patch is only touching Wine as configured for 9x, it brings no issues to the general user and makes Wine behave as 9x did. I cannot solve the mistery of how XP detects the game and avoids SuspendThread as my knowledge is limited and I believe it would require reverse engineering.
To be clear, I'm not rejecting your idea. Whatever this heuristic is, it would just replace the Windows version check in your patch so users wouldn't have to switch the Windows version in winecfg. We still need the separate thread implementation.
Thanks, re-reading what I wrote may have sounded like I'm angry or something like that but it is just my simple English vocabulary. In a different point of view I could say that since the next stable is getting closer this solution would really affect the minimum amount of people possible, and that I don't have the skills to debug anything as my assembly knowledge is limited to mov, add, xor, cmp, jmp, jnz ;-)
If we can bypass SuspendThread there wouldn't be a need for the thread, a hack that works for this bug is to comment out Suspend/ResumeThread in Wine code. But I guess it is harder than creating the thread since there is no simple way to do that in Windows API AFAICS.
If I were to tackle this, I would reproduce the exact sequence of steps that the program takes, with identical parameters and structs, and see what happens when run on Windows. Then try to figure out which step or piece of data triggers the behavior switch.
I'll see what I can do by following the relay logs.
Best wishes, Bruno