September 2001 - Wine-Devel

Re: InstallShield 6 again (debuggers requested)

by Ove Kaaven

Almost there, here's the current state of the patch, now with more hacks than ever before (but you also need the MoveFileEx and DispGetParam patches I've submitted to wine-patches). The current showstopper is a bug in Wine's SLTG typelib loader (it crashes reading the iuser.dll typelib resource). I think that once that typelib bug is fixed, it should only have minor issues left, or even work outright... I've already mailed Huw about the problem, but if anyone else wants to fix it, *I* don't mind...

Sept. 30, 2001

DdeConnect errors while running setup.exe

by Ian D . Stewart

Dear Wine Developers, Due to resource constraints (75 MHz processor, 1.2 GB hard drive, 16 MB RAM), we recently replaced Windows98 on our daughter's PC with Linux Mandrake, using the IceWM window manager. It isn't quite as flashy as Windows, but it boots beyond the startup screen, which is more than can be said for Win98. Well, to make a long story short, I've installed and configured Wine following the instructions in the Wine User's Guide. Everything seems to be working properly, but when I attempted to run the setup.exe for 'Jim Henson Muppets Letters: Capital & Small', I received the following errors: err:ddeml:DdeConnect .. but no Server window available err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle fixme:ddeml:DdeUninitialize16 stub calling DdeUninitialize Following the recomendations in the Wine User's Guide, section 3.2 (Installing Wine Without Windows), I re-ran wine with --debug msg +module,+file. I didn't see anything in the trace that jumped out at me, but I've attached it here, just in case it means something to someone else. One last thing. The setup.exe appears to be a 16-bit app, originally designed for Windows 3.1. Not sure if that makes any difference or not. Any help in resolving this would be greatly appreciated. Regards, Ian D. Stewart -- "God may have mercy. We will not." --Senator John S. McCain (R-AZ)

Sept. 30, 2001

Re: InstallShield 6 again (debuggers requested)

by Ove Kaaven

OK, we finally figured out the problem... here are updated proxy.c files that, when you also apply the MoveFileEx patch, manages to run through the "Preparing InstallShield Wizard" progress bar before it stops on unimplemented rpcrt4 stuff. I'm working on it...

Sept. 30, 2001

Re: InstallShield 6 again (debuggers requested)

by Gerard Patel

At 03:11 AM 29/09/2001 -0700, you wrote: >> Probably only that there's a problem with your setup. For example, perhaps >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > No , I did that.. Well, did you import all the registry entries in winedefault.reg then ? Gerard

Sept. 30, 2001

Re: InstallShield 6 again (debuggers requested)

by Andreas Mohr

On Sat, Sep 29, 2001 at 04:26:12AM -0700, Daniel Walker wrote: > Gerard Patel wrote: > > > > At 03:11 AM 29/09/2001 -0700, you wrote: > > >> Probably only that there's a problem with your setup. For example, perhaps > > >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > > > > > > > No , I did that.. > > > > Well, did you import all the registry entries in winedefault.reg then ? > > No, that wasn't part of the "instructions" .. That's completely and utterly *required* for about anything that you intend to run on Wine, so of course it's not mentioned in the "instructions" ! (well, it's not that bad, but that's nearly the extent of it) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Sept. 29, 2001

Bug in CreateWindowEx

by Luke Stras

I'm trying to get Civ2 to run under wine (checked out via CVS today), and I've run into a particular problem. The installation is totally stand-alone -- all DLLs are built-in. I get an invalid page fault in X11DRV_GetDC [winpos.c:441], at the line which says: drawable = data->client_window Some debugger work shows that data is NULL. Now, the backtrace shows that we get *here* from a call to WIN_GetMinMaxInfo from CreateWindowEx [win.c:885]. The problem, as I see it, is that USER_Driver.pCreateWindow doesn't get called until [win.c:922] -- in other words, when the callback inside Civ2 receives the WM_GETMINMAXINFO, it tries acquiring a DC for some reason, and this causes the crash. Now, I don't know enough about how wine works internall to fix this. Can anyone provide any suggestions? -- Luke Stras <stras(a)utias.toronto.edu> "The meek can have the Earth; the rest of us have other plans" --Henry Spencer

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Ove Kaaven

On Sat, 29 Sep 2001, Daniel Walker wrote: > > I got a marshalling error from IKernel.exe .. > > trace:ole:StdMarshal_Release (0x403ab9f0)->Release() > trace:ole:LRPC_feed marshalling error 80070057 > trace:ole:RpcChannel_Release (0x403ab9a0)->Release() > > If that means anything .. Probably only that there's a problem with your setup. For example, perhaps you forgot to copy stdole32.tlb from real windows, as instructed?

Sept. 29, 2001

installshield 6

by Daniel Walker

Is there a specific application that I should be attempting to install ? Or is there a specific version of stdole32.tlb that I need ? Daniel Walker

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Daniel Walker

In that case I assume I've done it then .. I'm not using a native registry.. Daniel Walker Andreas Mohr wrote: > > On Sat, Sep 29, 2001 at 04:26:12AM -0700, Daniel Walker wrote: > > Gerard Patel wrote: > > > > > > At 03:11 AM 29/09/2001 -0700, you wrote: > > > >> Probably only that there's a problem with your setup. For example, perhaps > > > >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > > > > > > > > > > No , I did that.. > > > > > > Well, did you import all the registry entries in winedefault.reg then ? > > > > No, that wasn't part of the "instructions" .. > That's completely and utterly *required* for about anything that you > intend to run on Wine, so of course it's not mentioned > in the "instructions" ! > (well, it's not that bad, but that's nearly the extent of it)

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Daniel Walker

Gerard Patel wrote: > > At 03:11 AM 29/09/2001 -0700, you wrote: > >> Probably only that there's a problem with your setup. For example, perhaps > >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > > > > No , I did that.. > > Well, did you import all the registry entries in winedefault.reg then ? No, that wasn't part of the "instructions" .. Daniel Walker

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Daniel Walker

Ove Kaaven wrote: > > On Sat, 29 Sep 2001, Daniel Walker wrote: > > > > > I got a marshalling error from IKernel.exe .. > > > > trace:ole:StdMarshal_Release (0x403ab9f0)->Release() > > trace:ole:LRPC_feed marshalling error 80070057 > > trace:ole:RpcChannel_Release (0x403ab9a0)->Release() > > > > If that means anything .. > > Probably only that there's a problem with your setup. For example, perhaps > you forgot to copy stdole32.tlb from real windows, as instructed? No , I did that.. Daniel Walker

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Daniel Walker

I got a marshalling error from IKernel.exe .. trace:ole:StdMarshal_Release (0x403ab9f0)->Release() trace:ole:LRPC_feed marshalling error 80070057 trace:ole:RpcChannel_Release (0x403ab9a0)->Release() If that means anything .. Daniel Walker Ove Kaaven wrote: > > We still don't have progress, but Alexandre committed the stuff I > submitted, so here's an updated diff against the latest CVS... > good luck debugging...

Sept. 29, 2001

Re: InstallShield 6 again (debuggers requested)

by Ove Kaaven

We still don't have progress, but Alexandre committed the stuff I submitted, so here's an updated diff against the latest CVS... good luck debugging...

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by Andreas Mohr

On Fri, Sep 28, 2001 at 07:22:37PM +0200, Uwe Bonnes wrote: > >>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: > ... > eric> however, what I don't know is what 096d4e18 is (thread of same > eric> process or newly created thread). looks more like and old thread > eric> but... on the other hand, since createprocess is called without > eric> the inherit flag and that no argument are given on the command > eric> line, the newly created process shouldn't wait on this event > eric> (0x7C), unless it opens the event with its name (Uwe, is there > eric> something like that after line 51145 ?), or there's a mess in > eric> message sending/processing (or wait for a window creation) that > eric> doesn't take place > > This TKWDOG is some strange process. Starting is seperatly on WinXX doesn't > give any visible output ( beside some window flashing up short and then > vanishing again), but the taskmanager shows it running. I guess that this > TKWDOG belongs to the license checking of that progarms (Synario SCS, > Xilinux seems to use them too). TKWDOG has CreateProcess call(s?) too. I > guess that TKWDOG is supposed to spwawn another process and finish and I > suspect that this doen't happen in wine. Have to dig deeper when I find > time... TK...(W)atch(DOG) ? That would make quite some sense why it does some event waiting and stuff. I didn't analyze it further, though. -- Andreas Mohr

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by Uwe Bonnes

>>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: ... eric> however, what I don't know is what 096d4e18 is (thread of same eric> process or newly created thread). looks more like and old thread eric> but... on the other hand, since createprocess is called without eric> the inherit flag and that no argument are given on the command eric> line, the newly created process shouldn't wait on this event eric> (0x7C), unless it opens the event with its name (Uwe, is there eric> something like that after line 51145 ?), or there's a mess in eric> message sending/processing (or wait for a window creation) that eric> doesn't take place This TKWDOG is some strange process. Starting is seperatly on WinXX doesn't give any visible output ( beside some window flashing up short and then vanishing again), but the taskmanager shows it running. I guess that this TKWDOG belongs to the license checking of that progarms (Synario SCS, Xilinux seems to use them too). TKWDOG has CreateProcess call(s?) too. I guess that TKWDOG is supposed to spwawn another process and finish and I suspect that this doen't happen in wine. Have to dig deeper when I find time... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by eric pouech

Andreas Mohr wrote: > > On Fri, Sep 28, 2001 at 11:16:40AM +0200, Eric Pouech wrote: > > > 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd > > can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) > > if it's the case, it means that the started program rely on some messages order to do some stuff > > the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message... > Nope (or maybe I don't get your point). > Most probably it's the standard CreateProcess(), WaitForSingleObject() combo > to wait for successful program execution or so (which gets confirmed by the > close address range between these two function calls). well, if I analyse the trace: 1844 08068938:Call kernel32.CreateEventA(00000000,00000001,00000000,100192a0 "TKMESG response trigger") ret=100168c1 1845 08068938:Ret kernel32.CreateEventA() retval=0000007c ret=100168c1 ... 51123 08068938:Call kernel32.ResetEvent(0000007c) ret=100169fd 51124 08068938:Ret kernel32.ResetEvent() retval=00000001 ret=100169fd +++ 0x7C is a handle to an event (and still valid at this point) 51125 08068938:Call kernel32.CreateProcessA(00000000,10019364 "tkwdog.exe",00000000,00000000,00000000,04000000,00000000,00000000,405f6b7c,405f6b6c) ret=10016a23 51126 fixme:module:CreateProcessA (D:\cae\pasic90\scs\TKWDOG.EXE,...): CREATE_DEFAULT_ERROR_MODE ignored 51127 fixme:pthread_kill_other_threads_np 51128 FIXME:pthread_rwlock_rdlock 51129 FIXME:pthread_rwlock_unlock 51130 FIXME:pthread_rwlock_rdlock 51131 FIXME:pthread_rwlock_unlock 51132 08068938:Ret kernel32.CreateProcessA() retval=00000001 ret=10016a23 51133 08068938:Call kernel32.WaitForSingleObject(0000007c,ffffffff) ret=10016a4d +++ the process that called CreateProcess waits on 0x7C, which is still the event above, and not a process handle, and then blocks forever 51134 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406c7efd 51135 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51136 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51137 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) 51138 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) retval=00000001 51139 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) 51140 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) retval=00000276 51141 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) 51142 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) retval=00000000 51143 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51144 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd so I assume that thread 096d4e18 (in line 51145) should wait on a specific object too however, what I don't know is what 096d4e18 is (thread of same process or newly created thread). looks more like and old thread but... on the other hand, since createprocess is called without the inherit flag and that no argument are given on the command line, the newly created process shouldn't wait on this event (0x7C), unless it opens the event with its name (Uwe, is there something like that after line 51145 ?), or there's a mess in message sending/processing (or wait for a window creation) that doesn't take place A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by Andreas Mohr

On Fri, Sep 28, 2001 at 11:16:40AM +0200, Eric Pouech wrote: > > 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd > can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) > if it's the case, it means that the started program rely on some messages order to do some stuff > the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message... Nope (or maybe I don't get your point). Most probably it's the standard CreateProcess(), WaitForSingleObject() combo to wait for successful program execution or so (which gets confirmed by the close address range between these two function calls). --> search.microsoft.com "CreateProcess WaitForSingleObject" for a description. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by Eric Pouech

> 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

Sept. 28, 2001

Re: fixme:pthread_kill_other_threads

by Uwe Bonnes

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> Uwe Bonnes wrote: >> I don't understand why pthread_kill_other_threads ist called when a >> programm creates a new process. With the pthread_kill_other_threads >> call, the starting process dies. ... What can happen between chdir() >> and execve() to trigger the pthread_kill_other_threads() call? Dan> This is per the Posix standard; Dan> http://www.opengroup.org/onlinepubs/007908799/xsh/exec.html says: Dan> "A call to any exec function from a process with more than one Dan> thread results in all threads being terminated and the new Dan> executable image being loaded and executed." Dan> Maybe this is hurting you because LinuxThreads implements fork() in Dan> a nonstandard way, i.e. maybe it only forks the current thread Dan> rather than the whole process? Dan> In any case, what you're trying to do is so common and important Dan> that maybe it's a glibc bug. Which glibc and kernel are you using? I am trying to run a windows program combo ( schem.exe from the quicklogic qworks 9.0 beta). The programm starts, tells about the demo license and then starts a "background" process called tkwdog.exe, as I understand it. After the background programm pops up its desktop window, the schem.exe window isn't refreshed any more. I thought this would relate to pthread_kill_other_threads_np, but obviously I am wrong. schem.exe hangs in a WaitForSingleObject call: Here again an excerpt from the relay log, hopefully more helpfull: 1844 08068938:Call kernel32.CreateEventA(00000000,00000001,00000000,100192a0 "TKMESG response trigger") ret=100168c1 1845 08068938:Ret kernel32.CreateEventA() retval=0000007c ret=100168c1 ... 51123 08068938:Call kernel32.ResetEvent(0000007c) ret=100169fd 51124 08068938:Ret kernel32.ResetEvent() retval=00000001 ret=100169fd 51125 08068938:Call kernel32.CreateProcessA(00000000,10019364 "tkwdog.exe",00000000,00000000,00000000,04000000,00000000,00000000,405f6b7c,405f6b6c) ret=10016a23 51126 fixme:module:CreateProcessA (D:\cae\pasic90\scs\TKWDOG.EXE,...): CREATE_DEFAULT_ERROR_MODE ignored 51127 fixme:pthread_kill_other_threads_np 51128 FIXME:pthread_rwlock_rdlock 51129 FIXME:pthread_rwlock_unlock 51130 FIXME:pthread_rwlock_rdlock 51131 FIXME:pthread_rwlock_unlock 51132 08068938:Ret kernel32.CreateProcessA() retval=00000001 ret=10016a23 51133 08068938:Call kernel32.WaitForSingleObject(0000007c,ffffffff) ret=10016a4d 51134 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406c7efd 51135 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51136 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51137 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) 51138 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) retval=00000001 51139 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) 51140 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) retval=00000276 51141 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) 51142 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) retval=00000000 51143 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51144 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd There is no more message from process 08068938 until I abort the program with ^C on the console. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 28, 2001

Re: _NET_WM_NAME support patch

by Dmitry Timoshkov

"Ilya Konstantinov" <wine-patches(a)future.shiny.co.il> wrote: > This patch adds a _NET_WM_NAME(UTF8_STRING) property to every window, > storing it's title in non-ambigous UTF8 encoding. This is a part of the > NET_WM standard. The UTF8 title feature is currently implemented only > by KWin (KDE's window manager), but is adopted by both GNOME and KDE > camps. @@ -746,12 +748,32 @@ BOOL X11DRV_SetWindowText( HWND hwnd, LP return FALSE; } WideCharToMultiByte(text_cp, 0, text, -1, buffer, count, NULL, NULL); + + count = utf8_wcstombs(text, strlenW(text), utf8_buffer, 0); Why didn't you use win32 call instead of a purely internal one? count = WideCharToMultiByte( CP_UTF8, 0, text, -1, NULL, 0, NULL, NULL ); utf8_buffer = HeapAlloc( GetProcessHeap(), 0, count ); count = WideCharToMultiByte( CP_UTF8, 0, text, -1, utf8_buffer, count, NULL, NULL ); -- Dmitry.

Sept. 27, 2001

Re: fixme:pthread_kill_other_threads

by Dan Kegel

Uwe Bonnes wrote: > I don't understand why pthread_kill_other_threads ist called when a programm > creates a new process. With the pthread_kill_other_threads call, the starting > process dies. ... > What can happen between chdir() and execve() to trigger the > pthread_kill_other_threads() call? This is per the Posix standard; http://www.opengroup.org/onlinepubs/007908799/xsh/exec.html says: "A call to any exec function from a process with more than one thread results in all threads being terminated and the new executable image being loaded and executed." Maybe this is hurting you because LinuxThreads implements fork() in a nonstandard way, i.e. maybe it only forks the current thread rather than the whole process? In any case, what you're trying to do is so common and important that maybe it's a glibc bug. Which glibc and kernel are you using? - Dan

Sept. 27, 2001

Re: fixme:pthread_kill_other_threads

by Ove Kaaven

On Thu, 27 Sep 2001, Uwe Bonnes wrote: > What can happen between chdir() and execve() to trigger the > pthread_kill_other_threads() call? Well, not much... glibc's execve() implementation calls pthread_kill_other_threads_np() itself to prepare the threading system for an exec. This is a feature, not a bug.

Sept. 27, 2001

fixme:pthread_kill_other_threads

by Uwe Bonnes

Hallo, I don't understand why pthread_kill_other_threads ist called when a programm creates a new process. With the pthread_kill_other_threads call, the starting process dies. This is a +relay,+server,+... log: trace:dosfs:DOSFS_GetFullName returning /home/dosd/cae/ql82/scs/TKWDOG.EXE = D:\CAE\QL82\SCS\TKWDOG.EXE 08068938: new_process( inherit_all=0, create_flags=67108864, start_flags=257, exe_file=200, hstdin=4, hstdout=8, hstderr=12, cmd_show=1, filename="D:\cae\ql82\scs\TKWDOG.EXE" ) 08068938: new_process() = 0 { info=204 } fixme:pthread_kill_other_threads_np 08068938: select( flags=12, cookie=0x405c5778, sec=1001624181, usec=913175, handles={204} ) 08068938: select() = PENDING 00000000: *fd* 0 -> 46 08625a70: *fd* 6 <- 46 08625a70: *fd* 8 <- 47 08625a70: init_thread( unix_pid=2070, teb=0x40127ce0, entry=(nil), reply_fd=6, wait_fd=8 ) 08625a70: init_thread() = 0 { pid=0x86259a0, tid=0x8625a70, boot=0, version=53 } This is an strace of that part: 1898 close(28) = 0 1898 chdir("/home/dosd/cae/ql82/scs") = 0 1898 write(2, "fixme:pthread_kill_other_threads"..., 36) = 36 1898 execve("/usr/local/bin/wine", ["/usr/local/bin/wine", "--", "tkwdog.exe"], [/* 57 vars */] <unfinished ...> and I think this relates to scheduler/process.c:fork_and_exec if (newdir) chdir(newdir); if (argv && envp) { if (!filename) { argv[1] = "--"; exec_wine_binary( argv, envp ); } else execve( filename, argv, envp ); } What can happen between chdir() and execve() to trigger the pthread_kill_other_threads() call? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

Sept. 27, 2001

Problem in installation of Wine on SPARC Solaris 8.0

by Mrugan Bhorkar

I am trying to install Wine on UltraSPARC Solaris 8.0 using tools/wineinstall. The installation script fails at following point...... gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -D__WINE__ -D_REENTRANT -I/usr/openwin/include -o lex.ppl.o lex.ppl.c In file included from ./ppl.l:141: ../../include/config.h:486: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition ./ppl.l: In function `pplex': ./ppl.l:336: `pplval' undeclared (first use in this function) ./ppl.l:336: (Each undeclared identifier is reported only once ./ppl.l:336: for each function it appears in.) make: *** [lex.ppl.o] Error 1 Can anybody suggest how to fix this?? Thanks Mrugan __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com

Sept. 27, 2001

Re: pthread_atfork and PTHREAD_FORK

by Ove Kaaven

On Wed, 26 Sep 2001, Bill Medland wrote: > Is it legal for pthread_atfork to be called with null parameters (in which > case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). NAME pthread_atfork - register handlers to be called at fork(2) time SYNOPSIS #include <pthread.h> int pthread_atfork(void (*prepare)(void), void (*par ent)(void), void (*child)(void)); DESCRIPTION pthread_atfork registers handler functions to be called just before and just after a new process is created with fork(2). The prepare handler will be called from the par ent process, just before the new process is created. The parent handler will be called from the parent process, just before fork(2) returns. The child handler will be called from the child process, just before fork(2) returns. => One or several of the three handlers prepare, parent and => child can be given as NULL, meaning that no handler needs => to be called at the corresponding point. pthread_atfork can be called several times to install sev eral sets of handlers. At fork(2) time, the prepare han dlers are called in LIFO order (last added with pthread_atfork, first called before fork), while the par ent and child handlers are called in FIFO order (first added, first called). To understand the purpose of pthread_atfork, recall that fork(2) duplicates the whole memory space, including mutexes in their current locking state, but only the call ing thread: other threads are not running in the child process. Thus, if a mutex is locked by a thread other than the thread calling fork, that mutex will remain locked forever in the child process, possibly blocking the execu tion of the child process. To avoid this, install handlers with pthread_atfork as follows: the prepare handler locks the global mutexes (in locking order), and the parent and child handlers unlock them (in reverse order). Alterna tively, prepare and parent can be set to NULL and child to a function that calls pthread_mutex_init on the global mutexes. RETURN VALUE pthread_atfork returns 0 on success and a non-zero error code on error. ERRORS ENOMEM insufficient memory available to register the han dlers. AUTHOR Xavier Leroy <Xavier.Leroy(a)inria.fr> SEE ALSO fork(2), pthread_mutex_lock(3), pthread_mutex_unlock(3). LinuxThreads PTHREAD_ATFORK(3)

Sept. 26, 2001

pthread_atfork and PTHREAD_FORK

by Bill Medland

Can someone tell me what we should have here? (It might be interesting to know how it's supposed to work too but that's beside the point). I had a case where pthread_atfork was being called with two null pointers, so it all blew up when PTHREAD_FORK tried to execute the code they pointed to. Is it legal for pthread_atfork to be called with null parameters (in which case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). Bill

Sept. 26, 2001

pthread_atfork problems

by Bill Medland

Any chance of a hand with this please? I have just traced a problem to the fact that __pthread_atfork is passed a couple of null pointers, which I presume is an illegal thing to do. Can anyone point me at the code that results in __pthread_atfork being called and/or explain why it would be called with null pointers? TIA Bill

Sept. 26, 2001

Re: GetMessageTime

by Alexandre Julliard

"David Hammerton" <david(a)transgaming.com> writes: > BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, > GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the > game Alice seems to make it return 0) - so the value sent to XSetInputFocus for > the time is too small, and hence X refuses to give the window focus. The real fix is that XSetInputFocus should not use GetMessageTime at all, this is only a temporary hack. To conform to the ICCCM the focus time should be based on the timestamp of a previous X event, and the focus should never be changed if we didn't receive an event. To do this right probably requires supporting the take focus protocol, as was discussed some time ago. -- Alexandre Julliard julliard(a)winehq.com

Sept. 26, 2001

Re: Getting Routing tables

by Michael Stefaniuc

On Wed, Sep 26, 2001 at 07:17:36AM +1000, Robert Lunnon wrote: > In my pitiful attempt to hack on WINE I have come to an impasse. I have > managed to find portable equivalents to get the interface name and the number > of interfaces in winsock/wsock32 but I can't seem to find a portable way to > get to the routing table. In Solaris (why I'm doing the hacking) there is a > vague mention in the man pages of being able to get this info by reading > /dev/ip but no information about how to actually do it. > > Can anyone provide a hint on how this can be done portably or to a multi-os > implementation of netstat that might serve as an example. (Only netstat > sources I have found are OS specific) You can't realy do that in a portable way. That's why I choosed to parse /proc/net/route (and because most of the winsock stuff was also only Linux specific). > Hurry because in desperation I am actually thinking of piping the output of > netstat -r That seems to be the most resonable way to go. If you want to also parse the header of the netstat output you should set LANG=C before. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 26, 2001

Getting Routing tables

by Robert Lunnon

In my pitiful attempt to hack on WINE I have come to an impasse. I have managed to find portable equivalents to get the interface name and the number of interfaces in winsock/wsock32 but I can't seem to find a portable way to get to the routing table. In Solaris (why I'm doing the hacking) there is a vague mention in the man pages of being able to get this info by reading /dev/ip but no information about how to actually do it. Can anyone provide a hint on how this can be done portably or to a multi-os implementation of netstat that might serve as an example. (Only netstat sources I have found are OS specific) Hurry because in desperation I am actually thinking of piping the output of netstat -r Thanks Bob

Sept. 25, 2001

BeginPaint not called on WM_PAINT...

by Andreas Mohr

Hi all, the game Undying emits lots and lots of err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 20029! errors. This is because it simply does: 0806d2c8:Call user32.DispatchMessageA(406c29b0) ret=1090e313 0806d2c8:Call window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) 0806d2c8:Call user32.ValidateRect(00020029,00000000) ret=11107b57 0806d2c8:Ret user32.ValidateRect() retval=00000001 ret=11107b57 0806d2c8:Ret window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) retval=00000000 This seems to be perfectly legal in order to validate the whole window update rect (NULL) and thus prevent further WM_PAINTs. (as http://www.intrepidhero.com/articles/wgpfd_errata/part2.html hints) In short: the wine error message is erroneous in this case. The Wine check is: if (painting && wndPtr && (wndPtr->flags & WIN_NEEDS_BEGINPAINT) && wndPtr->hrgnUpdate) { ERR("BeginPaint not called on WM_PAINT for hwnd %04x!\n", msg->hwnd); So I assume that either a) some flag or so doesn't get updated properly by that ValidateRect() or b) the error message check condition is (slightly) wrong. Could someone please fix this ? This happened to #WineHQ nick Thunderbird with latest version of winex (20010824). -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Sept. 25, 2001

GetMessageTime

by David Hammerton

Hey, Durings my hunting down for why SetFocus wasnt always working, I have traced it back to a problem with GetMessageTime(). (which I have made a temporary fix for, haven't sent it to wine-patches because its not the 'right' way of fixing it) GetMessageTime() is supposed to return the time of the last message received by GetMessage(). But there are two cases where the time set (req->time) is 0 - and I can't fix it. If you turn your eyes to server/queue.c, around line 910 and 926 you will see the two times this value gets set to 0. Statically. I believe the only way to fix this is some sort of restructuring, since GetCurrentTime() (used by all other functions that set req->time) relies on a variable thats not available to the wine server. Anyone else have any suggestions? BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the game Alice seems to make it return 0) - so the value sent to XSetInputFocus for the time is too small, and hence X refuses to give the window focus. As I said i've written a small patch for this, I may send it to wine-patches if its worth it, but I really think that the source of the problem should be addressed more urgently. David. -- David Hammerton, web programmer TransGaming Technologies Inc. http://www.transgaming.com david(a)transgaming.com

Sept. 25, 2001

Re: NG: Wine and cyrillic input and output ?

by Dmitry Timoshkov

"Nerijus Baliunas" <nerijus(a)users.sourceforge.net> wrote: > In my XF86Config-4 I have: > Option "XkbLayout" "lt" > Option "XkbOptions" "grp:ctrl_shift_toggle" - it means Ctrl+Shift switches layouts. > > I switched layouts 2 times in notepad. > Without patch: > > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : > err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : > err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) > > With patch: > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : > err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) > err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : > err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=2005) > > As you see, with patch "state" is different when switching layout second time. Sure. Wine corrects state according to its internal lpKeyState. Difference between internal and actual state value is due to the fact that Wine does not see (or better X does not show) some keyboard events. Since I also have "grp:ctrl_shift_toggle" I had seen the same state correction. Perhaps Wine should ignore ISO_Prev_Group/ISO_Next_Group keyboard events to not confuse users. -- Dmitry.

Sept. 25, 2001

Re: NG: Wine and cyrillic input and output ?

by Nerijus Baliunas

On Tue, 25 Sep 2001 19:30:02 +0900 Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: DT> Hello all. DT> DT> This patch fixes a couple of problems with keyboard group switching DT> reported in the news group: DT> 1. Group switch had never worked before, if the keyboard has been DT> switched outside of Wine. DT> 2. I was clearly stated that Group switch is active if event->state & 0x2000, DT> not event->state & 0x6000. DT> DT> Please test it on your local configurations and report back. In my XF86Config-4 I have: Option "XkbLayout" "lt" Option "XkbOptions" "grp:ctrl_shift_toggle" - it means Ctrl+Shift switches layouts. I switched layouts 2 times in notepad. Without patch: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) With patch: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=2005) As you see, with patch "state" is different when switching layout second time. Regards, Nerijus

Sept. 25, 2001

Re: Wine and cyrillic input and output ?

by Dmitry Timoshkov

I wrote: > This patch fixes a couple of problems with keyboard group switching > reported in the news group: > 1. Group switch had never worked before, if the keyboard has been > switched outside of Wine. Correct. > 2. I was clearly stated that Group switch is active if event->state & 0x2000, > not event->state & 0x6000. Wrong. Please replace AltGrMask = event->state & 0x2000; to AltGrMask = event->state & 0x6000; in the patch, all possible group indexes should be available. > Please test it on your local configurations and report back. If there will be > no objections, I'll send it to wine-patches. -- Dmitry.

Sept. 25, 2001

GetClipboardData

by Dominik Strasser

Hello, with MS WinWord I am encountering the following problem: If there's something selected, GetClipboardData is called. In GetClipboardData, there is the line: HWND hWnd = (hWndClipWindow) ? hWndClipWindow : GetActiveWindow(); hWndClipWindow is 0, so GetActiveWindow() is called which also returns 0. I tracked this down to PERQDATA_GetActiveWnd returning 0. This leads later to "w" bening 0 which results in an X error calling XConvertSelection. It happens in all modes, desktop managed, non managed. Does anybody have any clues ? Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser(a)mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

Sept. 25, 2001

NG: Wine and cyrillic input and output ?

by Dmitry Timoshkov

Hello all. This patch fixes a couple of problems with keyboard group switching reported in the news group: 1. Group switch had never worked before, if the keyboard has been switched outside of Wine. 2. I was clearly stated that Group switch is active if event->state & 0x2000, not event->state & 0x6000. Please test it on your local configurations and report back. If there will be no objections, I'll send it to wine-patches. Thanks. -- Dmitry.

Sept. 25, 2001

InstallShield 6 again (debuggers requested)

by Ove Kaaven

Here are some kludgy patches (against the current WineHQ CVS) that's supposed to make InstallShield 6 with its stupid interprocess COM sort of work, but it doesn't for some reason, probably because of something else in Wine that's broken... and because of a lack of time, I think I really need some debugging assistance. Most of these patches are too ugly to be submitted to the official wine as-is, I'll clean these parts up later, but probably not before InstallShield has been debugged and actually works with these hacks. To make this run, you need to copy stdole32.tlb from a real windows and put into c:\windows\system. Then run your favorite InstallShield 6 setup.exe and wait for it to crash. --debugmsg +ole is recommended. It crashes for me after about 25 remote method calls. If you find out why, let me know. Please.

Sept. 24, 2001

Re: Callwave doesn't run

by eric pouech

> Yes, the debugger starts, but I don't really think its configured > correctly, still. In order to get it to start, I have to start wine > from the directory I built it, so that it will find ./debugger/winedbg. > Shouldn't it look in the path for "winedbg," rather than only the > current directory? well, if you want to run wine from the directory it's built in, you need to : 1/ add to LD_LIBRARY_PATH the dlls subdir 2/ add to PATH the wine's dir check out the tools/winelauncher for some more on this > Possibly an interesting note, when I run as "wine -debugmsg +relay", and > the debugger is unable to start for whatever reason, no messages are > printed that aren't also printed with just "wine". "wine -debugmsg > +all" does, however, log extra stuff. Attached is the latter part of what > that yields. first, it's not a good idea to jam wine-devel with lots of logs. best practice is to put the log (if rather large, > 10k for example) somewhere on the web and put only the URL for retrieving the log in your mail (this will save bandwidth) > 08068490:trace:win32:dump_exports *******EXPORT DATA******* > 08068490:trace:win32:dump_exports 08068490:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 > 08068490: queue_exception_event( first=1, record={context={flags=00000000,eax=402a2a00,ebx=4033fe38,ecx=ffffffff,edx=40856c8b,esi=0000000f,edi=967c77e5,ebp=40856c8c,eip=402a2ab2,esp=40856694,eflags=00210246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x402a2ab2,params={0,967c77e5}} ) the dumping of export badly crashes did you test that your program isn't infected by a virus ? if not, what gives dumping (with winedump) the file (tools/winedump dump iamsetup.exe -x) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 23, 2001

Re: Callwave doesn't run

by Steven Walter

On Sat, Sep 22, 2001 at 09:55:10PM +0200, eric pouech wrote: > what's strange is that the relay posted only targets the debugger > process, not > the process creating the exception... > (the one creating the exception is 080671f0 and never shows up in the > trace) > how did you run your program ? which wine version are you using ? > (from your previous post, the debugger now starts) Yes, the debugger starts, but I don't really think its configured correctly, still. In order to get it to start, I have to start wine from the directory I built it, so that it will find ./debugger/winedbg. Shouldn't it look in the path for "winedbg," rather than only the current directory? Anyway, I started the program, from the directory where I built wine, as "wine -debugmsg +relay 'c:\iamsetup.exe'" Wine version is CVS from yesterday, though it has occurred in the CVS version for several weeks; I've never not had the problem. Possibly an interesting note, when I run as "wine -debugmsg +relay", and the debugger is unable to start for whatever reason, no messages are printed that aren't also printed with just "wine". "wine -debugmsg +all" does, however, log extra stuff. Attached is the latter part of what that yields. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell 08068490: init_process_done() = 0 { debugged=0 } 08068490:fixme:win32:PE_CreateModule Security directory ignored 08068490:trace:global:GLOBAL_Alloc 138 flags=0042 08068490:trace:heap:HeapAlloc (40620000,00000002,000000a0): returning 40621170 08068490:trace:string:lstrcpynA (0x406211e9, "IamSetup."..., 9) 08068490:trace:dosfs:GetShortPathNameA "C:\\IamSetup.exe" 08068490:trace:heap:HeapAlloc (40620000,00000002,00000400): returning 4062121c 08068490:trace:string:lstrcpynA (0x4062121f, "IamSetup.exe", 13) 08068490:trace:string:lstrcpynA ((nil), ""..., 0) 08068490:trace:dosfs:GetShortPathNameA returning (null) 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:trace:heap:HeapAlloc (40620000,0000000a,00000060): returning 40620438 08068490:trace:dosfs:GetShortPathNameA "C:\\IamSetup.exe" 08068490:trace:heap:HeapAlloc (40620000,00000002,00000400): returning 4062121c 08068490:trace:string:lstrcpynA (0x4062121f, "IamSetup.exe", 13) 08068490:trace:string:lstrcpynA (0x40620484, "C:\\IamSetup.exe", 16) 08068490:trace:dosfs:GetShortPathNameA returning "C:\\IamSetup.exe" 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:trace:win32:dump_exports *******EXPORT DATA******* 08068490:trace:win32:dump_exports 08068490:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08068490: queue_exception_event( first=1, record={context={flags=00000000,eax=402a2a00,ebx=4033fe38,ecx=ffffffff,edx=40856c8b,esi=0000000f,edi=967c77e5,ebp=40856c8c,eip=402a2ab2,esp=40856694,eflags=00210246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x402a2ab2,params={0,967c77e5}} ) 08068490: queue_exception_event() = 0 { handle=0 } 08068490:trace:seh:EXC_CallHandler calling handler at 0x40070348 code=c0000005 flags=0 08068490: queue_exception_event( first=0, record={context={flags=00000000,eax=402a2a00,ebx=4033fe38,ecx=ffffffff,edx=40856c8b,esi=0000000f,edi=967c77e5,ebp=40856c8c,eip=402a2ab2,esp=40856694,eflags=00210246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x402a2ab2,params={0,967c77e5}} ) 08068490: queue_exception_event() = 0 { handle=0 } 08068490: create_event( manual_reset=1, initial_state=0, inherit=1, name=L"" ) 08068490: create_event() = 0 { handle=24 } 08068490:trace:heap:HeapAlloc (40620000,00000002,0000006c): returning 4062121c 08068490:trace:reg:NtOpenKey (0x80000002,L"Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug",f003f,0x40744830) 08068490: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug" ) Open key \\Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug 08068490: open_key() = 0 { hkey=32 } 08068490:trace:reg:NtOpenKey <- 0x0020 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:trace:reg:RegQueryValueExA (0x20,"Debugger",(nil),0x40744828,0x40744840,0x4074482c=256) 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 4062121c 08068490:trace:reg:NtQueryValueKey (0x20,L"Debugger",2,0x407446f0,256) 08068490: get_key_value( hkey=32, offset=00000000, name=L"Debugger" ) Get key \\Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug value "Debugger"="debugger/winedbg %ld %ld" 08068490: get_key_value() = 0 { type=1, len=50, data={64,00,65,00,62,00,75,00,67,00,67,00,65,00,72,00,2f,00,77,00,69,00,6e,00,65,00,64,00,62,00,67,00,20,00,25,00,6c,00,64,00,20,00,25,00,6c,00,64,00,00,00} } 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:trace:reg:RegQueryValueExA (0x20,"Auto",(nil),0x40744828,0x40744824,0x4074482c=4) 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 4062121c 08068490:trace:reg:NtQueryValueKey (0x20,L"Auto",2,0x407446f0,256) 08068490: get_key_value( hkey=32, offset=00000000, name=L"Auto" ) Get key \\Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug value "Auto"="1" 08068490: get_key_value() = 0 { type=1, len=4, data={31,00,00,00} } 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:trace:reg:RegQueryValueExA (0x20,"Auto",(nil),0x40744828,0x40744834,0x4074482c=10) 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 4062121c 08068490:trace:reg:NtQueryValueKey (0x20,L"Auto",2,0x407446f0,256) 08068490: get_key_value( hkey=32, offset=00000000, name=L"Auto" ) Get key \\Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug value "Auto"="1" 08068490: get_key_value() = 0 { type=1, len=4, data={31,00,00,00} } 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490: close_handle( handle=32 ) 08068490: close_handle() = 0 { fd=-1 } 08068490:trace:seh:start_debugger Starting debugger (fmt=debugger/winedbg %ld %ld) 08068490:trace:module:CreateProcessA app '(null)' cmdline 'debugger/winedbg 134640208 24' 08068490:trace:heap:HeapAlloc (40620000,00000002,00000020): returning 4062121c 08068490:trace:module:get_file_name trying 'debugger/winedbg' 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 40621248 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg.exe (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg.exe 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 4062126c 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 406214a4 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg.exe' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,406214a4): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,4062126c): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 40621248 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 40621480 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,40621480): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:module:get_file_name trying 'debugger/winedbg 134640208' 08068490:trace:heap:HeapAlloc (40620000,00000002,00000020): returning 40621248 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg 134640208.exe (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg 134640208.exe 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 40621274 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 406214ac 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg 134640208.exe' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,406214ac): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621274): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg 134640208 (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg 134640208 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 40621248 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 40621480 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg 134640208' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,40621480): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:module:get_file_name trying 'debugger/winedbg 134640208 24' 08068490:trace:heap:HeapAlloc (40620000,00000002,00000024): returning 40621248 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg 134640208 24.exe (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg 134640208 24.exe 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 40621278 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 406214b0 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg 134640208 24.exe' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,406214b0): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621278): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:dosfs:DOSFS_GetFullName debugger/winedbg 134640208 24 (last=1) 08068490:trace:string:lstrcpynA (0x40743e70, "/home/srwalter", 1024) 08068490:trace:string:lstrcpynA (0x40743e7f, "", 1009) 08068490:trace:string:lstrcpynA (0x40744273, "", 1021) 08068490:trace:dosfs:DOSFS_FindUnixName /home/srwalter,debugger/winedbg 134640208 24 08068490:trace:heap:HeapAlloc (40620000,00000002,0000022c): returning 40621248 08068490:trace:heap:HeapAlloc (40620000,00000002,00000018): returning 40621480 08068490:warn:dosfs:DOSFS_FindUnixName 'debugger/winedbg 134640208 24' not found in '/home/srwalter' 08068490:trace:heap:HeapFree (40620000,00000002,40621480): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,40621248): returning TRUE 08068490:trace:heap:HeapFree (40620000,00000002,4062121c): returning TRUE 08068490:err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640208 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger 08068490: event_op( handle=24, op=1 ) 08068490: event_op() = 0 08068490:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08068490:trace:seh:EXC_CallHandler calling handler at 0x4006fbb0 code=c0000005 flags=2 08068490:trace:seh:EXC_CallHandler handler returned 1 08068490: terminate_thread( handle=-2, exit_code=-1073741819 ) 08068490: terminate_thread() = 0 { self=1, last=1 } 08068490: *killed* exit_code=-1073741819 /home/srwalter/.wine/user.reg: saving key \\User\\srwalter /home/srwalter/.wine/system.reg: saving key \\Machine /home/srwalter/.wine/userdef.reg: saving key \\User\\.Default Server: exiting (pid=15202)

Sept. 22, 2001

Re: Callwave doesn't run

by eric pouech

Steven Walter wrote: > > On Sat, Sep 22, 2001 at 09:26:22AM +0200, eric pouech wrote: > > the first fixme is harmless > > the second part means that an exception occured in the program (likely a > > seg fault) > > and the debugger couldn't be launched to display the context of the > > error > > read the doc and properly set up the debugger for this information, > > and/or > > look at the various ways to submit a full bug report (running with > > -debugmsg +relay > > and quoting the 500 lines before the point the exception is triggered is > > quite always a good starting point) > > Attached is the /entire/ relay log. Its pretty obvious that it doesn't > get far. Additionally, the debugger seems to get killed for some > reason; it pops up, stays for a fraction of a second, and is then > killed. I get the message "Terminated" in the shell where I was running > wine. what's strange is that the relay posted only targets the debugger process, not the process creating the exception... (the one creating the exception is 080671f0 and never shows up in the trace) how did you run your program ? which wine version are you using ? (from your previous post, the debugger now starts) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 22, 2001

Re: Callwave doesn't run

by Steven Walter

On Sat, Sep 22, 2001 at 09:26:22AM +0200, eric pouech wrote: > the first fixme is harmless > the second part means that an exception occured in the program (likely a > seg fault) > and the debugger couldn't be launched to display the context of the > error > read the doc and properly set up the debugger for this information, > and/or > look at the various ways to submit a full bug report (running with > -debugmsg +relay > and quoting the 500 lines before the point the exception is triggered is > quite always a good starting point) Attached is the /entire/ relay log. Its pretty obvious that it doesn't get far. Additionally, the debugger seems to get killed for some reason; it pops up, stays for a fraction of a second, and is then killed. I get the message "Terminated" in the shell where I was running wine. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell fixme:win32:PE_CreateModule Security directory ignored fixme:pthread_kill_other_threads_np 084a9b88:Call PE DLL (proc=0x40907958,module=408f9000,type=1,res=0x1) 084a9b88:Ret PE DLL (proc=0x40907958,module=408f9000,type=1,res=0x1) retval=1 084a9b88:Call PE DLL (proc=0xbfed135c,module=bfed0000,type=1,res=0x1) 084a9b88:Call kernel32.DisableThreadLibraryCalls(bfed0000) ret=bfed136f 084a9b88:Ret kernel32.DisableThreadLibraryCalls() retval=00000001 ret=bfed136f 084a9b88:Ret PE DLL (proc=0xbfed135c,module=bfed0000,type=1,res=0x1) retval=1 084a9b88:Starting process /home/srwalter/cvs/wine/debugger/winedbg (entryproc=0x40749148) 084a9b88:Call ntdll.__wine_get_main_args(407867fc) ret=40749164 084a9b88:Ret ntdll.__wine_get_main_args() retval=00000003 ret=40749164 084a9b88:Call kernel32.IsBadWritePtr(408a6e8c,00000004) ret=bfed1795 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed1795 084a9b88:Call kernel32.VxDCall3(00010012) ret=bfed17be fs=008f eax=80000001 ebx=4076fe94 ecx=00000001 edx=408a6e8c esi=407868ac edi=40786b40 ebp=408a6e4c esp=408a6e40 ds=002b es=002b gs=0000 flags=00200282 084a9b88:Ret kernel32.VxDCall3() retval=00000000 ret=bfed17be fs=008f eax=00000000 ebx=4076fe94 ecx=00000001 edx=408a6e8c esi=407868ac edi=40786b40 ebp=408a6e4c esp=408a6e4c ds=002b es=002b gs=0000 flags=00200282 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.IsBadWritePtr(408a6e88,00000004) ret=bfed15d1 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15d1 084a9b88:Call kernel32.IsBadWritePtr(408a6e84,00000004) ret=bfed15e8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15e8 084a9b88:Call kernel32.IsBadWritePtr(408a6e80,00000004) ret=bfed15f8 084a9b88:Ret kernel32.IsBadWritePtr() retval=00000000 ret=bfed15f8 084a9b88:Call kernel32.VxDCall6(0001001a) ret=bfed1626 fs=008f eax=00000001 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e1c ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall6() retval=00000002 ret=bfed1626 fs=008f eax=00000002 ebx=408a6e80 ecx=00000000 edx=408a6e80 esi=40938960 edi=408a6e88 ebp=408a6e40 esp=408a6e34 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.VxDCall1(00010013) ret=bfed16ca fs=008f eax=00000001 ebx=4076fe94 ecx=00000000 edx=40786908 esi=0000001c edi=00000250 ebp=408a6e90 esp=408a6e50 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Ret kernel32.VxDCall1() retval=00000000 ret=bfed16ca fs=008f eax=00000000 ebx=4076fe94 ecx=00000000 edx=40786908 esi=0000001c edi=00000250 ebp=408a6e90 esp=408a6e54 ds=002b es=002b gs=0000 flags=00200202 084a9b88:Call kernel32.GetStdHandle(fffffff5) ret=4075db3b 084a9b88:Ret kernel32.GetStdHandle() retval=00000008 ret=4075db3b 084a9b88:Call kernel32.SetConsoleCursorPosition(00000008,00010000) ret=4075db41 Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np 084a9b88:Ret kernel32.SetConsoleCursorPosition() retval=00000001 ret=4075db41 084a9b88:Call kernel32.GetStdHandle(fffffff5) ret=4075bf58 084a9b88:Ret kernel32.GetStdHandle() retval=00000008 ret=4075bf58 084a9b88:Call kernel32.WriteFile(00000008,40785760,00000014,00000000,00000000) ret=4075bf5e 084a9b88:Ret kernel32.WriteFile() retval=00000001 ret=4075bf5e 084a9b88:Call kernel32.DebugActiveProcess(080671f0) ret=4075cac7 084a9b88:Ret kernel32.DebugActiveProcess() retval=00000001 ret=4075cac7 084a9b88:Call kernel32.SetEvent(00000018) ret=4075dbae 084a9b88:Ret kernel32.SetEvent() retval=00000001 ret=4075dbae 084a9b88:Call kernel32.CloseHandle(00000018) ret=4075dbcc 084a9b88:Ret kernel32.CloseHandle() retval=00000001 ret=4075dbcc 084a9b88:Call kernel32.GetStdHandle(fffffff5) ret=4075bf58 084a9b88:Ret kernel32.GetStdHandle() retval=00000008 ret=4075bf58 084a9b88:Call kernel32.WriteFile(00000008,40785760,00000010,00000000,00000000) ret=4075bf5e 084a9b88:Ret kernel32.WriteFile() retval=00000001 ret=4075bf5e 084a9b88:Call kernel32.WaitForDebugEvent(408a6e34,ffffffff) ret=4075d998 084a9b88:Ret kernel32.WaitForDebugEvent() retval=00000001 ret=4075d998 084a9b88:Call kernel32.ReadProcessMemory(0000001c,4011033c,408a6b28,00000004,408a6b2c) ret=4075c8af 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075c8af 084a9b88:Call kernel32.ReadProcessMemory(0000001c,40126340,408a6d10,00000100,408a6b2c) ret=4075c8d0 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075c8d0 084a9b88:Call kernel32.ReadProcessMemory(0000001c,0040003c,408a6a10,00000004,00000000) ret=40753367 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753367 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400108,408a6a3c,000000f8,00000000) ret=40753398 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753398 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400200,408a6a14,00000028,00000000) ret=40753411 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753411 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400228,408a6a14,00000028,00000000) ret=40753411 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753411 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400250,408a6a14,00000028,00000000) ret=40753411 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753411 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400200,408a69b0,00000028,00000000) ret=4075698d 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075698d 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400228,408a69b0,00000028,00000000) ret=4075698d 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075698d 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400250,408a69b0,00000028,00000000) ret=4075698d 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075698d 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400200,0804ef90,00000078,00000000) ret=4075679f 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075679f 084a9b88:Call kernel32.CloseHandle(00000000) ret=40754235 084a9b88:Ret kernel32.CloseHandle() retval=00000000 ret=40754235 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400200,408a66a0,00000028,00000000) ret=4075365e 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075365e 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400228,408a66a0,00000028,00000000) ret=4075365e 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075365e 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400250,408a66a0,00000028,00000000) ret=4075365e 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=4075365e 084a9b88:Call kernel32.ReadProcessMemory(0000001c,00400180,408a6670,00000008,00000000) ret=407536fb 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=407536fb 084a9b88:Call kernel32.ReadProcessMemory(0000001c,0044bc20,408a6678,00000028,00000000) ret=40753760 084a9b88:Ret kernel32.ReadProcessMemory() retval=00000001 ret=40753760 084a9b88:Call kernel32.GetStdHandle(fffffff5) ret=4075bf58 084a9b88:Ret kernel32.GetStdHandle() retval=00000008 ret=4075bf58 084a9b88:Call kernel32.WriteFile(00000008,40785760,00000012,00000000,00000000) ret=4075bf5e 084a9b88:Ret kernel32.WriteFile() retval=00000001 ret=4075bf5e

Sept. 22, 2001

Re: Callwave doesn't run

by eric pouech

Steven Walter wrote: > > Is this a known problem? When I try to run the callwave install > program, or the callwave program itself, I merely get: > > fixme:win32:PE_CreateModule Security directory ignored > err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2) > Read the Wine Developers Guide on how to set up winedbg or another debugger the first fixme is harmless the second part means that an exception occured in the program (likely a seg fault) and the debugger couldn't be launched to display the context of the error read the doc and properly set up the debugger for this information, and/or look at the various ways to submit a full bug report (running with -debugmsg +relay and quoting the 500 lines before the point the exception is triggered is quite always a good starting point) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 22, 2001

Callwave doesn't run

by Steven Walter

Is this a known problem? When I try to run the callwave install program, or the callwave program itself, I merely get: fixme:win32:PE_CreateModule Security directory ignored err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Is this a configuration error on my part? Either way, is there some information I need to give to get this fixed? I appreciate it. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell

Sept. 21, 2001

Re: wsprintf

by Jeremy White

> Well, because *you* don't look at it doesn't mean it's not the right > place, does it? <g> I look at the CVS history quite often, and I find > that in many cases it's the best way to find out why things are done a > certain way. Ah, but I suspect that I am more representative of the typical hacker than you are, in this regard. Further, attempting to comprehend the changelog without the context of the relevant source code is generally unrewarding for me. However, I think I realize that my post and thread is largely useless. As much as I think you err on the side of brevity, I suspect that, except for my patches, you rarely go around deleting comments from code... Jer

Sept. 21, 2001

Re: wsprintf

by Bill Medland

Jeremy White <jwhite(a)codeweavers.com> wrote in message news:3BAB95E0.2020608(a)codeweavers.com... > > > > I added a comment in wsprintf16 to make Andreas happy. But I agree > > that the change log (and cvs diff) is the best way to store this kind > > of information. > > > > Okay, so it's a slow news day, and I feel like stirring up trouble. Seems like a reasonable idea for a Friday afternoon > > I would argue that it is, in fact, counterintuitive, to have this > sort of comment solely in the change log. The only time I ever think > to look at a diff (or even the change log) is when something has broken > recently. I agree in general, but I believe that such information is required (in two different forms) in both places. (In this particular case what is in the cvs seems fine to me, but to a large extent we have Alexandre to thank for keeping that tidy). > > IMO, it is appropriate to comment in the code, > whenever something useful about Wine/Windows behavior is learned, > especially when the knowledge is something non intuitive > like the fact that the 16 bit version and 32 bit version > behave differently. Here's my views The change log and cvs diff should explain why a change was made (and in an ideal world should refer to the supporting documentation e.g. bug numbers etc.). In this particular case it should mention, as it does, that the difference has been detected. The code should not contain change information. (I have worked on large code without the benefit of version control; it's revolting!). Comments in the code ought to reflect its current state, not how it got there. They should highlight important information that is not obvious (and what may be obvious to you may not be obvious to someone else or, more worryingly, may be obviously something else to them). Thus when two pieces of code look extremely similar but not identical it is worth a quick comment that the difference is deliberate, not the result of poor maintenance. (And I am a firm believer in doubly linked comments; e.g. one place contains the comment and the other refers to it). So what does anyone else think? Bill

Sept. 21, 2001

Re: wsprintf

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > Okay, so it's a slow news day, and I feel like stirring up trouble. Bad boy... > I would argue that it is, in fact, counterintuitive, to have this > sort of comment solely in the change log. The only time I ever think > to look at a diff (or even the change log) is when something has broken > recently. Well, because *you* don't look at it doesn't mean it's not the right place, does it? <g> I look at the CVS history quite often, and I find that in many cases it's the best way to find out why things are done a certain way. I don't see any reason to duplicate this info inside the code itself; since we are using a source control system we might as well take advantage of it. Plus it guarantees the info is stored permanently, unlike a comment that may get moved or lost next time the code is changed. -- Alexandre Julliard julliard(a)winehq.com

Sept. 21, 2001

Re: wsprintf

by Jeremy White

> > I added a comment in wsprintf16 to make Andreas happy. But I agree > that the change log (and cvs diff) is the best way to store this kind > of information. Okay, so it's a slow news day, and I feel like stirring up trouble. I would argue that it is, in fact, counterintuitive, to have this sort of comment solely in the change log. The only time I ever think to look at a diff (or even the change log) is when something has broken recently. IMO, it is appropriate to comment in the code, whenever something useful about Wine/Windows behavior is learned, especially when the knowledge is something non intuitive like the fact that the 16 bit version and 32 bit version behave differently. Jer

Sept. 21, 2001

Re: re-implementing real mode interrupts

by Alexandre Julliard

Mike McCormack <mike_mccormack(a)start.com.au> writes: > For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 > on the VWIN32 device calls to the real mode interrupt INT 13. It could > be re-implemented so that INT_Int13Handler does a DeviceIoControl and > the low level disk access code moved into the VWIN32 device > implemetation. VWIN32_DIOC_DOS_INT_13 is not really different from int 13, so it wouldn't make much difference either way. Much better would be to implement the higher level calls that are needed to reimplement the DOS interrupts; for instance int 13 should use the IOCTL_DISK calls of DeviceIoControl, int 25/26 should be replaced by Win32 device access (CreateFile("\\.\PHYSICALDRIVEx")+Read/WriteFile), etc. -- Alexandre Julliard julliard(a)winehq.com

Sept. 21, 2001

Re: wsprintf

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > I think this is part of what the change log is for. > > Alexandre has committed the patch, i will ask him if he wants me to > document something further and submit another patch. I added a comment in wsprintf16 to make Andreas happy. But I agree that the change log (and cvs diff) is the best way to store this kind of information. -- Alexandre Julliard julliard(a)winehq.com

Sept. 21, 2001