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

How to mantain complete CVS repository

by Max

I downloaded complete CVS wine repository, but the instructions on how to use CVSUP to mantain it up to date are not complete (for me at least !). Can anybody explain me how to do it ? Thanx in advance Max

July 25, 2002

Re: Dinput - Keyb Bug

by Sylvain Petreolle

> i tried to use native ddraw.dll but then the game won't even start, > there's > just a black screen. > ddraw.dll can't be used as native, it has too much hardware functions. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

July 25, 2002

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

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> As I don't have a test target, I don't feel yet like filling >> lpvBuffer and I don't yet have an idea how to do that. I looked at >> the kernel sources and lseek unconditionally returns error on >> pipe. So how can we read the pipe and get the filepointer back to the >> original position afterwards? Alexandre> You can't use lseek, you have to make the pipe a socket pair Alexandre> and use recv(MSG_PEEK). >> wine/server/protocol.def Define a FD_TYPE_PIPE wine/server/file.c: >> get_handle_fd On type FD_TYPE_PIPE check other end of type Alexandre> If this is really necessary it should be done on the client Alexandre> side. I'm not sure I see the point though. 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. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 25, 2002

dos console apps question

by Chris Morgan

Lately I've been trying to get some dos console apps running under wine. These apps run great under wineconsole but not so much just under wine due to the lack of a server side console for the routines in dlls/msdos/vga.c to output too. So, after poking all around it seems that at some point during the normal loading of an app that we should be calling out to the server with alloc_console to create a default console, and binding this console to the current terminal. Does anyone have any suggestions about this? What function this should be done in? Thanks, Chris

July 24, 2002

Re: Procite and Wine

by Duane Clark

On c.e.m.w Uwe Bonnes wrote: > Duane Clark <junkmail(a)junkmail.com> wrote: > : This is a multi-part message in MIME format. > : --------------040608050206010706050208 > : Content-Type: text/plain; charset=us-ascii; format=flowed > : Content-Transfer-Encoding: 7bit > > : Duane Clark wrote: > :> ... > :> Try this simple patch and see if it fixes it: > :> ... > > : Hmmm, that came out kind of poorly. Here it is as an attachment. > > This makes the the java application ChipView from the Xilinx webpack much > more usable (beside all those deficencies you expect form a java > application: delay and exceptions..) > > Please discuss (again?) on wine-devel. > > Bye Okay (switching from c.e.m.w to wine-devel), this had not yet been discussed on wine-devel, nor had I submitted the patch. It was one of those things I did awhile ago, and was going to look into more, but never got around to. I found this problem on two applications, and now it is apparently showing up on two more. On c.e.m.w Dong Wook Ko wrote: > Does anyone know where I should look for in order to use procite under wine? > > I got procite installed, and it sort of runs, but I can see it's > flickering very quickly, and my console is flooded with the same error > message: > > err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 30a4! > > And I cannnot open individual index of the bibs. > > Any help would be grateful. > > ps. If anyone could tell me how to export procite into bibtex, I won't > have to bother with this... > I have seen this in two other programs. The problem appears to be here, at about line 779 in windows/painting.c: else /* entire window or client depending on RDW_FRAME */ { if( flags & RDW_FRAME ) hRgn = 1; else { GETCLIENTRECTW( wndPtr, r2 ); hRgn = CreateRectRgnIndirect( &r2 ); } } 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. This rather simple patch appears to fix things, but I did not submit it because it did not completely clear up the screen corruption (for example testing on Kaleidegraph, for which a free download is available somewhere...), though it did stop this bug: 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 24, 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: > As I don't have a test target, I don't feel yet like filling lpvBuffer and I > don't yet have an idea how to do that. I looked at the kernel sources and > lseek unconditionally returns error on pipe. So how can we read the pipe and > get the filepointer back to the original position afterwards? You can't use lseek, you have to make the pipe a socket pair and use recv(MSG_PEEK). > wine/server/protocol.def > Define a FD_TYPE_PIPE > wine/server/file.c: get_handle_fd > On type FD_TYPE_PIPE check other end of type If this is really necessary it should be done on the client side. I'm not sure I see the point though. -- Alexandre Julliard julliard(a)winehq.com

July 24, 2002

Re: Calling a winelib program (wcmd) from inside wine with arguments

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > how do I call a winelib programm with arguments from inside wine. I tried > several appoaches in a first hack for Batch file support in wine, but I > didn't succeed. It seemed that either the winelib programm insisted on the > "--" divider or it tried to interpret it. You must not add "--" when starting it inside Wine. Just build a normal command line and pass it to CreateProcess. -- Alexandre Julliard julliard(a)winehq.com

July 24, 2002

Re: DTR / DTS vs RTS/CTS vs Wine

by Mike McCormack

Hi Miguel, I'm pretty sure that Windows 95 and Windows NT's standard drivers both implement hardware flow control (DTR/DSR and RTS/CTS). Windows 3.1 may be a different story though... Mike mfeitosa wrote: > Mike, > > Thanks for a prompt answer! > I am going to test the cabling scheme and will send some info by the end > of next week. > Are you aware how windows implements hw flow control? > I read in the wine-devel history a comment that stated that windows > might not imlpement hw flow control at all. > This intrigues me because the printer does work on windows. > > Miguel

July 24, 2002

Re: DTR / DTS vs RTS/CTS vs Wine

by mfeitosa

Mike, Thanks for a prompt answer! I am going to test the cabling scheme and will send some info by the end of next week. Are you aware how windows implements hw flow control? I read in the wine-devel history a comment that stated that windows might not imlpement hw flow control at all. This intrigues me because the printer does work on windows. Miguel At 16:43 24/7/2002 -0500, you wrote: >Hi Miguel, > >You are correct; the Linux kernel does not support DTR/DSR flow control. >If a windows program requests DTR/DSR flow control in wine, we just write >a FIXME to stderr and ignore the setting. > >Your idea to build a cable that wires the printer's DTR/DSR to the >computer's RTS/CTS may work, but you may also need some small hacks in >wine to select RTS/CTS flow control when the program asks for DTR/DSR flow >control. That won't garantuee that your program works, but it will at >least be a little better... > >I guess the other option is to implement DTR/DSR flow control in the Linux >kernel... but that may not be easy :) > >Mike >

July 24, 2002

Re: Dinput - Keyb Bug

by Steven Edwards

> Also i fail to get opengl to work, i simply can't select it in game. Any > ideas? I've compiled with --enable-opengl and i've run a testprogram using > opengl which works fine. I was never able to get tribes to work in OpenGL on my Nvidia cards. I ended up using 2 voodoo2's in SLI under GLIDE mode to play, If you can get it to work in OpenGL let me know as I may start playing again =). As for your sound issues your on your own, I think it worked fine for me. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 24, 2002