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

Re: wsprintf

by Aric Stewart

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. -aric Andreas Mohr wrote: > > On Thu, Sep 20, 2001 at 01:38:11PM -0500, Aric Stewart wrote: > > The behavior for wsprintfA is different that for wsprintf16 in how it > > handles NULLs being passed as character parameters. This patch fixes > > that. > Hmm, can't you add a small comment inside the code that actually mentions > this remarkable difference ? > I think we should make every effort possible to ensure that important > differences between architectures are being preserved as well as possible. > > -- > Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

Sept. 21, 2001

Re: Better font charset handling

by Huw D M Davies

On Fri, Sep 21, 2001 at 03:46:29PM +0200, Nerijus Baliunas wrote: > On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > > HDMD> Huw D M Davies <hdavies(a)codeweavers.com> > HDMD> Use the font charset to obtain a codepage for A->W conversion in the > HDMD> text functions. > > HDMD> Index: objects/text.c > > HDMD> + case VISCII_CHARSET: > HDMD> + case TCVN_CHARSET: > HDMD> + case KOI8_CHARSET: > HDMD> + case ISO3_CHARSET: > HDMD> + case ISO4_CHARSET: > HDMD> + case ISO10_CHARSET: > HDMD> + case CELTIC_CHARSET: > HDMD> + /* FIXME: These have no place here, but becasue x11drv > HDMD> + enumerates fonts with these (made up) charsets some apps > HDMD> + might use them and then the FIXME below would become > HDMD> + annoying. Now we could pick the intended codepage for > HDMD> + each of these, but since it's broken anyway we'll just > HDMD> + use CP_ACP and hope it'll go away... > HDMD> + */ > HDMD> + cp = CP_ACP; > HDMD> + break; > > Why these are here? Because they do not have windows equivalents? > If so, at least KOI8 shouldn't be there (IMHO). AFAIK they're not Windows charsets, somebody has made up some numbers and added them to wingdi.h . The reason they're here at all is because the x11drv enumerates fonts with these charsets and I'm claiming that this is a bug, since no application can be expected to know that these numbers mean. Now there is a RUSSIAN_CHARSET and this gets handled by the TranslateCharsetInfo before the switch. Huw.

Sept. 21, 2001

Re: Better font charset handling

by Nerijus Baliunas

On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: HDMD> Huw D M Davies <hdavies(a)codeweavers.com> HDMD> Use the font charset to obtain a codepage for A->W conversion in the HDMD> text functions. HDMD> Index: objects/text.c HDMD> + case VISCII_CHARSET: HDMD> + case TCVN_CHARSET: HDMD> + case KOI8_CHARSET: HDMD> + case ISO3_CHARSET: HDMD> + case ISO4_CHARSET: HDMD> + case ISO10_CHARSET: HDMD> + case CELTIC_CHARSET: HDMD> + /* FIXME: These have no place here, but becasue x11drv HDMD> + enumerates fonts with these (made up) charsets some apps HDMD> + might use them and then the FIXME below would become HDMD> + annoying. Now we could pick the intended codepage for HDMD> + each of these, but since it's broken anyway we'll just HDMD> + use CP_ACP and hope it'll go away... HDMD> + */ HDMD> + cp = CP_ACP; HDMD> + break; Why these are here? Because they do not have windows equivalents? If so, at least KOI8 shouldn't be there (IMHO). HDMD> + default: HDMD> + FIXME("Can't find codepage for charset %d\n", lf.lfCharSet); HDMD> + break; Regards, Nerijus

Sept. 21, 2001

Re: winsock socket.c patch fixes issues with halflife's multicasting

by Francois Gouget

On 21 Sep 2001, David Hammerton wrote: > it seems there we're a few (bugs/typos) in dlls/winsock/socket.c which > prevented binding of ports when using multicast, or something along those > lines. > heres a small patch which fixes it. Please, user -u when you do a diff: * it makes it easier to see what the patch changes * it makes it easier to find the location you changed in the file. None of my copies of socket.c match yours so all the line offsets are off * it is more robust if you want to apply the patch to a modified version of the file (translation Unified diff formats actually have a chance to apply properly, yours does not) So I suggest you put the following line in your .cvsrc: diff -u All this is also explained there: Wine Developper's Guide: "Submitting Patches" http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT That said I must appologize: I am the one who broke this piece of code. A very bad case of copy/paste. Sincere appologies. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Sept. 21, 2001

re-implementing real mode interrupts

by Mike McCormack

Hi, I was wondering if it would be a Good Thing to start re-implementing real mode interrupts using Win32 calls. 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. This would better seperate the DOS and Win32 implementations. Any thoughts? Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Sept. 21, 2001

Re: Implementation of SPI_GETSHOWSOUNDS action in SystemParametersInfo

by Gerard Patel

At 02:34 PM 20/09/2001 -0400, you (Andriy Palamarchuk <apa3a(a)yahoo.com>) wrote: >File: windows/sysparams.c <snip> use diff -u See: http://www.winehq.com/dev.shtml (section : patches) Gerard

Sept. 20, 2001

Re: min/max and types

by John Alvord

On Thu, 20 Sep 2001 21:03:20 +0200, eric pouech <eric.pouech(a)wanadoo.fr> wrote: >(resent because of mail issues) > >still thinking about it, there is however some points I don't like (and >especially for keeping it permanent) >errors we want to catch are mainly related to sign mismatch >(like min(char, unsigned short)...) > >however, comparaisons like min(short, int) or min(size_t, DWORD) don't >provide lots of errors. integral promotions are straightforward, and >behave as expected by any programmer. so it would be rather ugly IMO >to write something like min((int)s, i) (s being short and i int) > >on the other hand, in the case of min(char, unsigned short), only >experienced programmers are able to tell the order of integral >promotions >involved here, and we really do need some guidance here. unfortunately, >I don't see any ways not to let the min/max macro only spit errors on >integral type of same sign-ness Another argument in the L-K debate was that precisely the same problem exists when comparing variables... and comparisons are much more common then min/max. One person suggested a LE/GT/etc set of #defines to capture those errors. Not an easy job. john

Sept. 20, 2001

Re: wsprintf

by Andreas Mohr

On Thu, Sep 20, 2001 at 01:38:11PM -0500, Aric Stewart wrote: > The behavior for wsprintfA is different that for wsprintf16 in how it > handles NULLs being passed as character parameters. This patch fixes > that. Hmm, can't you add a small comment inside the code that actually mentions this remarkable difference ? I think we should make every effort possible to ensure that important differences between architectures are being preserved as well as possible. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

Sept. 20, 2001

Re: min/max and types

by eric pouech

(resent because of mail issues) still thinking about it, there is however some points I don't like (and especially for keeping it permanent) errors we want to catch are mainly related to sign mismatch (like min(char, unsigned short)...) however, comparaisons like min(short, int) or min(size_t, DWORD) don't provide lots of errors. integral promotions are straightforward, and behave as expected by any programmer. so it would be rather ugly IMO to write something like min((int)s, i) (s being short and i int) on the other hand, in the case of min(char, unsigned short), only experienced programmers are able to tell the order of integral promotions involved here, and we really do need some guidance here. unfortunately, I don't see any ways not to let the min/max macro only spit errors on integral type of same sign-ness A+-- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 20, 2001

GetSystemMetrics / SetSystemMetrics ?

by Andriy Palamarchuk

Question: How to update metrics data returned by GetSystemMetrics function? Problem: Currently I'm implementing some easiest FIXMEs (e.g. SPI_GETSHOWSOUNDS) in function SystemParametersInfo. GetSystemMetrics is used to return information for a few types of SPI_GETxxx actions from this function, including the action I'm working on. Logic for corresponding SPI_SETxxx actions is not implemented and contains commented out calls to SetSystemMetrics. As I understand this comment is a mark that corresponding GetSystemMetrics data should be updated in this place. GetSystemMetrics returns data from array sysMetrics. I did not find any function which provides update access to the array. Can you advise how to deal with this problem? Regards, Andriy Palamarchuk

Sept. 20, 2001

Re: Quicktime 5.0.x / XVideo usage

by Matthias Dahl

On Fri, Sep 14, 2001 at 09:57:46AM +0200, Marcus Meissner wrote: [... WINE DIRECT DRAW BUILTIN SUPPORT ...] > It works better with my patch, thats why I did it ;) Strange. The builtin support just causes trouble here - and is way too slow. Even though the picture quality is somewhat better with it. *sigh* > No. If you use ddraw=n it will (I think) not use DDRAW, but fall back to use > DIB Sections. Right. And that results in windows-like performance - with the known problems I have stated earlier. > Builtin. The native version of DDRAW does not work to my knowledge. The native support works - at least with DirectX 7.0a. Yet in my case the best solution is turn them both off. *pondering* I will try a new CVS checkout and see if the problem still occurs. If it does, I hope (if you don't mind) we could try to track it down. What do you say? -- So long, Matt ]) matthew2k(a)web.de, GPG key available at public keyservers ([

Sept. 20, 2001

[Problem report] SetWindowWord creates infinite loop

by Gerard Patel

The following change in SetWindowWord + + WIN_ReleaseWndPtr(wndPtr); + switch(offset) { - case GWW_ID: ptr = (WORD *)&wndPtr->wIDmenu; break; - case GWW_HINSTANCE: ptr = (WORD *)&wndPtr->hInstance; break; - case GWW_HWNDPARENT: retval = SetParent( hwnd, newval ); - goto end; - default: - WARN("Invalid offset %d\n", offset ); - retval = 0; - goto end; + case GWL_ID: + case GWL_HINSTANCE: + case GWL_HWNDPARENT: + return SetWindowLongW( hwnd, offset, (UINT)newval ); + default: + WARN("Invalid offset %d\n", offset ); + return 0; } creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, that calls SetWindowWord for the GWL_HINSTANCE case. Gerard

Sept. 20, 2001

Re: [Problem report] SetWindowWord creates infinite loop

by Alexandre Julliard

Gerard Patel <gerard.patel(a)nerim.net> writes: > The following change in SetWindowWord > [...] > creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, > that calls SetWindowWord for the GWL_HINSTANCE case. Oops, sorry about that. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

Sept. 19, 2001

Re: min/max and types

by Eric Pouech

> > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > > provide lots of errors. integral promotions are straightforward, and > > behave as expected by any programmer. so it would be rather ugly IMO > > to write something like min((int)s, i) (s being short and i int) > > But in this last example, wouldn't it be better to declare s as an > int or i as a short? Then we would not need a cast. > I believe we would rarely be forced to really compare integers of > different sizes. Of course the only way to be sure is to really look at > the actual warnings... well, the warnings I looked at come of three kinds (for that's for from being exhaustive): - comparing the dwSize of a struct with the sizeof of the struct. The first being a DWORD, the second of type size_t. Using the macro means using a cast here, which I find rather ugly - comparing an unsigned int with an explicit integer : min(4, u). This could be rewritten easily into min(4u, u) for example - real potential problems with comparing unsigned char with signed short for example. IMO, the first two ones shouldn't require type casts. last but not least, I think that the basic issue here is that gcc should report a sign mismatch in the comparison... and it doesn't. If it did, we wouldn't be arguing on the matter... A+ > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. > > > > --------------- 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. 19, 2001

Re: min/max and types

by Francois Gouget

On Tue, 18 Sep 2001, eric pouech wrote: [...] > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > provide lots of errors. integral promotions are straightforward, and > behave as expected by any programmer. so it would be rather ugly IMO > to write something like min((int)s, i) (s being short and i int) But in this last example, wouldn't it be better to declare s as an int or i as a short? Then we would not need a cast. I believe we would rarely be forced to really compare integers of different sizes. Of course the only way to be sure is to really look at the actual warnings... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Sept. 18, 2001

Re: DDE and postmessage

by eric pouech

Alexandre Julliard wrote: > > eric pouech <eric.pouech(a)wanadoo.fr> writes: > > > I've started looking at the inter-process DDE message management > > as of today, PostMessage doesn't use the packing strategy used by > > SendMessage (rightfully because of possible dangling pointer issue > > if pointers are used in message parameters) > > > > however, some DDE messages need to send additional information > > even when posting (copying all data), and DDE protocol requires > > posting messages (SendMessage is banned) > > > > do you have any plan to handle this ? > > I don't really have any plan yet. We clearly need to do a special case > for posted DDE messages; a possibility would be to use an internal > message with SendMessage to send the data across before posting the > actual DDE message. There is an undocumented message similar to > WM_COPYDATA that can be used to transfer a global memory block across > processes, which is used for stuff like WM_DROPFILES; it doesn't work > right now but I'm planning to implement it soon. This would add a > synchronisation point that may defeat the purpose of the PostMessage > though. If this is a problem we can probably add a DDE-specific server > call to transfer the data what I had in mind was somehow reusing the message packing capabilities of SendMessage for PostMessage. Moreover, we need to handle large memory chunks to be exchanged in SendMessage, so we could kill two birds with one stone. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 18, 2001

Re: Dialog painting

by Niclas Karlsson MATE

On Mon, Sep 17, 2001 at 11:33:03PM +0000, Gerard Patel wrote: > Your code does not display anything because no message > is retrieved from the message queue. After the Sleep call, > WM_PAINT messages are available, but as you don't > retrieve them by calling PeekMessage or something > like that, nothing is shown. Ok, I see. I actually did compare the messages sent in windows to those sent in wine and then I noticed, among other things, that no WM_PAINT messages were received in this case. > I don't want to say that your app code is wrong, of course. It may very well be, but it works with real windows and some apps use constructs like this (and exhibit the same problems in wine). > There is a problem in Wine, but I don't know what to do > about it. My first thought would be to scan the X queue > and retrieve the expose events as was done before the > great changes of this summer, but this may be somewhat > difficult to do right. Well, the window needs to be painted during the first call to CreateDialog() - how to fix it is another matter. My naive idea would be to just set the invalid region manually and/or to send a WM_PAINT. Fetching expose events may also be a good idea, but I know very little about the interaction between Wine and X so I can't really say whether that is a good or a bad idea. > I prefer to waste my time searching for other problems, > because I have no doubt that Alexandre Julliard is > aware of this one and it's clear that he is not finished > yet with X code reorganization. Ok, thanks for clueing me in. Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

Sept. 18, 2001

Re: Dialog painting

by Gerard Patel

At 12:35 AM 11/09/2001 +0300, you wrote: > >I took a closer look at this. I just ripped out the interesting parts >from Speak freely in order to find a simple program exhibiting the >problems. What I ended up with was a program which does nothing >interesting except to show a simple dialg using CreateDialog(). It >still doesn't work under Wine. The source is attached. I have looked at your source. With current Wine, expose X events are retrieved from the X server when Wine has nothing else to do. These events are setting the update region. CreateWindow does not set the update region in current Wine, even if the window is visible. This is the point that matters for your problem I think. hSplash = CreateDialog (hInstance, MAKEINTRESOURCE(IDD_SPLASH), NULL, Splash_DlgProc); SetForegroundWindow(hSplash); // here the update region is nil (Wine problem !) UpdateWindow(hSplash); // --> nothing is displayed. Sleep(5000); // events are retrieved from the X server queue. printf("Removing splash.\n"); DestroyWindow(hSplash); Your code does not display anything because no message is retrieved from the message queue. After the Sleep call, WM_PAINT messages are available, but as you don't retrieve them by calling PeekMessage or something like that, nothing is shown. I don't want to say that your app code is wrong, of course. There is a problem in Wine, but I don't know what to do about it. My first thought would be to scan the X queue and retrieve the expose events as was done before the great changes of this summer, but this may be somewhat difficult to do right. I prefer to waste my time searching for other problems, because I have no doubt that Alexandre Julliard is aware of this one and it's clear that he is not finished yet with X code reorganization. Gerard

Sept. 17, 2001

RE: dlls/advapi32/crypt.c

by Patrik Stridvall

> Vladimir Vukicevic <vladimir(a)ximian.com> writes: > > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > > necessary -- there's no reason why two implementations of CryptoAPI > > can't be done, one using the gcrypt backend, one using OpenSSL. > > Granted, this is a duplication of effort, but I think there > is enough > > interest that it shouldn't be too difficult to do both. > Also, it's easy > > enough to ship two different advapi32.so's, or even create an > > intermediate cryptoapi layer that supports plugins, so that > the option > > always remains with the distributor or user whether to go with a GPL > > implementation, a BSD implementation, or even a commercial > > implementation. > > As far as the main tree is concerned, everything has to be under the > Wine license (or compatible). It's not acceptable to depend on a > library that would impose extra conditions on the Wine/Winelib > user. The problem is what constitutes extra conditions is extremly vague. If you have a Winelib application that don't for example use say any crypto functions, you really can't be said either to use or to derive a new work from a completely unused and/or unnessary library. If you do use any crypto function, well, whether that imposes any extra conditions is an extremely difficult legal issue that really can't be answered without a real court case. It might depend on whether the use is optional but it might not. That is what I have been trying to point out in my recent messages. So just saying that "I don't want any libraries that imposed extra conditions on the Wine/Winelib user" is not really a very informative answer. What you mean is (I guess): 1. No use of libraries under the GPL or other viral licenses 2. No use of commersial libraries (end user and/or developer must pay for it) Or do you mean something else? Anyway see below. > And this is not solved by having a choice between two different > sets of extra conditions. Note that you always have the choice of NOT using crypto. If Wine didn't include a working crypto implementation that would be the only choice wouldn't it? As long as it doesn't effect the performance or maintainabillity of Wine in negative way more choices are always better than less IMHO.

Sept. 17, 2001

Monkey Island 3 install

by Johan Gill

After some testing, I've found that the installation of Curse of Monkey Island works fine if winver=win98 is specified. What made the win95 install break was this: --- /opt/cvs-commit/wine/misc/version.c 2001/07/02 19:59:49 1.43 +++ /opt/cvs-commit/wine/misc/version.c 2001/07/27 23:57:38 1.44 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, If that is a correct fix, the real problem is to be found somewhere else. /Johan Gill, johane(a)lysator.liu.se

Sept. 17, 2001

RE: dlls/advapi32/crypt.c

by Patrik Stridvall

> On Sat, 2001-09-15 at 02:12, Patrik Stridvall wrote: > > In short. GPL:ed Winelib applications is not our concern > > and we shouldn't IMHO make it one beyond making sure > > that all linking to non GPL compatible libraries is optional. > > > > GPL:ed libraries is, as said above, a different story, that > > from a legal point of view is an unresolved issue. The "answer" > > of that question regardless of what it will be, will, be very > > important since it might, unless it is too vague, define the > > boundaries of copyright in a more definite way. > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > necessary -- there's no reason why two implementations of CryptoAPI > can't be done, one using the gcrypt backend, one using OpenSSL. > Granted, this is a duplication of effort, but I think there is enough > interest that it shouldn't be too difficult to do both. > Also, it's easy > enough to ship two different advapi32.so's, or even create an > intermediate cryptoapi layer that supports plugins, so that the option > always remains with the distributor or user whether to go with a GPL > implementation, a BSD implementation, or even a commercial > implementation. It is not the effort that is the real problem. The problem is that since ADVAPI32 might use libgcrypt (that is GPL:ed library) it possible to for a non-GPL:ed Winelib application to indirectly via the ADVAPI to "link" to libgrypt. This would violate the GPL:ed in some meaning. Of course the authors of the Winelib application might be entirely unaware of this fact but it is still teoretical violation. This is, of course, in some meaning absurd, but ask yourself this: What meaning have the GPL for libraries if you can just wrap a intermediate library with a GPL compatible license (like Winelib:s ADVAPI "library") around it and circumvent the GPL? Of course a distinct possibility exists that a court of law will find that the GPL (as applied to libraries) is meaningless or at least meaningless in the case of Wine. But are you willing to be the defendent in a test case? Alexandre is not. Still IMHO even in the worst case what will likely happend is that. 1. Richard Stallman (or somebody else) sends a GPL violation notice. 2. Slashdot debate the case and possibly hang us out. :-) 3. We will discuss on the list what to do and possible remove the offending code. 4. If we do not the debate on Slashdot and elsewhere will continue 5. If we still persist the chances that we will be sued is still quite small since A) The cases of winning is close to zero B) There is little or no chance to profit even regardless of this. Of course there is moral aspect of this but ask yourself this: "Is it immoral to shatter somebodies unrealistic expectations?" In short there is no legal risk at all IMHO but Alexandre has said earlier that he doesn't want code using GPL:ed libraries if not to protect himself or the Wine project, so to protect possible users of Wine if not from legal issues so from bad PR. > There's also something to be said for following Microsoft's API for > crypto back-ends, so that proprietary back-ends (i.e. those > dealing with > hardware keys, etc.) could function within the wine cryptoapi > framework. > In this case, each individual provider (RSA, DSS, etc.) would then be > implemented either in terms of gcrypt, or OpenSSL, or libcrypt, or any > other. That is probably a good idea. But you can't use libgcrypt at least not without asking the libgcrypt authors if it is OK that Wine(lib) uses libgcrypt despite the fact that it makes it possible for non-GPL:ed Winelib applications to indirectly use libgcrypt. And you better ask Alexandre whether is OK with him to include the code under such circumstances.

Sept. 17, 2001

RE: dlls/advapi32/crypt.c

by Vladimir Vukicevic

On Sat, 2001-09-15 at 02:12, Patrik Stridvall wrote: > In short. GPL:ed Winelib applications is not our concern > and we shouldn't IMHO make it one beyond making sure > that all linking to non GPL compatible libraries is optional. > > GPL:ed libraries is, as said above, a different story, that > from a legal point of view is an unresolved issue. The "answer" > of that question regardless of what it will be, will, be very > important since it might, unless it is too vague, define the > boundaries of copyright in a more definite way. I think that the discussion of OpenSSL vs. libgcrypt isn't really necessary -- there's no reason why two implementations of CryptoAPI can't be done, one using the gcrypt backend, one using OpenSSL. Granted, this is a duplication of effort, but I think there is enough interest that it shouldn't be too difficult to do both. Also, it's easy enough to ship two different advapi32.so's, or even create an intermediate cryptoapi layer that supports plugins, so that the option always remains with the distributor or user whether to go with a GPL implementation, a BSD implementation, or even a commercial implementation. There's also something to be said for following Microsoft's API for crypto back-ends, so that proprietary back-ends (i.e. those dealing with hardware keys, etc.) could function within the wine cryptoapi framework. In this case, each individual provider (RSA, DSS, etc.) would then be implemented either in terms of gcrypt, or OpenSSL, or libcrypt, or any other. - Vlad

Sept. 17, 2001

DDE and postmessage

by eric pouech

(mainly for Alexandre) I've started looking at the inter-process DDE message management as of today, PostMessage doesn't use the packing strategy used by SendMessage (rightfully because of possible dangling pointer issue if pointers are used in message parameters) however, some DDE messages need to send additional information even when posting (copying all data), and DDE protocol requires posting messages (SendMessage is banned) do you have any plan to handle this ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 16, 2001

Re: dlls/advapi32/crypt.c

by Ove Kaaven

On Sat, 15 Sep 2001, Travis Michielsen wrote: > On September 14, 2001 9:40 pm, Dan Kegel wrote: > > Gavriel State wrote: > > > That said on the licensing side, I have no idea whether the > > > OpenSSL code actually provides the functionality we need to > > > implement the CryptoAPIs. Has anyone looked into this yet? > > > > > > The other alternative is to ask the libgcrypt team if they > > > are willing to consider LGPL-ing their library so that we > > > can use it. Has anyone asked? > > > > FWIW, Peter Gutmann (author of another SSL API, > > http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ), > > > > says wine is welcome to use his code: > >... > > Hmm, I was unaware of that project. I asume that you have already contacted > the author and has his approval at least for the wine project. But have you > also clarified the situation with winelib applications both GPL and > otherwise? I just want to clarify this as this seems to be the main area of > concern. I have briefly visited the site and the API seems to support > everything we need and I will consider using it. However, I did not find a > license on the site. There seems to be some conditions if you click "downloading". Alas, those usage conditions on the site doesn't even come close to conforming with something like the Debian Free Software Guidelines, much less the GPL...

Sept. 16, 2001

Re: dlls/advapi32/crypt.c

by Travis Michielsen

On September 14, 2001 9:40 pm, Dan Kegel wrote: > Gavriel State wrote: > > That said on the licensing side, I have no idea whether the > > OpenSSL code actually provides the functionality we need to > > implement the CryptoAPIs. Has anyone looked into this yet? > > > > The other alternative is to ask the libgcrypt team if they > > are willing to consider LGPL-ing their library so that we > > can use it. Has anyone asked? > > FWIW, Peter Gutmann (author of another SSL API, > http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ), > > says wine is welcome to use his code: >... Hmm, I was unaware of that project. I asume that you have already contacted the author and has his approval at least for the wine project. But have you also clarified the situation with winelib applications both GPL and otherwise? I just want to clarify this as this seems to be the main area of concern. I have briefly visited the site and the API seems to support everything we need and I will consider using it. However, I did not find a license on the site. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Sept. 15, 2001

RE: dlls/advapi32/crypt.c

by Patrik Stridvall

> Patrik Stridvall wrote: > > > > > On another note, however, I was re-reading the CryptoAPI > > > thread and I don't > > > think that Vladimir Vukicevic's questions were really > > > answered from September > > > 3rd. > > > > Can you be a little more specific? > > > > As far using GPL:ed libraries, that is a question that > > really can't be properly answered without a real court > > case. > > I think that Vladimir's suggestion that OpenSSL could be > used as an alternative back end did not recieve sufficient > attention. He wasn't sure that that was a good approach > given the fact that it would arguably cause difficulty for > people who wanted to run GPLed apps on top of Wine+OpenSSL. Well. If we only permit linking with libraries that have GPL compatible licenses, we will seriously limit our choices. Sure I, since GPL is a dominant license, fully agree that all linking to non-GPL:ed libraries should be optional. Of course the question of what is optional is vague too. See below. Also note that this is an entirely different issue than the issues concerning GPL:ed libraries. In the case above it is 100% clear that only the distributor of the GPL:ed application can have any legal liabillities for possible violation of the GPL. It is not out immediate concern. Beside since they, because of the GPL, must have the source code they can always disable things like crypto that might not have a 100% GPL compatible Winelib implementation. In short. GPL:ed Winelib applications is not our concern and we shouldn't IMHO make it one beyond making sure that all linking to non GPL compatible libraries is optional. GPL:ed libraries is, as said above, a different story, that from a legal point of view is an unresolved issue. The "answer" of that question regardless of what it will be, will, be very important since it might, unless it is too vague, define the boundaries of copyright in a more definite way. However, I'm a little afraid of that for the GPL to be truely meaningful, especially in the case of Wine, you will have define the boundaries of copyright a little to strict for my liking. > Since the number of GPLed Windows apps that do not have Linux > counterparts is vanishingly small, the OpenSSL option seems to > me more appropriate than using a libgcrypt back end. The > OpenSSL license does not have the viral properties that the > GPL has (it's an old-style BSD-type license, complete with the > advertising clause), and therefore we should be able to weak-link > Wine with libOpenSSL without any license contamination. Agreed. > Packagers > who distribute libOpenSSL with Wine would then be responsible > for meeting the OpenSSL license requirements for advertising > and attribution. Of course but that is not our immediate concern, the same would be if we link with any proprietary library. Any distributor of such libraries whether in conjuction with Wine(lib) or seperately must of course fullfull the licensing requirements of such libraries (including but not limited to pay any license fees). Actually in some meaning we already do, since proprietary implemenatations of both X Windows and OpenGL exists and Wine(lib) will happily dynamically link with them and use them if they exists. Wine(lib):s use of them obviously do not gives any license to distribute them, but that is not our concern. This of course raises they question if we mandatorily link to libraries, like X Windows or OpenGL, that both have GPL and non-GPL compatible implemtations: Do we optionally or mandatorily link to a non GPL compatible library? Does this matter from a legal perspetive as concerning whether a Winelib user violate the GPL or not? In addition does it matter whether the GPL compatible library is: 1. Complete 2. Close to complete 3. Has only basic functionallity 4. Unusably buggy 5. Unimplemented stubs 6. In the planing state 7. A theoretical construction In that case why?

Sept. 15, 2001

Re: min/max and types

by eric pouech

> * removed the undefs and using the same #ifndef for both well, I added the undefs to be sure that we wouldn't be using any min/max def:s lying in a libc header which might be included before windef.h removing the const might also be a good idea when we use min/max on pointers and not simply int:s A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 15, 2001

Re: min/max and types

by Francois Gouget

On Fri, 14 Sep 2001, eric pouech wrote: > just for fun, I tried compiling Wine with Linux latest min/max macros > definitions I think it's an excellent idea. But there are some problems with their macros: we have duplicate consts :-( Example in controls/edit.c:1575 *x = min(max(*x, es->format_rect.left), es->format_rect.right-1); *y = min(max(*y, es->format_rect.top), es->format_rect.bottom-1); edit.c: In function `EDIT_ConfinePoint': edit.c:1575: warning: duplicate `const' edit.c:1576: warning: duplicate `const' Still I think it would be a good idea to put them in windef.h on a more permanent basis. What about the attached patch? * removed the consts * added a WINE_MINMAX for WineLibe applications that would want to use this feature * removed the undefs and using the same #ifndef for both How does all this sound? PS: Alternately we may be able to keep the consts if we cast the result to typeof(x) (or y). Because in the above case it is because max returns a 'const int' instead of an int that we have a problem. 'const ints' are pretty rare otherwise (I think). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Sept. 15, 2001

Re: dlls/advapi32/crypt.c

by Dan Kegel

Gavriel State wrote: > That said on the licensing side, I have no idea whether the > OpenSSL code actually provides the functionality we need to > implement the CryptoAPIs. Has anyone looked into this yet? > > The other alternative is to ask the libgcrypt team if they > are willing to consider LGPL-ing their library so that we > can use it. Has anyone asked? FWIW, Peter Gutmann (author of another SSL API, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ), says wine is welcome to use his code: > Dan Kegel wrote: > >On an unrelated note, a couple people on wine-devel are thinking of > >implementing support for Microsoft's CryptoAPI in Wine (hopefully based on an > >existing crypto library, if one can be found that is suitable, license-wise). > >Any wisdom you could throw their way would probably be appreciated. > > Euurgghh, that'd be like implementing RPC over SMB support for... oh hang on, > that's already been done :-). The two problems are (1) it's a pretty awful > design (and I'm using the word "design" loosely here, accretion might be a > better word) and (2) it's a great pile of semi-documented, uncontrolled > functions, structures, constants... hmm, it really is like RPC over SMB. > > Anyway, if you do want to implement it you're welcome to use cryptlib for it > (you can use it for Wine under whatever terms Wine requires), cryptlib has an > API-mapping layer (look at cryptapi.c) which maps any API to the native > cryptlib functions (a bit like the Win32 vs NT native API) so by unplugging > cryptapi.c and plugging in a CryptoAPI-compatible interface you should be able > to do a lot of what you want - there's support for certificate stores and all > the usual stuff which CryptoAPI needs in there. > > (As the above may indicate, I've looked at doing this a bit myself, but > couldn't really work up much enthusiasm for it). > > Peter. - Dan

Sept. 15, 2001

Winsock API

by Robert Lunnon

I have Converted WSAIOCTL to use SIOCGETIFCONF ioctl calls rather than parse /proc which is to linux-centric but I was asked by Francois Gouget to look at trying to make WsControl unix independent by implementing it using other windows APIs rather than by using unix calls directly. Unfortunately this API is a bit of a mess because WsControl can return the MAC Adress but WSAIoctl doesn't appear to implement that functionality. To get The MAC Address we then need to make an appropriate UNIX IOCTL call for which we need the interface name, which isn't available from WSAIoctl either. There are other ways in windows to getthe MAC address via an SNMP call but I'm not sure how that is implemented (Possibly with a call back to WSControl) I don't see then how WSControl can be implemented without the present hacks and duplicated code between WSAIoclt and WSControl helper functions. My proposal then would be... 1.) Separate out all the unix centric helper functions for WSControl and WSAIoctl into a common ancestor source file with no windows dependencies. This should remove the ugly socket hack in WSControl, both libraries still end up with private copies of the common helper functions but since they are all derived from the same common source file it will at least be encapsulated and easier to maintain. 2.) The doco for WSIoctl indicate the encoding for the Ioctl op-code allows for a "Standard" unix IOCTL to be passed to WSIoctl ostensibly for FIONREAD,FIONBIO et al, with predictable results. If I were to implement SIOCGETIFCONF in WsIoctl then this would allow a pass-through so I could get what I need from the host OS without disturbing current windows programs. Because windows doesn't define SIOCGETIFCONF whatever we choose for the value of the op-code might end up being used by Microsoft later, breaking Wine. (Possible but not very likely) Opinions ?

Sept. 15, 2001

Re: dlls/advapi32/crypt.c

by Gavriel State

Patrik Stridvall wrote: > > > On another note, however, I was re-reading the CryptoAPI > > thread and I don't > > think that Vladimir Vukicevic's questions were really > > answered from September > > 3rd. > > Can you be a little more specific? > > As far using GPL:ed libraries, that is a question that > really can't be properly answered without a real court > case. I think that Vladimir's suggestion that OpenSSL could be used as an alternative back end did not recieve sufficient attention. He wasn't sure that that was a good approach given the fact that it would arguably cause difficulty for people who wanted to run GPLed apps on top of Wine+OpenSSL. Since the number of GPLed Windows apps that do not have Linux counterparts is vanishingly small, the OpenSSL option seems to me more appropriate than using a libgcrypt back end. The OpenSSL license does not have the viral properties that the GPL has (it's an old-style BSD-type license, complete with the advertising clause), and therefore we should be able to weak-link Wine with libOpenSSL without any license contamination. Packagers who distribute libOpenSSL with Wine would then be responsible for meeting the OpenSSL license requirements for advertising and attribution. That said on the licensing side, I have no idea whether the OpenSSL code actually provides the functionality we need to implement the CryptoAPIs. Has anyone looked into this yet? The other alternative is to ask the libgcrypt team if they are willing to consider LGPL-ing their library so that we can use it. Has anyone asked? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Sept. 15, 2001

Re: Information Request For Porting WINE

by Dan Kegel

Lucien LaCroix wrote: > > I would like to find out if the development of WINE supports it being ported > to Windows 16-Bit OS. No. Wine runs on Posix operating systems. It is an implementation of Windows on top of Posix. - Dan

Sept. 15, 2001

Information Request For Porting WINE

by Lucien LaCroix

I would like to find out if the development of WINE supports it being ported to Windows 16-Bit OS. Currently, I am developing a Windows Clone and would very much ike to work on Porting WINE to Win16. However, I am not 100% sure if the way WINE operates wether it would work. WINE will work if it is a complete re-written library system that merely interfaces with the host system. WINE won't work if it serves as a translater from host system system calls to the guest application. Any information on this plus a good compiler that is usefull for someone who knows a bit, but not everything, hopefully one with a good GUI. Thank-You. David Scherer, lacroixlucien(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Sept. 15, 2001

min/max and types

by eric pouech

just for fun, I tried compiling Wine with Linux latest min/max macros definitions Index: include/windef.h =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/include/windef.h,v retrieving revision 1.58 diff -u -r1.58 windef.h --- include/windef.h 2001/07/30 18:57:18 1.58 +++ include/windef.h 2001/09/14 18:06:53 @@ -133,6 +133,27 @@ #define min(a,b) (((a) < (b)) ? (a) : (b)) #endif #endif /* NOMINMAX */ +#if defined(__WINE__) && defined(__GNUC__) +#undef max +#undef min +#define min(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x < _y ? _x : _y; \ + }) + +#define max(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x > _y ? _x : _y; \ + }) +#endif #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ here's the output (the list of types mismatches in min/max calls...) to whomever feels like fixing them (if needed) registry.c:386: warning: comparison of distinct pointer types lacks a cast registry.c:1246: warning: comparison of distinct pointer types lacks a cast trace.c:69: warning: comparison of distinct pointer types lacks a cast trace.c:147: warning: comparison of distinct pointer types lacks a cast reg.c:177: warning: comparison of distinct pointer types lacks a cast reg.c:195: warning: comparison of distinct pointer types lacks a cast reg.c:209: warning: comparison of distinct pointer types lacks a cast reg.c:224: warning: comparison of distinct pointer types lacks a cast reg.c:232: warning: comparison of distinct pointer types lacks a cast reg.c:306: warning: comparison of distinct pointer types lacks a cast reg.c:318: warning: comparison of distinct pointer types lacks a cast reg.c:328: warning: comparison of distinct pointer types lacks a cast reg.c:379: warning: comparison of distinct pointer types lacks a cast reg.c:416: warning: comparison of distinct pointer types lacks a cast reg.c:496: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2201: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2202: warning: comparison of distinct pointer types lacks a cast drive.c:926: warning: comparison of distinct pointer types lacks a cast file.c:1884: warning: comparison of distinct pointer types lacks a cast profile.c:120: warning: comparison of distinct pointer types lacks a cast module.c:1644: warning: comparison of distinct pointer types lacks a cast module.c:1645: warning: comparison of distinct pointer types lacks a cast heap.c:645: warning: comparison of distinct pointer types lacks a cast local.c:401: warning: comparison of distinct pointer types lacks a cast local.c:891: warning: comparison of distinct pointer types lacks a cast registry.c:507: warning: comparison of distinct pointer types lacks a cast version.c:477: warning: comparison of distinct pointer types lacks a cast int21.c:857: warning: comparison of distinct pointer types lacks a cast int21.c:861: warning: comparison of distinct pointer types lacks a cast ole2nls.c:435: warning: comparison of distinct pointer types lacks a cast process.c:1251: warning: comparison of distinct pointer types lacks a cast process.c:1276: warning: comparison of distinct pointer types lacks a cast process.c:1312: warning: comparison of distinct pointer types lacks a cast process.c:1345: warning: comparison of distinct pointer types lacks a cast console.c:170: warning: comparison of distinct pointer types lacks a cast console.c:429: warning: comparison of distinct pointer types lacks a cast console.c:982: warning: comparison of distinct pointer types lacks a cast console.c:984: warning: comparison of distinct pointer types lacks a cast console.c:1294: warning: comparison of distinct pointer types lacks a cast console.c:1345: warning: comparison of distinct pointer types lacks a cast registry.c:785: warning: comparison of distinct pointer types lacks a cast registry.c:1001: warning: comparison of distinct pointer types lacks a cast registry.c:1082: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:203: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:229: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:230: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:1702: warning: comparison of distinct pointer types lacks a cast dde/misc.c:1963: warning: comparison of distinct pointer types lacks a cast message.c:962: warning: comparison of distinct pointer types lacks a cast resource.c:320: warning: comparison of distinct pointer types lacks a cast resource.c:370: warning: comparison of distinct pointer types lacks a cast text.c:318: warning: comparison of distinct pointer types lacks a cast menu.c:847: warning: comparison of distinct pointer types lacks a cast menu.c:849: warning: comparison of distinct pointer types lacks a cast menu.c:917: warning: comparison of distinct pointer types lacks a cast menu.c:918: warning: comparison of distinct pointer types lacks a cast menu.c:931: warning: comparison of distinct pointer types lacks a cast cursoricon.c:519: warning: comparison of distinct pointer types lacks a cast timer.c:155: warning: comparison of distinct pointer types lacks a cast winpos.c:1811: warning: comparison of distinct pointer types lacks a cast winpos.c:1812: warning: comparison of distinct pointer types lacks a cast winproc.c:1755: warning: comparison of distinct pointer types lacks a cast winproc.c:1768: warning: comparison of distinct pointer types lacks a cast winproc.c:1901: warning: comparison of distinct pointer types lacks a cast winpos.c:1733: warning: comparison of distinct pointer types lacks a cast winpos.c:1734: warning: comparison of distinct pointer types lacks a cast winpos.c:1738: warning: comparison of distinct pointer types lacks a cast winpos.c:1739: warning: comparison of distinct pointer types lacks a cast winpos.c:1743: warning: comparison of distinct pointer types lacks a cast winpos.c:1744: warning: comparison of distinct pointer types lacks a cast winpos.c:1748: warning: comparison of distinct pointer types lacks a cast winpos.c:1749: warning: comparison of distinct pointer types lacks a cast winpos.c:1815: warning: comparison of distinct pointer types lacks a cast winpos.c:1816: warning: comparison of distinct pointer types lacks a cast winpos.c:1817: warning: comparison of distinct pointer types lacks a cast winpos.c:1818: warning: comparison of distinct pointer types lacks a cast xfont.c:3336: warning: comparison of distinct pointer types lacks a cast xfont.c:3339: warning: comparison of distinct pointer types lacks a cast lolvldrv.c:106: warning: comparison of distinct pointer types lacks a cast mmsystem.c:986: warning: comparison of distinct pointer types lacks a cast comboex.c:395: warning: comparison of distinct pointer types lacks a cast listview.c:723: warning: comparison of distinct pointer types lacks a cast listview.c:780: warning: comparison of distinct pointer types lacks a cast listview.c:3123: warning: comparison of distinct pointer types lacks a cast listview.c:7940: warning: comparison of distinct pointer types lacks a cast propsheet.c:145: warning: comparison of distinct pointer types lacks a cast propsheet.c:1998: warning: comparison of distinct pointer types lacks a cast rebar.c:1476: warning: comparison of distinct pointer types lacks a cast rebar.c:1490: warning: comparison of distinct pointer types lacks a cast tab.c:1080: warning: comparison of distinct pointer types lacks a cast toolbar.c:1086: warning: comparison of distinct pointer types lacks a cast treeview.c:1500: warning: comparison of distinct pointer types lacks a cast treeview.c:1594: warning: comparison of distinct pointer types lacks a cast treeview.c:2514: warning: comparison of distinct pointer types lacks a cast treeview.c:2516: warning: comparison of distinct pointer types lacks a cast treeview.c:4218: warning: comparison of distinct pointer types lacks a cast treeview.c:4351: warning: comparison of distinct pointer types lacks a cast treeview.c:4356: warning: comparison of distinct pointer types lacks a cast midi.c:117: warning: comparison of distinct pointer types lacks a cast audio.c:774: warning: comparison of distinct pointer types lacks a cast audio.c:1759: warning: comparison of distinct pointer types lacks a cast midi.c:618: warning: comparison of distinct pointer types lacks a cast midi.c:968: warning: comparison of distinct pointer types lacks a cast internet.c:489: warning: comparison of distinct pointer types lacks a cast -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Sept. 14, 2001

Re: Bug: loss of mousepointer

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > After last nights CVS commits, the Mousepointer appears not to be visible > in some applications in both managed and unmanaged mode. > > Reproducable for me with sol.exe and winmine.exe (16bit) for instance. This should fix it I think: Index: windows/nonclient.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/nonclient.c,v retrieving revision 1.84 diff -u -r1.84 nonclient.c --- windows/nonclient.c 2001/08/24 00:26:59 1.84 +++ windows/nonclient.c 2001/09/14 17:20:00 @@ -1729,7 +1729,8 @@ */ LONG NC_HandleSetCursor( HWND hwnd, WPARAM wParam, LPARAM lParam ) { - if (hwnd != (HWND)wParam) return 0; /* Don't set the cursor for child windows */ + if (hwnd != WIN_GetFullHandle( (HWND)wParam )) + return 0; /* Don't set the cursor for child windows */ switch(LOWORD(lParam)) { -- Alexandre Julliard julliard(a)winehq.com

Sept. 14, 2001

Re: IE 5.01

by Uwe Bonnes

>>>>> "Nick" == Nick Hudson <nhudson(a)hiwaay.net> writes: Nick> Greetings, Well i know ill get flamed for this but has anyone got Nick> IE 5.01 installed on wine? Everytime I try it gives me an error Nick> that "Some programs hasnt finished and that I need to let it Nick> finish and restart my computer" Then it closes. So any ideo on Nick> getting any version of IE installed? Delete the files mentioned in the wininit.ini file (in the windows directory) and then remove wininit.ini. 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. 14, 2001

IE 5.01

by Nick Hudson

Greetings, Well i know ill get flamed for this but has anyone got IE 5.01 installed on wine? Everytime I try it gives me an error that "Some programs hasnt finished and that I need to let it finish and restart my computer" Then it closes. So any ideo on getting any version of IE installed? Thanks Nick Hudson

Sept. 14, 2001

Re: GDI_CheckNotLock strikes again

by Huw D M Davies

On Fri, Sep 14, 2001 at 09:43:39AM +0900, Dmitry Timoshkov wrote: > "Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > > > Does this help? > > Yes, it does. But application (a heavily modified MS glyph sample > from 1993) doesn't show anything. I could send you the source code > if you are interested to fix it. It won't at the moment. Currently no driver in the cvs attempts to use gdi fonts, so the new code is never called. [working on it]. Huw.

Sept. 14, 2001

Re: Quicktime 5.0.x / XVideo usage

by Marcus Meissner

On Mon, Sep 10, 2001 at 08:36:13PM +0200, Matthias Dahl wrote: > On Mon, Sep 10, 2001 at 02:26:55PM +0200, Marcus Meissner wrote: > > > Please check if after the patch I sent Saturday, which restricts blting > > to actually used rectangles and gives a rather good speed up to QuickTime > > here. > I applied the patch but no change. The problem still occurs. Reminds me. Your > patch is mostly (or even entirely) for the Direct Draw stuff. But I have that > disabled here because the wine builtin support doesn't work too well for me. *sigh* It works better with my patch, thats why I did it ;) > With the builtin support enabled, the screen goes black as soon as I fire up > for example Quicktime. It looks like something draws black over the whole > screen because as soon as you cause X to redraw parts of the screen (by moving > a window for example), you can clean up everything and use the window like a > eraser. :-) Also the performance is really poor. :( Yes. DirectDraw was drawing over the whole screen for every frame displayed. With my patch it does the full screen blt only once now, all others are restricted to the area it actually changes. > Things work a bit better if I copy the necessary Direct stuff over to my fake > windows and let wine use native support. The black screen and such won't > happen. Yet I get the best performance if I disable direct draw entirely. And > if I open a window during quicktime playback (page setup for example) so that > both the "time slider" and the "audio analyzer bars" stop updating, I get the > same great performance like with a real windows system. Strange... No. If you use ddraw=n it will (I think) not use DDRAW, but fall back to use DIB Sections. > Are you using native or builtin direct draw? Does it work on your system? If > it does, I should start wondering what's wrong with my setup here I guess. Builtin. The native version of DDRAW does not work to my knowledge. Ciao, Marcus

Sept. 14, 2001

Bug: loss of mousepointer

by Marcus Meissner

Hi, After last nights CVS commits, the Mousepointer appears not to be visible in some applications in both managed and unmanaged mode. Reproducable for me with sol.exe and winmine.exe (16bit) for instance. Ciao, Marcus

Sept. 14, 2001

Re: unmanaged windows

by Alexandre Julliard

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > I think there was a discussion a while back about possibly rewriting the > "unmanaged" mode (or adding a new mode, I don't recall which) to make it more > like XMMS, but I can't find it now. This would really help on my system, as > with KDE 2.2, wine windows are always on top and on every desktop and XMMS > fits in a little better. I was wondering what the result if any, of that > discussion was. I was planning to implement that as part of the new window management stuff. But this is on hold at the moment while I'm finishing the shared window handles. -- Alexandre Julliard julliard(a)winehq.com

Sept. 14, 2001

Re: GDI_CheckNotLock strikes again

by Dmitry Timoshkov

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > Does this help? Yes, it does. But application (a heavily modified MS glyph sample from 1993) doesn't show anything. I could send you the source code if you are interested to fix it. -- Dmitry.

Sept. 14, 2001

Re: GDI_CheckNotLock strikes again

by Huw D M Davies

On Thu, Sep 13, 2001 at 05:49:56PM +0900, Dmitry Timoshkov wrote: > Hello. > > Decided to try sample program which uses GetGlyphOutline. > > Backtrace: > =>0 0x400d2ae1 (_CheckNotSysLevel+0x51(lock=0x407bb6a4) [syslevel.c:153] in libntdll.so) (ebp=405b6734) > 1 0x407a2667 (GDI_CheckNotLock+0x1b [gdiobj.c:446] in libgdi32.so) (ebp=405b6744) > 2 0x40798a1c (DeleteDC+0x48(hdc=0x8bc) [dc.c:784] in libgdi32.so) (ebp=405b6764) > 3 0x407983b9 (RestoreDC+0x13d(hdc=0x8a0, level=0x1) [dc.c:541] in libgdi32.so) (ebp=405b6790) > 4 0x4078ba4b (PATH_StrokePath+0x28b(dc=0x403a1640, pPath=0x403a16a0) [path.c:1511] in libgdi32.so) (ebp=405b67b4) Does this help? Huw.

Sept. 13, 2001

Re: Problem with specmaker

by Guy L. Albertelli

-----Original Message----- From: Patrik Stridvall <ps(a)leissner.se> To: 'eric pouech' <eric.pouech(a)wanadoo.fr>; Guy L. Albertelli <galberte(a)neo.lrun.com> Cc: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, September 06, 2001 5:59 PM Subject: RE: Problem with specmaker > >Hmm. Thinking, modifying etc. > >What about this? > >Index: wine/tools/specmaker/function_grep.pl >=================================================================== >RCS file: /home/wine/wine/tools/specmaker/function_grep.pl,v >retrieving revision 1.1 >diff -u -u -r1.1 function_grep.pl >--- wine/tools/specmaker/function_grep.pl 2001/01/04 19:45:50 1.1 >+++ wine/tools/specmaker/function_grep.pl 2001/09/06 21:50:26 <snip> No the above patch merely resulted in an infinite loop. After much consultation with "Perl in a Nutshell", I came up with the following patch. The header file in question is "shlobj.h". The patch has two sections. First gets rid of the \n imbeded with the lookahead for preprocessor statements. The second gets rid of the ICOM_DEFINE statement (poorly I know) because it has no ";". This seems to make things work and generate correct headers. Thanks, Guy

Sept. 13, 2001

RE: dlls/advapi32/crypt.c

by Patrik Stridvall

> On another note, however, I was re-reading the CryptoAPI > thread and I don't > think that Vladimir Vukicevic's questions were really > answered from September > 3rd. Can you be a little more specific? As far using GPL:ed libraries, that is a question that really can't be properly answered without a real court case. Regardless of this if you want any code using a GPL:ed library in the CVS you need to convince Alexandre to change his mind. What other questions are unanswered?

Sept. 13, 2001

Re: dlls/advapi32/crypt.c

by Travis Michielsen

On September 12, 2001 6:51 pm, Morten Welinder wrote: > Someone added code to CryptGenRandom so that it generates > very bad random data (with <10 bits randomness in them). > > Don't do that. It's a known security risk. > > Read from /dev/urandom instead. If that does not succeed, just > abort(). > > Linux and newer Solaris have /dev/urandom. I would guess the > BSDs have it too. > > Morten So far all the functions in that file are just stubs. I would assume that CryptGenRandom is currently not being used (at least not much) if the rest of the API has not been implemented. If you read the comments inside that function, however, it is listing this situation as a known problem. I will likely fix this though in an upcoming patch to the CryptoAPI (patch 3 or 4 perhaps?) . On another note, however, I was re-reading the CryptoAPI thread and I don't think that Vladimir Vukicevic's questions were really answered from September 3rd. As to my progress, so far I have just creating stubs for the functions in advapi32.dll (patch 1 - crypt.c) and am currently working on wincrypt.h (patch 2). If you want to help on the API, you can. However, we should probably try to coordinate our efforts. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Sept. 13, 2001

wcs* functions within Wine

by Huw D M Davies

Hi, I want to use wcsrchr and wcstrol in oleaut32.dll . If I just use them then we do indeed call the ntdll versions rather than libc which is all very nice. The question is, what include file am I supposed to use to get their protoypes? Huw.

Sept. 13, 2001

unmanaged windows

by Bobby Bingham

I think there was a discussion a while back about possibly rewriting the "unmanaged" mode (or adding a new mode, I don't recall which) to make it more like XMMS, but I can't find it now. This would really help on my system, as with KDE 2.2, wine windows are always on top and on every desktop and XMMS fits in a little better. I was wondering what the result if any, of that discussion was. Bobby Bingham -- Microsoft Windows: Made for the internet The Internet: Made for UNIX

Sept. 13, 2001

GDI_CheckNotLock strikes again

by Dmitry Timoshkov

Hello. Decided to try sample program which uses GetGlyphOutline. Backtrace: =>0 0x400d2ae1 (_CheckNotSysLevel+0x51(lock=0x407bb6a4) [syslevel.c:153] in libntdll.so) (ebp=405b6734) 1 0x407a2667 (GDI_CheckNotLock+0x1b [gdiobj.c:446] in libgdi32.so) (ebp=405b6744) 2 0x40798a1c (DeleteDC+0x48(hdc=0x8bc) [dc.c:784] in libgdi32.so) (ebp=405b6764) 3 0x407983b9 (RestoreDC+0x13d(hdc=0x8a0, level=0x1) [dc.c:541] in libgdi32.so) (ebp=405b6790) 4 0x4078ba4b (PATH_StrokePath+0x28b(dc=0x403a1640, pPath=0x403a16a0) [path.c:1511] in libgdi32.so) (ebp=405b67b4) 5 0x4078baf0 (StrokeAndFillPath+0x64(hdc=0x8a0) [path.c:1547] in libgdi32.so) (ebp=405b67d4) 6 0x004016c6 (DrawPath+0xb6(hDC=0x8a0) [C:\DevStudio\Projects\Glyph\Glyph.c:434] in C:\Glyph.exe) (ebp=405b683c) 7 0x00401c77 (DrawTTOutline+0x527(hDC=0x8a0, lpHeader=0x403a1c10, size=0xffffffff) [C:\DevStudio\Projects\Glyph\Glyph.c:618] in C:\Glyph.exe) (ebp=405b68c8) 8 0x00402023 (OutputGlyph+0x243(hDC=0x8a0, letter=0x21, x=0x0, y=0x0, ascent=0x78) [C:\DevStudio\Projects\Glyph\Glyph.c:724] in C:\Glyph.exe) (ebp=405b6970) 9 0x0040225f (PaintIt+0x14f(hWnd=0x10021, hDC=0x8a0) [C:\DevStudio\Projects\Glyph\Glyph.c:806] in C:\Glyph.exe) (ebp=405b6a48) 10 0x00402701 (MainWndProc+0x351(hWnd=0x10021, message=0xf, wParam=0x0, lParam=0x0) [C:\DevStudio\Projects\Glyph\Glyph.c:958] in C:\Glyph.exe) (ebp=405b6b30) 11 0x406e8507 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b6b54) 12 0x406e85a0 (WINPROC_CallWndProc+0x8c(proc=0x401028, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:172] in libuser32.so) (ebp=405b6b84) 13 0x406edcfd (WINPROC_CallProc32WTo32A+0x8d(func=0x401028, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2434] in libuser32.so) (ebp=405b6bac) 14 0x406ee237 (CallWindowProcW+0x93(func=0x40f80871, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2685] in libuser32.so) (ebp=405b6bd4) 15 0x4068a6c9 (call_window_proc+0xb5(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=405b6c24) 16 0x4068b23c (SendMessageTimeoutW+0xc4(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405b6ca8) [message.c:1508] in libuser32.so) (ebp=405b6c78) 17 0x4068b4b0 (SendMessageW+0x38(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0) [message.c:1577] in libuser32.so) (ebp=405b6cac) 18 0x406d6a03 (RDW_Paint+0xbf(wndPtr=0x4039f0cc, hrgn=0x0, flags=0x180, ex=0x0) [painting.c:780] in libuser32.so) (ebp=405b6ce0) 19 0x406d6f40 (RedrawWindow+0x398(hwnd=0x10021, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:974] in libuser32.so) (ebp=405b6d4c) 20 0x406d703d (UpdateWindow+0x21(hwnd=0x10021) [painting.c:1006] in libuser32.so) (ebp=405b6d68) 21 0x0040297e (InitInstance+0x6e(hInstance=0x400000, nCmdShow=0xa) [C:\DevStudio\Projects\Glyph\Glyph.c:1051] in C:\Glyph.exe) (ebp=405b6dc4) 22 0x004029e0 (WinMain+0x30(hInstance=0x400000, hPrevInstance=0x0, lpCmdLine=0x40360c45, nCmdShow=0xa) [C:\DevStudio\Projects\Glyph\Glyph.c:1087] in C:\Glyph.exe) (ebp=405b6e3c) 23 0x00402f53 (WinMainCRTStartup+0x113 [crt0.c:198] in C:\Glyph.exe) (ebp=405b6ecc) 24 0x400cec3d (start_process+0x195 [process.c:390] in libntdll.so) (ebp=405b6f30) 25 0x400d252c (SYSDEPS_DoCallOnStack+0x20(func=0x400ceaa8, arg=0x0) [sysdeps.c:183] in libntdll.so) (ebp=405b6ff0) 26 0x400d25d3 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffffa3c) 27 0x400d2680 (SYSDEPS_SwitchToThreadStack+0x94(func=0x400ceaa8) [sysdeps.c:238] in libntdll.so) (ebp=bffffa78) 28 0x400cefce (PROCESS_InitWine+0x1ca(argc=0x2, argv=0xbffffaf4, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:522] in libntdll.so) (ebp=bffffa90) 29 0x0804b1e6 (Letext [main.c] in wine) (ebp=bffffaa8) 30 0x402769cb (__libc_start_main+0xff(main=0x804b1cc, argc=0x2, argv=0xbffffaf4, init=0x80486d4, fini=0x804b224, rtld_fini=0x4000aea0, stack_end=0xbffffaec) [libc-start.c:92] in libc.so.6) (ebp=bffffac8) 31 0x08049021 (_start+0x21 in wine) (ebp=00000000) -- Dmitry.

Sept. 13, 2001

Re: negative listview column width in WinZip 8.0

by Malte Starostik

Am Thursday 13 September 2001 03:37 schrieben Sie: > WinZip 8.0 requests a negative column width for one of the columns in > the WinZip classic Zip file contents list. This stuffs up the list, > causing the other columns to be overwritten, and resulting in a blank > list. > > This patch prevents column widths from being negative. AFAIK, -1 and -2 and maybe others are special values that tell the list view to adjust the contents to the widest item and something else I cannot remember exactly (sorry, no Windows available ATM). -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] http://malte.homeip.net/justice-not-war.html M0ò0ò0

Sept. 13, 2001