- Wine-Devel - list.winehq.org

Re: fix teb crash
by Andreas Mohr Feb. 1, 2001

Feb. 1, 2001

On Thu, Feb 01, 2001 at 12:32:34AM +0100, gerard patel wrote: > At 12:12 PM 31/1/01 +0100, you (amohr(a)codeweavers.com) wrote: > >The terminated thread had done a SendMessage before, however, and when > >the receiving thread tried to reply to that SendMessage, the sending thread > >was gone, which resulted in a crash as queue->teb was invalid. > > <snip> > > I remember having looked at some crash akin to this one; I had > never the time to find the proper fix, but my impression was rather > that the problem was that Wine don't destroy windows when a thread > is terminated through TerminateThread(). Nope, I don't think so. The part doing this is: [cleanup] Call kernel32.443: GlobalFree(403b4864) ret=010043cd fs=02c7 Ret kernel32.443: GlobalFree() retval=00000000 ret=010043cd fs=02c7 Call kernel32.273: FreeResource(0101225c) ret=01004730 fs=02c7 Ret kernel32.273: FreeResource() retval=00000000 ret=01004730 fs=02c7 Call user32.500: SendMessageA(00000138,00000fa1,00000001,00000000) ret=01004777 fs=02c7 trace:relay:WINPROC_CallWndProc (wndproc=0x40751990,hwnd=00000138,msg=WM_USER+0ba1,wp=00000001,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_USER+0ba1,wp=00000001,lp=00000000) Call kernel32.685: TerminateThread(00000048,00000000) ret=01002f65 fs=008f err:win:UserSignalProc uCode: 32 err:system:UserSignalProc Ret kernel32.685: TerminateThread() retval=00000001 ret=01002f65 fs=008f Call user32.188: EndDialog(00000138,00000001) ret=0100307f fs=008f trace:dialog:EndDialog 0138 1 trace:relay:WINPROC_CallWndProc (wndproc=0x40722ac0,hwnd=00000228,msg=WM_KILLFOCUS,wp=00000138,lp=00000000) trace:win:GetClientRect (0,0 - 75,21) trace:relay:WINPROC_CallWndProc (wndproc=0x40751990,hwnd=00000138,msg=WM_CTLCOLORBTN,wp=0000005c,lp=00000228) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_CTLCOLORBTN,wp=0000005c,lp=00000228) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_CTLCOLOR This is a dialog with a progress bar, BTW. So it seems the progress bar is a separate thread of the dialog, which is probably also responsible for extracting files. And this worker thread does a SendMessage to the original thread, which then does a TerminateThread of the sending thread and an EndDialog to close the whole dialog. And after that the window proc returns and Wine wants to send the window procs result to the sending thread, only to discover that the originating thread doesn't *exist* any more and to crash ! That's why we need this fix IMHO. Andreas Mohr

1 0

Present status of DOS support
by Uwe Bonnes Feb. 1, 2001

Feb. 1, 2001

Hallo, it seems that libwinedos.so is missing some functions on my system: hertz:/spare/bon/wine> wine -- /dosc/local/pkunzip.exe eagle-4.0g.exe ... fixme:win32:ELF_FindExportedFunction function GetCurrent not found: /spare/bon/wine/dlls/libwinedos.so: undefined symbol: GetCurrent fixme:win32:ELF_FindExportedFunction function LoadDPMI not found: /spare/bon/wine/dlls/libwinedos.so: undefined symbol: LoadDPMI ... Did I forget to configure something? But with a grep through the sources, I couldn't find a place were LoadDPMI was defined. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: WINE_UNICODE_TEXT
by Francois Gouget Feb. 1, 2001

Feb. 1, 2001

On Mon, 29 Jan 2001, Jon Griffiths wrote: > Hi, > > This patch removes the warnings from the WINE_UNICODE_TEXT macro and fixes an > obscure (read: uninvestgated) bug where the value of WCHAR('x') + 1 is off by You mean WINE_UNICODE_TEXT('x')+1 != WINE_UNICODE_TEXT('y') ? I see why this could happen: gcc considers that the expression is of type WCHAR* and since sizeof(WCHAR)==2, it just adds two. > one. Currently 2-3 warnings are generated whenever TEXT() is used in Winelib > programs, depending on whether a string or char is the target. > > Only one warning remains, when using WCHAR('x') the result should be > explicitly cast to WCHAR to get rid of it. If you do this -Wall is blissfully > silent once again... Which means you get warnings too. I'm not too convinced about this patch especially because it does not return the proper type. On the other hand it seems what I did returns a WCHAR* (after a fashion). But it seems there's no really good solution (besides -fshort-wchar) :-(. If you are going to modify your source, I think casting TEXT('x') to WCHAR is not the solution. The solution is to not use TEXT (and equivalents) on characters. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 3

Re: signed char
by Uwe Bonnes Feb. 1, 2001

Feb. 1, 2001

Josh DuBois writes: > { > - char *p = (char*) p_data; > + signed char *p = (char*) p_data; ^signed Shouldn't the cast be for the targert variable? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0