T.J. Zeeman wrote:
Warcraft still complains about the CD-rom being MIA though :( I'll see if I can dig up a few hints from the log this weekend.
Make sure your kernel hsa the ptrace regression fixes in.
I guess you meant the problems refered to in WWN250 (http://www.winehq.com/?issue=250). I checked and the patch there is only for i386. I ported those to the x86_64 files (see attachments) and tried again to no avail.
I also tried the test app as posted by Linus Torvalds here: http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html When trying that on amd64 with the ptrace patches it does not even want to compile (not completely surprising). In the chroot it segfaults. A strace showed the following:
x5556c000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0 old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x55576000 old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0x5569f000 old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x556a7000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556aa000 set_thread_area({entry_number:-1 -> 11, base_addr:0x556aa2a0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0x5556d000, 32850) = 0 rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0 mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
I haven't been this deep into low level code in a long time (and that was 8086 asm simulated on a sparc), but I thought this would work and not segfault. Anybody around here that can comment on that? Or should I take this to another forum to further investigate? If so, where would you suggest I take it?
I'm not sure, probably lkml would be best but I'm not subscribed to that. I'll CC wine-devel and maybe somebody there can help.
I'd recommend pinging Linus and asking about whether the ptrace regressions still affect x86-64.
thanks -mike
regards, Thomas
--- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/ptrace.c 2004-12-24 22:34:30.000000000 +0100 +++ ptrace.c 2005-03-01 20:32:29.713639136 +0100 @@ -79,6 +79,28 @@ return 0; }
+static void set_singlestep(struct task_struct *child) +{
- long eflags;
- set_tsk_thread_flag(child, TIF_SINGLESTEP);
- eflags = get_stack_long(child, EFL_OFFSET);
- put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG);
- child->ptrace |= PT_DTRACE;
+}
+static void clear_singlestep(struct task_struct *child) +{
- if (child->ptrace & PT_DTRACE) {
long eflags;clear_tsk_thread_flag(child, TIF_SINGLESTEP);eflags = get_stack_long(child, EFL_OFFSET);put_stack_long(child, EFL_OFFSET, eflags & ~TRAP_FLAG);child->ptrace &= ~PT_DTRACE;- }
+}
/*
- Called by kernel/ptrace.c when detaching..
@@ -86,11 +108,12 @@ */ void ptrace_disable(struct task_struct *child) {
- long tmp;
+/* long tmp;
clear_tsk_thread_flag(child, TIF_SINGLESTEP); tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;
- put_stack_long(child, EFL_OFFSET, tmp);
- put_stack_long(child, EFL_OFFSET, tmp); */
- clear_singlestep(child);
}
static int putreg(struct task_struct *child, @@ -338,8 +361,6 @@ break; case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */ case PTRACE_CONT: { /* restart after signal. */
long tmp;- ret = -EIO; if ((unsigned long) data > _NSIG) break;
@@ -347,12 +368,9 @@ set_tsk_thread_flag(child,TIF_SYSCALL_TRACE); else clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
clear_tsk_thread_flag(child, TIF_SINGLESTEP);tmp = get_stack_long(child, EFL_OFFSET);tmp &= ~TRAP_FLAG;put_stack_long(child, EFL_OFFSET,tmp);
clear_singlestep(child);@@ -394,34 +412,23 @@
- exit.
*/ case PTRACE_KILL: {
long tmp;- ret = 0; if (child->exit_state == EXIT_ZOMBIE) /* already dead */ break; clear_tsk_thread_flag(child, TIF_SINGLESTEP); child->exit_code = SIGKILL; /* make sure the single step bit is not set. */
tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;put_stack_long(child, EFL_OFFSET, tmp);
clear_singlestep(child);wake_up_process(child); break; }
case PTRACE_SINGLESTEP: { /* set the trap flag. */
long tmp;- ret = -EIO; if ((unsigned long) data > _NSIG) break; clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
if ((child->ptrace & PT_DTRACE) == 0) {/* Spurious delayed TF traps may occur */child->ptrace |= PT_DTRACE;}tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG;put_stack_long(child, EFL_OFFSET, tmp);set_tsk_thread_flag(child, TIF_SINGLESTEP);
set_singlestep(child);
--- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/signal.c 2004-12-24 22:35:23.000000000 +0100 +++ signal.c 2005-03-01 20:33:11.425298000 +0100 @@ -205,8 +205,14 @@ err |= __put_user(me->thread.trap_no, &sc->trapno); err |= __put_user(me->thread.error_code, &sc->err); err |= __put_user(regs->rip, &sc->rip);
- /*
* Iff TF was set because the program is being single-stepped by a* debugger, don't save that information on the signal stack.. We* don't want debugging to change state.*/
- if (current->ptrace & PT_PTRACED) {
- if (current->ptrace & PT_DTRACE) { eflags &= ~TF_MASK; } err |= __put_user(eflags, &sc->eflags);
@@ -324,12 +330,16 @@ regs->rsp = (unsigned long)frame;
set_fs(USER_DS);
- /*
* Clear TF when entering the signal handler, but* notify any tracer that was single-stepping it.* The tracer may want to single-step inside the* handler too.*/
if ((current->ptrace & (PT_PTRACED | PT_DTRACE)) == (PT_PTRACED | PT_DTRACE)) {
regs->eflags &= ~TF_MASK;if (current->ptrace & PT_DTRACE) ptrace_notify(SIGTRAP);
} else {regs->eflags &= ~TF_MASK;}#ifdef DEBUG_SIG
On Wed, 02 Mar 2005 12:52:38 +0000, Mike Hearn mike@navi.cx wrote:
I guess you meant the problems refered to in WWN250 (http://www.winehq.com/?issue=250). I checked and the patch there is only for i386. I ported those to the x86_64 files (see attachments) and tried again to no avail.
Anyway, the problem I had was that the cpu trap flag was being set during kernel operations when it wasn't supposed to. The way I finally discovered the exact spot was to make trap setting and clearing verbose in logs under a working kernel and the broken kernel and compare the logs. You need to make sure that 2.6.8 works and 2.6.9-rc1 or 2 breaks it, for this to be the same case. I know the initial two patches did touch amd64, and the later fixes have not been migrated to amd64.
I also tried the test app as posted by Linus Torvalds here: http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html When trying that on amd64 with the ptrace patches it does not even want to compile (not completely surprising). In the chroot it segfaults. A strace showed the following:
x5556c000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0 old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x55576000 old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0x5569f000 old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x556a7000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556aa000 set_thread_area({entry_number:-1 -> 11, base_addr:0x556aa2a0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0x5556d000, 32850) = 0 rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0 mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
This is from the test program?
Jesse
On Wed, 2 Mar 2005 09:59:29 -0700, Jesse Allen the3dfxdude@gmail.com wrote:
You need to make sure that 2.6.8 works and 2.6.9-rc1 or 2 breaks it, for this to be the same case. I know the initial two patches did touch amd64, and the later fixes have not been migrated to amd64.
Here Andi Kleen expresses a dislike for an amd64 version of a patch that broke 2.6.9-rc1 on my x86 system: http://marc.theaimsgroup.com/?l=linux-kernel&m=110379910702995&w=2
The patch link: http://linux.bkbits.net:8080/linux-2.6/cset@412a49d0Duv_YlSqDMoYxkNhiBwoWw?n...
Also here Andi speaks about the complexity of Linus' fixes and the problem of porting it to x86-64. http://marc.theaimsgroup.com/?l=linux-kernel&m=110444869225886&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=110445367319392&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=110449669800844&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=110451344128991&w=2
Entire thread: http://marc.theaimsgroup.com/?t=110055970800001&r=1&w=2
My guess x86-64 hasn't been looked at since this last time. You need to make sure this is the same problem.
Jesse
Hi,
and compare the logs. You need to make sure that 2.6.8 works and 2.6.9-rc1 or 2 breaks it, for this to be the same case. I know the
OK, if 2.6.8 is supposed to work, then this is likely another problem. I can't get Warcraft 3 to work with 2.6.8 either. Both .8 and .10 give the same dialog asking for the cdrom to be inserted.
[snip strace output]
This is from the test program?
Yes.
regards, Thomas
On Thu, 3 Mar 2005 09:22:59 +0100, Thomas Zeeman tjzeeman@gmail.com wrote:
OK, if 2.6.8 is supposed to work, then this is likely another problem. I can't get Warcraft 3 to work with 2.6.8 either. Both .8 and .10 give the same dialog asking for the cdrom to be inserted.
Ok. This does not mean ptrace is not at all at fault, it's likely that it's not the same issue. One thing to find out is whether windows users typically run the game in 32-bit compatibility mode. I'd also ask on the kernel list if they know the reason why the seg fault in the test program. Maybe Andi or Linus will respond.
Jesse
On Thu, 3 Mar 2005 09:22:59 +0100, Thomas Zeeman tjzeeman@gmail.com wrote:
OK, if 2.6.8 is supposed to work, then this is likely another problem. I can't get Warcraft 3 to work with 2.6.8 either. Both .8 and .10 give the same dialog asking for the cdrom to be inserted.
Oh do you know any kernel version that does work?
On Thu, 3 Mar 2005 08:13:13 -0700, Jesse Allen the3dfxdude@gmail.com wrote:
On Thu, 3 Mar 2005 09:22:59 +0100, Thomas Zeeman tjzeeman@gmail.com wrote:
OK, if 2.6.8 is supposed to work, then this is likely another problem. I can't get Warcraft 3 to work with 2.6.8 either. Both .8 and .10 give the same dialog asking for the cdrom to be inserted.
Oh do you know any kernel version that does work?
I don't know of any kernel-version that does work, but I have asked on the debian-amd64 list and someone over there claimed succes with warcraft 3 on amd64 but he was using cedega. Since 2.4 isn't even shipped anymore by most amd64 distributions it must be with a 2.6 version. I'll try to get a definitive answer for that.
Thanks for the replies so far.
regards, Thomas
On Thu, 2005-03-03 at 17:05 +0100, Thomas Zeeman wrote:
On Thu, 3 Mar 2005 08:13:13 -0700, Jesse Allen the3dfxdude@gmail.com wrote:
Oh do you know any kernel version that does work?
I don't know of any kernel-version that does work, but I have asked on the debian-amd64 list and someone over there claimed succes with warcraft 3 on amd64 but he was using cedega. Since 2.4 isn't even
I got a reply on that one and he is using 2.6.10 (debian kernel-image-2.6.10-9-amd64-k8).
Since 2.6.11 was out I tried that one too, but without success. AFAICT the ptrace patch has not been applied in any form for x86_64 yet.
As an aside I tried several other games I have and SimCity 3000 exhibits the same behaviour. I could have sworn that I played that game about half a year ago on the same machine. Unfortunately I no longer have the installation under which I played it then. It was an earlier version of debian's pure64 and a sid chroot from around that time is the best answer my memory can serve.
The last thing I noted was a slight difference in behaviour on mounting the cdrom. With 2.6.8 I have to become root in the chroot to do an umount -f /cdrom to get it unmounted in the chroot. With 2.6.10 and .11 I could do it as an ordinary user in the chroot.
Is there anything I could try to figure out through wine's debugoutput? If so, what channels are recommended to be shown?
regards, Thomas
PS Are the Debian maintainer and wine on speaking terms again? An apt-get update showed that 20050211 has entered sid and it wanted to replace my current install from winehq.
Le lun 07/03/2005 à 15:34, T.J. Zeeman a écrit : [snip]
PS Are the Debian maintainer and wine on speaking terms again? An apt-get update showed that 20050211 has entered sid and it wanted to replace my current install from winehq.
Ove Kaaven (Debian's Wine maintainer) released a 20050111 package (in unstable) on the 1st of March and a 20050211 package on the 5th of March. Read the changelog (http://packages.debian.org/changelogs/pool/main/w/wine/wine_0.0.20050211-1/c...) for details.
Vincent
On Mon, 07 Mar 2005 21:34:49 +0100, T.J. Zeeman tjzeeman@gmail.com wrote:
On Thu, 2005-03-03 at 17:05 +0100, Thomas Zeeman wrote:
On Thu, 3 Mar 2005 08:13:13 -0700, Jesse Allen the3dfxdude@gmail.com wrote:
Oh do you know any kernel version that does work?
I don't know of any kernel-version that does work, but I have asked on the debian-amd64 list and someone over there claimed succes with warcraft 3 on amd64 but he was using cedega. Since 2.4 isn't even
I got a reply on that one and he is using 2.6.10 (debian kernel-image-2.6.10-9-amd64-k8).
Since 2.6.11 was out I tried that one too, but without success. AFAICT the ptrace patch has not been applied in any form for x86_64 yet.
As an aside I tried several other games I have and SimCity 3000 exhibits the same behaviour. I could have sworn that I played that game about half a year ago on the same machine. Unfortunately I no longer have the installation under which I played it then. It was an earlier version of debian's pure64 and a sid chroot from around that time is the best answer my memory can serve.
The last thing I noted was a slight difference in behaviour on mounting the cdrom. With 2.6.8 I have to become root in the chroot to do an umount -f /cdrom to get it unmounted in the chroot. With 2.6.10 and .11 I could do it as an ordinary user in the chroot.
Is there anything I could try to figure out through wine's debugoutput? If so, what channels are recommended to be shown?
regards, Thomas
PS Are the Debian maintainer and wine on speaking terms again? An apt-get update showed that 20050211 has entered sid and it wanted to replace my current install from winehq.
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. They did have copy protection issues with Red Hat kernels, but they did not relate at all to the problem I discovered.
Are you using Debian packages for wine? You should try wine CVS. If your memory is correct too, you should build an early 2.6 kernel, like 2.6.4.
For tracking down the problem, I used the relay channel. You could also use the seh channel too. But I also inserted my own debug messages into wine or the linux kernel to show the cpu flags cause I couldn't even trap the exact failed condition. And these hacked versions are already long gone... so I don't remember.
Jesse
On Mon, 7 Mar 2005 18:28:36 -0700, Jesse Allen the3dfxdude@gmail.com 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... "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.
Jesse
Jesse Allen wrote:
On Mon, 7 Mar 2005 18:28:36 -0700, Jesse Allen the3dfxdude@gmail.com 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... "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.
Hi Jesse,
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
On Sun, 13 Mar 2005 03:55:37 -0500, Gavriel State gav@transgaming.com wrote:
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@transgaming.com http://www.transgaming.com Let the games begin!
Ok, I understand now. I'm really looking for a better info under what conditions it fails. If wine and cedega are similar enough here, then they actually should be both exhibiting trouble on x86-64. Also, Andi Kleen has made up x86-64 patches, but hasn't merged them because they are untested. I offered to have them tested. So perhaps I'll get access to an amd system or maybe Thomas Zeeman find out more. I really haven't seen an amd system in action here.
Jesse
Hi Jesse,
On Sun, 13 Mar 2005 21:46:19 -0700, Jesse Allen the3dfxdude@gmail.com wrote:
they actually should be both exhibiting trouble on x86-64. Also, Andi Kleen has made up x86-64 patches, but hasn't merged them because they are untested. I offered to have them tested. So perhaps I'll get access to an amd system or maybe Thomas Zeeman find out more. I really haven't seen an amd system in action here.
So far it seems my memory wasn't all that good, because 2.6.4, 2.6.6 and 2.6.7 did not work. I'm working on some logs with relay and seh, but relay seems to be failing on me with the latest wine release (using wine's deb for 2005-03-10).
If you know where I can find the patches by Andy, I would be happy to get them tested as well. I'm planning on doing some more testing next weekend (including digging up my old, trusty p2; but only for SimCity, W3 is too heavy) to figure out if it is a problem with wine, kernel, the compatibility-layer for running 32-bit on x86_64 or even somewhere in my config.
regards, Thomas
On Mon, 2005-03-14 at 11:47 +0100, Thomas Zeeman wrote:
So far it seems my memory wasn't all that good, because 2.6.4, 2.6.6 and 2.6.7 did not work. I'm working on some logs with relay and seh, but relay seems to be failing on me with the latest wine release (using wine's deb for 2005-03-10).
This is what I got when running with relay channel on:
tjzeeman@carrington:~/.wine/drive_c/Program Files/SimCity 3000/Game$ WINEDEBUG=relay wine SC3.EXE 0009:Call kernel32.__wine_kernel_init() ret=55719da4 Segmentation fault
tjzeeman@carrington:~/.wine/drive_c/Program Files/SimCity 3000/Game$ WINEDEBUG=all+relay wine SC3.EXE fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x558ee530)->(00010022,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x558ee530)->(00010022,00000011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x558ee530)->(00000000,00000008)
AFAICT I should get some results from the first attempt. The docs suggest that both should work and when I replace relay with seh it does. That, however, has not provided me with any insights yet.
regards, Thomas
-
Gavriel State -
Jesse Allen -
Mike Hearn -
T.J. Zeeman -
Thomas Zeeman
-
Vincent Béron