February 2001 - Wine-Devel - list.winehq.org

Re: debugger fix

by Ulrich Weigand

Eric Pouech wrote: > anyway, I don't think removing the .rel.stab is a big deal. the > current debugger code doesn't use the address of a global symbol > in .stab section, but rather rely on the ELF information... > (but if we also start by removing the .rel.stab section, the > compilation scheme becomes more and more ugly) So, if you use this version of strip_imports, does the Wine build run through then? #!/bin/sh # # Strip import stub symbols from Wine DLLs # while [ $# -gt 0 ] do if [ ! -e $1 ] then echo "strip_imports: $1: file not found" exit 1 fi /* Hack alert: some broken toolchains create a .rel.stab section. objcopy (all versions) has a bug that makes it unable to process reloc sections outside of segments (which .rel.stab is) ... Thus, we kill the .rel.stab section before running objcopy to remove the import stub symbols */ objcopy -R .rel.stab $1 IMPLIST=`nm $1 | grep __wine_dllimport | sed -e 's/^.*__wine_dllimport_[^_]*_/-N /'` if [ "$IMPLIST" != "" ] then echo $IMPLIST | xargs objcopy $1 fi shift done exit 0 Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

Feb. 6, 2001

Re: Strange window message / queue behaviour

by gerard patel

At 12:00 AM 6/2/01 +0100, you wrote: >last paragraph), there's also the possibility that Windows recognizes that >it's a message known to contain pointers, and so just drops the message, >so that EM_GETSEL is simply never dispatched? Indeed under NT4 such a call is discarded by Windows (returns 0, error is set to ERROR_INVALID_PARAMETER) Gerard

Feb. 6, 2001

Re: Strange window message / queue behaviour

by Ove Kaaven

On Mon, 5 Feb 2001, Marcus Meissner wrote: > PostMessageA(hwnd1,EM_GETSEL,&startsel,&endsel); Eek. > My suspicion is that SetFocus() in Windows drains all posted messages by > doing something like: > while (PeekMessage()) { TranslateMessage(); DispatchMessage(); } > but I do not really know. >From something (admittedly tangential/irrelevant to this problem) I remember Ulrich have been talking about (http://www.winehq.com/News/1999-48.html#2, last paragraph), there's also the possibility that Windows recognizes that it's a message known to contain pointers, and so just drops the message, so that EM_GETSEL is simply never dispatched? Or maybe the edit control uses IsBadWritePtr or exception handlers (though that would be even worse, race conditions...). At least message loops in SetFocus really doesn't seem right.

Feb. 5, 2001

Re: annoying EndDialog "feature"

by Andreas Mohr

On Mon, Feb 05, 2001 at 11:17:19PM +0100, gerard patel wrote: > At 02:38 PM 5/2/01 -0600, you wrote: > >Well, examining how Windows does it can be done, > >but I don't think it's too useful, as I think that the current approach > >with that fix should work fine. > > > >> Now I think I see : this can only be useful if EndDialog is called from > >> another thread, right ? If yes, you really *should* mention this in the > >> remark before the code. No need to be mysterious IMHO. > >I don't think the "other thread" is important. > >What is important is the fact that if we don't get frequent messages, > >the dialog will stay open without that fix. > > Well, if the current thread is active, it's in the dialog code I guess since > DialogBox is, well, modal. > And if it's in the dialog code, the code run should be in dialog box > procedure, so it should be in a message handling. So any EndDialog > is followed by a return to the dialog loop. I am not quite sure of > that, though. I've never really looked that up. > >Windows definitely does NOT do it this way, of course > >(well, I'd be surprised if it actually did ;-). > >This is just a (crude, if you want) hack to make it work. > >And I figured sending WM_NULL shouldn't hurt. > >I'm open to suggestions on how to rewrite the whole dialog handling > >(e.g. to do it like Windows), but I don't think it matters at all > >at the moment. > >There are much more important things to do. > > Possibly, but it's important at least to add a comment saying that it is a hack.... > Correct documentation can wait you think ? Wine is full of strange code > that nobody knows why it's here already :-/ Well, at least I *do* add comments to my code... ;-) (and that comment wasn't so bad) But yes, it only went as far as explaining 70%, not 100%. Andreas Mohr

Feb. 5, 2001

Strange window message / queue behaviour

by Marcus Meissner

Hi, I have an application that handles several text edit controls. At one point it flips from the first to the second (after you have entered the fourth character). This is done by a function, which does (simplified) this: { DWORD startsel,endsel; PostMessageA(hwnd1,EM_GETSEL,&startsel,&endsel); SetFocus(hwnd2); PostMessageA(hwnd2,EM_SETSEL,0,0); /* ... */ CallWindowProcA(hwnd,....); return; } According to the +relay,+edit trace the EM_GETSEL is executed way _AFTER_ the return from the function, so, since it uses stackvalues, it then smashes the stack somewhere else. My suspicion is that SetFocus() in Windows drains all posted messages by doing something like: while (PeekMessage()) { TranslateMessage(); DispatchMessage(); } but I do not really know. Does anybody have more knowledge of this? The respective trace is here, starting with the posting of the message with the pointers into the stack: Ciao, Marcus Call user32.455: PostMessageA(000006b4,000000b0,40599904,40599908) ret=0041a99b fs=008f Ret user32.455: PostMessageA() retval=00000001 ret=0041a99b fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041a9ab fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041a9ab fs=008f Call user32.527: SetFocus(0000074c) ret=0041a9b2 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_KILLFOCU S,wp=0000074c,lp=00000000) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,00000008,0000074c,00000000) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_KILLFO CUS,wp=0000074c,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=020007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=020007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=020007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=020007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_KILLFO CUS,wp=0000074c,lp=00000000) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_KILLFOCU S,wp=0000074c,lp=00000000) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=0000074c,msg=WM_SETFOCUS ,wp=000006b4,lp=00000000) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041aa7c fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041aa7c fs=008f Call user32.21: CallWindowProcA(41060311,0000074c,00000007,000006b4,00000000) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=0000074c,msg=WM_SETFOC US,wp=000006b4,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=010007d7,lp=0000074c) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=010007d7,lp=0000074c) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=010007d7,lp=0000074c) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=010007d7,lp=0000074c) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=0000074c,msg=WM_SETFOC US,wp=000006b4,lp=00000000) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=0000074c,msg=WM_SETFOCUS ,wp=000006b4,lp=00000000) retval=00000000 Ret user32.527: SetFocus() retval=000006b4 ret=0041a9b2 fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041a9cc fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041a9cc fs=008f Call user32.455: PostMessageA(0000074c,000000b1,00000000,00000000) ret=0041a9d3 fs=008f Ret user32.455: PostMessageA() retval=00000001 ret=0041a9d3 fs=008f Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,00000102,00000048,00230001) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_CHAR,w p=00000048,lp=00230001) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=040007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=040007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=040007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=040007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=030007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=030007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=030007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=030007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_CHAR,w p=00000048,lp=00230001) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_CHAR,wp= 00000068,lp=00230001) retval=00000000 After this it directly returns from the function. trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=EM_GETSEL32 ,wp=40599904,lp=40599908) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,000000b0,40599904,40599908) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=EM_GETSEL 32,wp=40599904,lp=40599908) trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=EM_GETSEL 32,wp=40599904,lp=40599908) retval=00040004 Ret user32.21: CallWindowProcA() retval=00040004 ret=00000004 fs=008f ... but still uses its stack values here. faulted at EIP=0x00000004, CR2=0x00000004, EAX 0x00040004 EBX 0x407936fc, ECX 0x00000001, EBP 0x40599950 EDI 0x40599904, ESP 0x002b:0x40599908 FS 0x008f, pid 1772

Feb. 5, 2001

Re: annoying EndDialog "feature"

by gerard patel

At 02:38 PM 5/2/01 -0600, you wrote: >Well, examining how Windows does it can be done, >but I don't think it's too useful, as I think that the current approach >with that fix should work fine. > >> Now I think I see : this can only be useful if EndDialog is called from >> another thread, right ? If yes, you really *should* mention this in the >> remark before the code. No need to be mysterious IMHO. >I don't think the "other thread" is important. >What is important is the fact that if we don't get frequent messages, >the dialog will stay open without that fix. Well, if the current thread is active, it's in the dialog code I guess since DialogBox is, well, modal. And if it's in the dialog code, the code run should be in dialog box procedure, so it should be in a message handling. So any EndDialog is followed by a return to the dialog loop. I am not quite sure of that, though. >Windows definitely does NOT do it this way, of course >(well, I'd be surprised if it actually did ;-). >This is just a (crude, if you want) hack to make it work. >And I figured sending WM_NULL shouldn't hurt. >I'm open to suggestions on how to rewrite the whole dialog handling >(e.g. to do it like Windows), but I don't think it matters at all >at the moment. >There are much more important things to do. Possibly, but it's important at least to add a comment saying that it is a hack.... Correct documentation can wait you think ? Wine is full of strange code that nobody knows why it's here already :-/ Gerard

Feb. 5, 2001

Re: debugger fix

by Eric Pouech

> I still don't understand why your toolchain creates a > .rel.stabs section in the first place. Could you check > at which point this is created first (as, ld, ld -shared)? it's done in latest ld -shared step. even a simple test example generates a .rel.stab section... (simple function compiled and linked to generate a .so file) I got a quick look at its content... it's always a relative relocation (like for a symbol global address), which in most examples I've seen is set to 0... another nice "feature" is that lots of libraries also have the .rel.stab, so it seems to come also from the distro itself (even if I goofed somehow with my setup) I'll dig further anyway, I don't think removing the .rel.stab is a big deal. the current debugger code doesn't use the address of a global symbol in .stab section, but rather rely on the ELF information... (but if we also start by removing the .rel.stab section, the compilation scheme becomes more and more ugly) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 5, 2001

Re: Corel Draw for Linux

by Bernhard Rosenkraenzer

On Mon, 5 Feb 2001, Uwe Bonnes wrote: > Does anybody know what is the status of Corel Draw for Linux? Sure, it's available. It's not very stable though. > Any source in Germany? AFAIK ixsoft (http://www.ixsoft.de/) has it. LLaP bero

Feb. 5, 2001

Corel Draw for Linux

by Uwe Bonnes

Hallo, somebidy fronm the local Linux User Group desperatlly looks for Corel Draw for Linux in Germany. He wasn't able to find anything? Looking araound only brings misleading Corel statements. Does anybody know what is the status of Corel Draw for Linux? Any source in Germany? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 5, 2001

Re: annoying EndDialog "feature"

by Andreas Mohr

On Mon, Feb 05, 2001 at 09:24:42PM +0100, gerard patel wrote: > At 10:37 AM 5/2/01 -0600, you wrote: > > >> I can't see this WM_NULL with Winsight. Maybe it's a bug in > >> Winsight :-/, but are you sure it's not some framework that is > >> sending it ? > >Hmm, what are you talking about ? > > > >And I don't quite understand what you're investigating here... ;-) > > *I* don't understand what it is supposed to fix. Using Winsight > was a rather brainless attempt to see what is happening under > Windows. Well, examining how Windows does it can be done, but I don't think it's too useful, as I think that the current approach with that fix should work fine. > Now I think I see : this can only be useful if EndDialog is called from > another thread, right ? If yes, you really *should* mention this in the > remark before the code. No need to be mysterious IMHO. I don't think the "other thread" is important. What is important is the fact that if we don't get frequent messages, the dialog will stay open without that fix. > Anyway, I tested your patch with a thread I launched before the > DialogBox call; after 15" of sleep the thread is calling EndDialog. > To add fun I added a WM_NULL handler in the dialog procedure > to display a MessageBox; under Windows the MessageBox does not fire, > under Wine with your patch, it does (test app available) > So probably Windows does not do it this way (or the WM_NULL message is > filtered). It probably does not matter much, granted. Windows definitely does NOT do it this way, of course (well, I'd be surprised if it actually did ;-). This is just a (crude, if you want) hack to make it work. And I figured sending WM_NULL shouldn't hurt. I'm open to suggestions on how to rewrite the whole dialog handling (e.g. to do it like Windows), but I don't think it matters at all at the moment. There are much more important things to do. Andreas Mohr

Feb. 5, 2001