September 2001 - Wine-Devel

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