July 2002 - Wine-Devel - list.winehq.org

Re: dos console apps question

by Jukka Heinonen

Yes, many DOS console apps don't work under plain Wine because DOS emulation does not create console for the applications. Some applications actually make Wine crash because the application gets illegal coordinates when GetConsoleScreenBufferInfo fails. The correct place for console allocation would likely be VGA_SetAlphaMode; call to normal Windows AllocConsole() function should be enough, no server calls are needed. Additionally, if DOS console application tries to call a routine that requires console, VGA_SetAlphaMode should be called in order to initialize console (see VGA_SetCursorPos). I have been thinking doing this myself, but I have always ended up being uncertain about how this change is going to affect piping input and output of DOS programs that use only stream IO and not console IO. Anyway, I don't have time for this stuff so I would appreciate if you could work on this. -- Jukka Heinonen <http://www.iki.fi/jhei/>

July 25, 2002

Re: Threading on Solaris

by Gregg Mattinson

Hey everyone. I've been trying to update threads by following Francois' directions, and I think I may have come across a bug. Can someone help me out here... Why does the SYSLEVEL structure have a CRITICAL_SECTION inside it? Shouldn't a mutex be used instead? According to MSDN, the function EnterCriticalSection has the following property: If a thread terminates while it has ownership of a critical section, the state of the critical section is undefined. Also, WaitForSingleObject returns WAIT_ABANDONED if: the specified object is a mutex object that was not released by the thread that owned the mutex object before the owning thread terminated. Ownership of the mutex object is granted to the calling thread, and the mutex is set to nonsignaled. So, if a thread _EnterSysLevel and is then terminated, no other threads can enter that sys level. This seems wrong to me... Should I replace the CRITICAL_SECTION with a mutex? Any objections? Or, should EnterCriticalSection be fixed so that it has similar behaviour to WaitForSingleObject, instead of "undefined" behaviour (which is currently to block forever) Let me know what you guys think, Gregg Mattinson Co-op Developer Sun Microsystems of Canada >From: Gregg Mattinson <gm138242(a)opcom-mail.canada.sun.com> >Subject: Re: Threading on Solaris >To: wine-devel(a)winehq.com >Cc: fgouget(a)codeweavers.com >Date: Tue, 23 Jul 2002 07:21:46 -0400 (EDT) > >Threads on Solaris are a big issue for Sun, so I will start tackling this >problem today. Thanks for telling me all the issues Francois. I have a >hack-ish version implemented, and now I can create a real solution to the >problem. > >Gregg Mattinson >Co-op Developer >Sun Microsystems of Canada > >>From: Francois Gouget <fgouget(a)codeweavers.com> >>To: wine-devel(a)winehq.com >>CC: Gregg Mattinson <gm138242(a)opcom-mail.canada.sun.com> >>Subject: Threading on Solaris >>Date: Tue, 23 Jul 2002 00:35:09 -0700 >> >>Hi, >> >> >>Some time ago I did some tests of Wine on Solaris x86 and found that >>there is a problem with the way we handle threads due to the differences >>between the Linux and Solaris threading models. These differences are >>also relevant for Solaris Sparc and probably many other Unices. >> >>Unfortunately I don't have time to work on it anymore so I created a bug >>report in Bugzilla where I tried to dump the relevant information, >>including a patch to illustrate the issues and the start of a fix. I >>hope it will be useful to someone... maybe Gregg who has been doing a >>lot of Solaris work recently. >> >>http://bugs.winehq.com/show_bug.cgi?id=904 >> >> >>-- >>Francois Gouget >>fgouget(a)codeweavers.com >

July 25, 2002

Re: Procite and Wine

by Duane Clark

Duane Clark wrote: > > Reading the MS docs, it appears to me that in this case RDW_FRAME should > be ignored. What happens is the program has an area that needs to be > repainted, but this part of the code causes only a portion to be > repainted, leaving a portion of the screen still "invalidated". This > causes another paint request, which since nothing has changed, still > does not result in the correct repainting. And so it is stuck in an > indefinite loop. I probably should mention where in the MS docs I was getting this idea. For the function RedrawWindow: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/pantdr… It says "The following flags are used to validate the window." and lists only RDW_NOERASE, RDW_NOFRAME (rather than RDW_FRAME), RDW_NOINTERNALPAINT, and RDW_VALIDATE. So, I will go ahead and submit this patch, and since it is small, just attach it here again. I have been using it with Wine for about 3 months now, so it does not appear to adversely effect anything. Probably a better fix would be to correctly implement the other flags, though. Changelog: RDW_FRAME should be ignored when validating a region. Index: windows/painting.c =================================================================== RCS file: /home/wine/wine/windows/painting.c,v retrieving revision 1.71 diff -u -r1.71 painting.c --- windows/painting.c 5 Jul 2002 01:23:31 -0000 1.71 +++ windows/painting.c 25 Jul 2002 00:44:15 -0000 @@ -779,15 +779,9 @@ OffsetRect( &r2, pt.x, pt.y ); hRgn = CreateRectRgnIndirect( &r2 ); } - else /* entire window or client depending on RDW_FRAME */ + else /* entire window */ { - if( flags & RDW_FRAME ) hRgn = 1; - else - { - GETCLIENTRECTW( wndPtr, r2 ); - hRgn = CreateRectRgnIndirect( &r2 ); - } } }

July 25, 2002

Re: Get number of bytes available in PeekNamedPipe (take 2)

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > PeekNamedPipe must report when the pipe is broken, otherwise some programs > wait forever for a message from the already disappeared program. Without > checking for a broken other end, FIONREAD always reports "0 bytes". I don't > see how I can doi that on the client side, beside exporting the > pipe(_user)_get_fd functions directly. Programming hints are welcome. OK, I was thinking this would be checked in read(), but I guess the app may never call read() if PeekNamedPipe returns 0 available bytes. You should be able to check for a closed pipe using poll() and testing for POLLHUP. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2002

Re: DTR / DTS vs RTS/CTS vs Wine

by list＠vmn.com.br

Hi Marcelo! Seems you are familiar with the problem! Yes, I am debugging a fiscal printer ! I was using sleep but I decided to look into the problem because sometimes you need to catch the signal, say if the printer runs out of paper, or whatever.... I am going to try the cable and then see what happens. Miguel Quoting Marcelo Welter <pouback(a)sysmo.com.br>: > Hi miguel > > If your are using a fiscal printers of brazilian producers. > > In wine the DTR/DTS are true everytime. Then you need stop your > application after eat command to wait printer get a ready status before > next command. > in delphi use SLEEP command to this. > > sorry per my english. > > see ya! > > Marcelo Welter > ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Duane Clark

Duane Clark wrote: > > Ahh, that was one of the parts I mentioned that I didn't test because I > did not know how to. Please tell me what you do to generate this error. Oh, and please mention exactly which version of Winzip. Thanks

July 25, 2002

Re: DTR / DTS vs RTS/CTS vs Wine

by Marcelo Welter

Hi miguel If your are using a fiscal printers of brazilian producers. In wine the DTR/DTS are true everytime. Then you need stop your application after eat command to wait printer get a ready status before next command. in delphi use SLEEP command to this. sorry per my english. see ya! Marcelo Welter

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Duane Clark

Tony Lambregts wrote: > > It seems that one of the patches to shlexec.c has broken WinZip. The > following is a trace from WinZip from this morning. > > > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:listview:LISTVIEW_UnsupportedStyles !LVS_SHAREIMAGELISTS > err:shell:SHGetFileInfoA pidl is null! > fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405b689c > err:shell:SHGetFileInfoA pidl is null! > > I have been trying to debug this for a while and it did not have this > problem yesterday. If you want to download WinZip here is the url > http://www.winzip.com/ Ahh, that was one of the parts I mentioned that I didn't test because I did not know how to. Please tell me what you do to generate this error.

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Tony Lambregts

Alexandre Julliard wrote: >Duane Clark <dclark(a)akamail.com> writes: > > > >>Ouch, that version had some serious bugs. It would be much better to >>apply the version I posted to wine-devel, which I think works pretty >>good. >> >> > >Oops sorry, that was the one I intended to apply, I didn't notice it >was only sent to wine-devel. > > > >>I can supply a diff between this version and the fixed one, if >>desired. >> >> > >Yes please. > > > It seems that one of the patches to shlexec.c has broken WinZip. The following is a trace from WinZip from this morning. fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented fixme:listview:LISTVIEW_UnsupportedStyles !LVS_SHAREIMAGELISTS err:shell:SHGetFileInfoA pidl is null! fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405b689c err:shell:SHGetFileInfoA pidl is null! I have been trying to debug this for a while and it did not have this problem yesterday. If you want to download WinZip here is the url http://www.winzip.com/ Tony Lambregts

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Max

Tony Lambregts wrote: > > It seems that one of the patches to shlexec.c has broken WinZip. The > following is a trace from WinZip from this morning. > > > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:listview:LISTVIEW_UnsupportedStyles !LVS_SHAREIMAGELISTS > err:shell:SHGetFileInfoA pidl is null! > fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405b689c > err:shell:SHGetFileInfoA pidl is null! > > I have been trying to debug this for a while and it did not have this > problem yesterday. If you want to download WinZip here is the url > http://www.winzip.com/ Same problem, winzip is broken as explained; I tested it some days ago and it worked fine. Regards Max

July 25, 2002