http://bugs.winehq.org/show_bug.cgi?id=12653
--- Comment #10 from Robert Wm Ruedisueli esd45@earthlink.net 2008-10-10 06:54:10 --- (In reply to comment #9)
Before suggesting the solutions please provide the test cases (preferably integrated into Wine test suite) confirming the above claims.
OK, I made a presumption that you were reading the console outputs and checking my statements there.
Here is where I see it from http://bugs.winehq.org/attachment.cgi?id=15756: --Snip-- Unhandled exception: page fault on write access to 0x0043f69c in 32-bit code (0x00143440). --Snip-- =>1 0x00143440 (0x00017e2c) 0x00143440: andb %dh,0x0(%esp,%edx,1) --Snip-- This command will and the %dh with the item and the 32bit Stack Pointer added to the 32bit data pointer, which results in the address of 0x0043f69c, it will then place it there at that same memory address (0x0043f69c).
It just happens, that this runs a cross-page exploit from a data-command write to the stack pointer, directly into the executable segment of The Sims binary, done by a kernel call from The Sims binary. It was most likely intended to do this.
The only part of my analysis that is presumption is that this is intentionally done by the copy protection system to change an specific instruction or constant in the Sims binary, which is a reasonable assumption as many copy protection systems are known to do this.
Also, could you point me to where to get this wine test suite you speak of, it would be helpful, as I could help trace where the exact code segment is that needs to be changed, as not to create this crash when run in this manner.