January 2005 - Wine-Devel - list.winehq.org

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...

by Dimitrie O. Paun

On Mon, Jan 31, 2005 at 08:26:24PM +0100, Alexandre Julliard wrote: > The bulk of the architectural work is done, yes. This is a big day then -- pretty cool stuff. > There are still many loose ends to tie up, and some missing > performance improvements. Plus of course fixing all the regressions > that this change will cause, notably with OpenGL... If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :)) -- Dimi.

Jan. 31, 2005

[d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem

by Paul Vriens

Hi, while trying to run a demo-app, I had a 'crash' I have the following (part of a) trace: trace:d3d:IDirect3DDevice9Impl_GetDepthStencilSurface (0x77e3d028)->returning ((nil)) default is stencilbuffer=((nil)) trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x499db0cd trace:seh:EXC_RtlRaiseException info[0]=00000001 trace:seh:EXC_RtlRaiseException info[1]=00000004 trace:seh:EXC_RtlRaiseException eax=00000004 ebx=499e232c ecx=00000000 edx=00000001 esi=77e3d028 edi=77ec8318 trace:seh:EXC_RtlRaiseException ebp=70ecf5ac esp=70ecf5a0 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210202 This is because IDirect3DSurface9Impl_AddRef is called with a NULL parameter. In d3d8/device.c this is checked in d3d9/device.c it isn't. The demo-app get's a bit further with this patch/hack, but I don't know if it's correct (or if it is correct in d3d8). Comments ? Cheers, Paul.

Jan. 31, 2005

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Cool. Does this mean that the window management rewrite is done? The bulk of the architectural work is done, yes. There are still many loose ends to tie up, and some missing performance improvements. Plus of course fixing all the regressions that this change will cause, notably with OpenGL... -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2005

Re: Recruit regression testers?

by Scott Ritchie

I can confirm that this patch fixes things, at least for DInput in Fallout THANKS! -Scott Ritchie On Sat, 2005-01-29 at 18:49 +0100, Carlos Lozano wrote: > El lun, 24 de ene de 2005, a las 10:39, Lionel Ulmer escribio: > > > Lionel, meanwhile, needs to digup his fallout CDs to debug the app :) > > > > Oh well, it's not exactly my CD that I need to find (I actually have a log > > showing the problem done with the Fallout installer on my CD), it's just > > that I need to find the time to do it. > > It is the line what did the regression. > > Regards, > Carlos. >

Jan. 31, 2005

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...

by Dimitrie O. Paun

On Mon, Jan 31, 2005 at 10:34:07AM -0600, Alexandre Julliard wrote: > Log message: > Only create an X window for top-level windows, not for child windows. > Get rid of the X client window too, it's no longer needed. Cool. Does this mean that the window management rewrite is done? -- Dimi.

Jan. 31, 2005

Re: [game] Running; Dark Reign - The future of war with Wine

by Mike Hearn

On Mon, 31 Jan 2005 16:23:49 +0100, Joachim Schiele wrote: > My question is where should I start to search for the mouse problem? Was there > a similar problem with other games in the past? Also note i've already tested > the DX grab and the DGA settings with no effect. Look at DirectInput, a +dinput trace should be OK. Apparently our DirectInput implementation isn't so hot ...

Jan. 31, 2005

Re: Help on Wine

by Mike Hearn

On Mon, 31 Jan 2005 14:34:23 +0100, Katia Maculan wrote: > Hello, > In the last few days I executed some tests to understand a segmentation > fault problem in my pcsdll library working with WineLib in RedHat 9. > I created: > - A little library pcsdll exporting a function that calls the TlsAlloc > function > - A little executable pcsmon that calls the exported library pcsdll > function and creates a window > Linking the library with the command > g++ -m32 -march=pentium-mmx -mcpu=i686 -g -shared -Wl,-soname=pcsdll.so > ...... I'm afraid you can't do this, you must use wineg++ not regular g++. The resulting library is only usable from Win32/Winelib applications. > when the pcsmon calls the library function the library obtains a > segmentation fault in calling TlsAlloc function. Yes, to use the Win32 API you must run it using Wine as a Winelib app or library. Anything else won't work. thanks -mike

Jan. 31, 2005

Re: Slick build output

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Alexandre Julliard wrote: > > >It's pretty trivial to write a make wrapper that massages the output > >into whatever form you prefer. > > Unless it's in CVS, only one person will benefit from it. That's not > the open-source way. Feel free to start a project on sourceforge for that. It's clearly not Wine specific and doesn't belong in the Wine CVS. > Ok, this is a problem. Does this mean you won't accept any patches to > the makefiles to convert to "slick" build output? No, I won't. Our makefiles are already complicated enough to not add such gratuitous complexity. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2005

Re: Slick build output

by Robert Shearman

Alexandre Julliard wrote: >Jason But <jbut(a)swin.edu.au> writes: > > >>- I have been a developer for 20 years and nothing frustrates me more than >>make output that is over complicated. I see the point of printing the full >>command line when developing and debugging the Makefile and the make process. >>Once this is fixed however, I prefer a simple output from make telling me >>what is currently being compiled, I don't need to see all output every time. >> >> > >It's pretty trivial to write a make wrapper that massages the output >into whatever form you prefer. > Unless it's in CVS, only one person will benefit from it. That's not the open-source way. >This way you get your preferred format >with every project you build, you don't have to impose your tastes on >everybody else, > If those tastes are shared by a majority of developers, then it shouldn't be a problem. > and you avoid adding complexity (and non-portable >code) into our makefiles. > > Ok, this is a problem. Does this mean you won't accept any patches to the makefiles to convert to "slick" build output? Rob

Jan. 31, 2005

Re: [wined3d] GUIDS for everything.

by Alexandre Julliard

Oliver Stieber <oliver_stieber(a)yahoo.co.uk> writes: > Hi, this patch provides guids for all the wined3d > interfaces. There not needed right now, but some > patches I'll be sending in depend on them. I don't think you want to add wined3d GUIDs to dxguid, they don't exist in the Windows one. IMO they should remain purely internal to wined3d and d3d8/d3d9. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2005