Am 20.11.2016 um 19:49 schrieb Fabian Maurer dark.shadow4@web.de:
I just did a few tests on windows on a VM, and it seems indeed to be UB. The code behaves exactly the same on wine and windows, just the UB is different. I mean, I could make a patch - it's just a single bit that needs to be flipped (movsx -> movzx) - but that's not a solution for wine.
There are applications that try to read private heap data structures by using magic offsets. I’m not entirely sure why, my guess is that they’re trying to fiddle with these things for Anti-Cheat or Copyprotection purposes.
Wine tries to accommodate those programs to as good as it can, but it’s not perfect. To make matters more complicated, those private structures differ from Windows version to Windows version and so different programs have different expectations.
You could try to find out what is supposed to be stored at the offset used by the program and see if you can modify Wine to behave similarly to Windows. It’s tricky to do that without violating Microsoft’s copyright though (I only found https://www.winehq.org/pipermail/wine-devel/2007-August/058455.html https://www.winehq.org/pipermail/wine-devel/2007-August/058455.html and the follow-up mails in a quick google search).
It is also possible that the program is really just broken and incredibly lucky on Windows. Even then you could in theory find out why it’s unlucky on Wine (e.g. how the allocated addresses look after its HeapAlloc calls) and try to improve the odds, but there is no guarantee that you can make it reliable.