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

Re: winebuild ppc

by Ulrich Weigand

Josh DuBois wrote: > @@ -3396,7 +3428,7 @@ > HANDLE OwningThread; > HANDLE LockSemaphore; > ULONG_PTR SpinCount; > -} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; > +} __attribute__ ((aligned (4))) RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; Why? The default alignment of this struct is 4 anyway (as all its members have a default alignment of 4 ...) The only situation where a RTL_CRITICAL_SECTION could conceivably be not aligned to 4 would be if if were embedded into a packed struct. In this case, however, the aligned attribute wouldn't help either AFAIK. (Additionally, the gcc'ism will annoy Patrik ;-/) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

Feb. 1, 2001

Re: fix teb crash

by Andreas Mohr

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

Feb. 1, 2001

Re: Present status of DOS support

by Ove Kaaven

On Thu, 1 Feb 2001, Uwe Bonnes wrote: > 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 > ... winedos.spec: @ stdcall GetCurrent() MZ_Current @ stdcall LoadDPMI() MZ_AllocDPMITask @ stdcall LoadDosExe(str long) MZ_LoadImage @ stdcall Exec(ptr str long ptr) MZ_Exec @ stdcall Exit(ptr long long) MZ_Exit Something missing?

Feb. 1, 2001

Re: psdrv: map Courier New to Courier

by Ian Pilcher

Huw D M Davies wrote: > > Great! Well the Windows 2000 PS driver stores the font sub table > under the value name "TTFontSubTable" in the printer driver's > PrinterDriverData registry key. To do this we need to implement > Get/SetPrinterData (if you give me a couple of days I'll do it). The > data associated with TTFontSubTable is just a set of 2n \0 > terminated strings the final one terminated by 2 \0 > (i.e. REG_MULTISZ). The actual configuring should go on in the > printer setup property sheet. Hmmm, fancy learning a little of the > Win32 api? > I think I can probably handle reading the registry. (Although from what little I've seen of the Win32 API, even that could be a night- mare.) I think we should also allow the Wine config file to override what's in the registry. > > hdavies(a)codeweavers.com should work. Could you also send me the > output of --debugmsg +psdrv. Note if you're using ghostscript to > process the output then the fonts will look about 15% larger, that's > because GS's fonts are rather bigger than Adobe's and you're probably > using Adobe's AFMs. Other than that then I'm seeing Wine's Courier to > be about another 15% larger than the output from Windows. > I think I may have overstated how large Courier is printing, at least in relation to other Type 1 fonts. I had forgotten that the TrueType fonts I have converted to Type 1 tend to print somewhat smaller than the Adobe/Ghostscript fonts. (I do see the problem on both my Ghost- script-driven printer at home and the PostScript printers at work.) Since people seem to use Arial and Courier a lot, the problem is emphasized; content that uses monospaced fonts also tends to suffer more when it is unexpectedly wrapped. So I think its mixing the two that makes things look really odd. For my particular situation, mapping everything to the "TrueType" fonts is probably the way to go, so I'll be motivated to get the user-defined mapping working. Which leads me to another, more dangerous, thought. It seems to me that life would be simpler for everyone if we could bring some consistency to the way that Wine's display and print subsystems work with fonts. What about a section in the configuration file that related Windows, X, and PostScript font names? In the old style, I would have suggested something of the form: Windows Font = X LFD, PostScript font name This would seem to be relatively straightforward to implement, and it would bring a small measure of sanity to the area. (I currently have both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and the PostScript driver don't agree on what the font should be called!) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 1, 2001

Present status of DOS support

by Uwe Bonnes

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 ----------

Feb. 1, 2001

Re: psdrv: map Courier New to Courier

by Ian Pilcher

Gavriel State wrote: > > Just FYI, the corelwine tree has support for psdrv font mapping that > you might be able to use - it uses the wine config file rather than > the registry to store font aliases, but as I recall it was a pretty > minor change in the psdrv code. > This may be a stupid question, but where is the Corel Wine tree? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 1, 2001

Re: WINE_UNICODE_TEXT

by Jon Griffiths

Hi, > Actually I suspect there's another problem with your patch. since you > cast the return values to void*, WINE_UNICODE_TEXT("abc")+1 will very > likely be wrong. Also I believe void* arithmetic is a gcc extension. I haven't checked, but youre probably right. However Ive never come across that usage of a literal in unicode or ascii (why increment a string lteral at declaration time?). But doing it to chars is quite common e.g. converting to a number string ('a' + n etc). > Do you have a lot of places where your application uses > WINE_UNICODE_TEXT with a character? I just know of a <10 places in the > MFC. Only about 5 cases in VWCL itself. >Alexandre suggests we just handle the string case and let it fail > at compile time if it is used with a char. It may be better than > compiling fine but doing incorrect things. Either works for me. All I really want is -Wall clean ;-) Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

Feb. 1, 2001

Re: WINE_UNICODE_TEXT

by Jon Griffiths

Hi, > type WCHAR* and since sizeof(WCHAR)==2, it just adds two. Sounds likely. A cast back to WCHAR fixes it, anyhow, but isn't especially nice. > 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). As you say, based on the above it seems that currently the conditional expression returns WCHAR* despite their being 2 possible returns. So it returns the wrong type for characters anyway. The whole macro can be cast to a WCHAR* if thats a problem and the behavior will be the same as with the patch as it stands (only one warning, when used with L'x' , for assigning a pointer to an int), but the bug above will remain. Assigning from a void* is perfectly safe and fixes the bug, so I chose that. > it seems there's no really good solution (besides -fshort-wchar) :-(. Sadly we're a long way away from having that option for the majority.Also going forward with Winelib there will be people who aren't using gcc, and who mightn't have that option at all. > 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. I agree, its not the best solution. My point was that it is possible to fix the problem (either by casting or some other method), and then compile your code without warnings. The purpose of the change is to remove all warnings except for the specific problematic case, which makes it considerably easier to locate and fix the offending code. Currently you get spurious warnings which dont help when the macro is used correctly (with L'string'). Given that it generates multiple warnings even when used corectly, how is a developer to notice that s/he has to fix that one case? IMHO its better to only generate a warning for the case that has problems, especially when its safe to eliminate the other warnings. So rather than leaving the broken macro in with warnings for both cases and a bug for one case, why not just remove support for characters from the macro altogether? Personally I prefer the patch because IMO it leaves the option to ignore the warning, and fixes the bug as well. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

Feb. 1, 2001

Re: WINE_UNICODE_TEXT

by Francois Gouget

On Thu, 1 Feb 2001, Francois Gouget wrote: > 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. Actually I suspect there's another problem with your patch. since you cast the return values to void*, WINE_UNICODE_TEXT("abc")+1 will very likely be wrong. Also I believe void* arithmetic is a gcc extension. Do you have a lot of places where your application uses WINE_UNICODE_TEXT with a character? I just know of a <10 places in the MFC. Alexandre suggests we just handle the string case and let it fail at compile time if it is used with a char. It may be better than compiling fine but doing incorrect things. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Feb. 1, 2001

Re: WINE_UNICODE_TEXT

by Francois Gouget

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.

Feb. 1, 2001