Jesse Allen wrote:Hi Jesse,On Mon, 7 Mar 2005 18:28:36 -0700, Jesse Allen <the3dfxdude@xxxxxxxxx> wrote:Well, even if cedega works, it doesn't help us. I'm sure their copy protection support is completely different. When copy protection broke on x86 and wine, the cedega side was completely quiet on it.Well, I've learned something new. They were affected too: http://downloads.transgaming.com/files/cedega-4.3_releasenotes.html#cedega_4_3_release_notes "2.6.9, 2.6.10 Kernels and Copy Protection" This is the first mention by them I have found. I dunno what to draw on this, except, to say that x86-64 should work too. If wine's and cedega's signal handling is pretty much the same, and cedega + x86-64 works, then there may be something else wrong. Actually, we first learned about the issue in the November-December timeframe, and mentioned it in our 4.2 release notes in December. In general, we still recommend that people use 2.4 kernels, since the scheduling changes can cause performance issues. We started to have a look at the problem, but by then Linus was already involved and the issue seemed well in hand. Cedega's signal handling code is certainly close enough to Wine at the lowest levels to still be affected by the same kind of issues with ptrace. While we've tested the 2.6.11 ptrace fixes on x86, we had not done so on x86-64. We haven't recieved any reports from users that it's still broken, but if the equivalent x86-64 ptrace patch didn't get applied to 2.6.11, the it presumably could still be broken. Though I don't know how the 64-bit kernel deals with 32-bit code in this respect - is it possible that the x86 32 bit pthreads code is being used for 32-bit processes even on a 64-bit kernel? Take care, -Gav -- Gavriel State, Founder & CTO TransGaming Technologies Inc. gav@xxxxxxxxxxxxxxx http://www.transgaming.com Let the games begin! |