August 2006 - Wine-devel - list.winehq.org

Read to 0x7ffe02c0
by Juan Lang 22 Aug '06

22 Aug '06

Hi folks, I'm trying to debug an access (by native userenv.dll in my case, but also by MS Money 2006) to address 0x7ffe02c0. This is my understanding so far: The TEB is at 0x7ffe0000, so, according to winternl.h, offset 0x02c0 within it is in the middle of GDI_TEB_BATCH. That doesn't make any sense to me. Anyone have any idea what's going on? Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 7

Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
by Raphael 22 Aug '06

22 Aug '06

On Monday 14 August 2006 19:57, you wrote: > Hi Raphael, Hi Roderick, sorry for late response i was in holidays (and before that a long moving to my new apartment) > I'm not sure how well you are monitoring the wine-devel lists these days, > so I'm also directing this mail directly to you. I have been trying to fix > various problems in the Wine OpenGL code. See the attached email and the > patch for more info. > > Basicly I changed the opengl code to only advertise the format of wine's > main visual. I think the changes I made are more or less correct to > Alexandre changes like this sounded correct aswell. But as he isn't an > OpenGL expert he wanted to know the opinion of others and especially from > people who know the code well. > > I already asked Lionel but he said that he isn't that familiar with the > current code which you rewrote a while ago. To Lionel the format > advertising change sounded correctly aswell although he hasn't checked the > code. > > Could you comment on the patch? (reply to the wine-devel list) > > Regards, > Roderick Colenbrander > > -------- Original-Message -------- > Datum: Mon, 14 Aug 2006 17:04:52 +0200 > From: "Roderick Colenbrander" <thunderbird2k(a)gmx.net> > To: wine-devel(a)winehq.org > Subject: RFC: OpenGL x11drv rewrite (WoW fix) > > Hi, > <snip> For me your patch seems correct Anyway the problem is you can add regression in cases: - application want a very specific needs that isn't compatible with current selected visual (use of SetPixelFormat before first CreateContext, now you don't care about user wanted PixelFormat) - application wants to create many context with not compatible pixel format (supported on windows) So you may restore many of the original problems but fixed the more problematic problem of BadMatch :) What it'll be interesting to do next is to move all low-level GLW/GLX utilities calls to x11drv to permit better access to x11drv internals (and to permit better portability on non GLX os, and better share with wined3d). This will help a lot for the famous bug of openGL chils windows. And after that, when user use the SetPixelFormat API, find a way to change the default created wine visual (use of SetPixelFormat is only permited once on windows). The problem is that visual is created by default before the application specify it's needs (ie. when the windows is created). We have the same problem for WineD3D, many games create a window and after want to choose a specific frame buffer (and if not compatible with current visual -> problem) I wanted to delay this visual creation (or better dynamically change this on X, if permited) but no chance (same problem for glwShareLists) :( Keep your good job :) Best Regards, Raphael

5 10

Re: [TRY 2] XEmbed System Tray Support
by Alexandre Julliard 22 Aug '06

22 Aug '06

James Liggett <jrliggett(a)cox.net> writes: > + /* fall back to he KDE hints if the WM doesn't support XEMBED'ed > + * systrays */ > + > + /* Put the window back within the screen so it will be mapped */ > + SetWindowPos( data->hwnd, NULL, 0, 0, 0, 0, SWP_NOZORDER | SWP_NOSIZE ); It would be nicer to create the window with normal coordinates, and only move it off-screen when needed, instead of having off-screen be the default behavior. It would also avoid having explorer know about internals of the systray implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/9] DDraw: Make IDirectDrawImpl thread safe
by Alexandre Julliard 22 Aug '06

22 Aug '06

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > @@ -245,11 +252,12 @@ void > IDirectDrawImpl_Destroy(IDirectDrawImpl *This) > { > IDirectDrawImpl *prev; > + DDOBJ_LOCK(This); You shouldn't need locking in Destroy, if the refcount is zero no one else can be using the object. > for(prev = ddraw_list; prev; prev = prev->next) > + { > if(prev->next == This) break; > + } > > if(prev) > + { > + DDOBJ_LOCK(prev); > prev->next = This->next; > + DDOBJ_UNLOCK(prev); > + } You can't lock just one object, you have the protect the whole list. -- Alexandre Julliard julliard(a)winehq.org

1 0

opengl pixel format regression
by Stefan Dösinger 22 Aug '06

22 Aug '06

Hi Roderick, Your pixel format patches caused a regression in half-life 1 for me with the fglrx drivers. It refuses to start in opengl mode and reports "ChoosePixelFormat failed", and then comes up in software(ddraw) mode. The d3d mode still works fine. This problem also does not occur with the open source radeon driver. I tested with fglrx 8.28.8 and fglrx 8.27.10. Other games seem to work fine(appart of a few fglrx bugs) What infos do you need to debug this? This is the format table glxinfo reports: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None

3 2

wine and other xservers
by Vijay Kiran Kamuju 22 Aug '06

22 Aug '06

Hi, How does wine work/perform with other opensource X servers, like nano Xserver. Thanks, VJ

1 0

Re: Using winehq to store patches that have not yet got into the wine code
by Tony Lambregts 22 Aug '06

22 Aug '06

Nick Law wrote: > Hi Tony / Chris > > Is there someway of storing a patch on the winehq/appdb domain so that > I can put a link on the APPDB page to it, rather than use links to > other places like thehandofagony (which doesn't look like the sort of > place we should be using). I've been using rapid.de (I think it's > called which I can carry on doing, which gives you download stats). > However I thought as we store screenshots it would be nice to store > patches approved by the maintainers (prior to be incorporated into the > code, or the code fixed). > > Regards > Nick Law > There are a number of places that patches can be stored within winehq. The first place that you could store them is in the wiki like http://wiki.winehq.org/InterestingPatches, or if they fix/hack around a bug in the application then you can start a bug report and attach the patch there and link back to it. Finally you can submit a patch to wine-patches(a)winehq.org and link to the archive. http://www.winehq.org/pipermail/wine-patches/ ie: http://www.winehq.org/pipermail/wine-patches/2006-August/029455.html I do not know what the best way is but I tend to favor the wiki.

1 0

Re: crypt32: work around an apparent compiler bug
by Robert Shearman 22 Aug '06

22 Aug '06

Juan Lang wrote: >This seems like voodoo to me too, but the combined condition if statement >would always fail for me, while two distinct if statements succeed. > >ChangeLog: >- add a couple traces to make following execution easier >- expand an if condition to work around an apparent gcc bug > > >- if (HIWORD(function->entry.pszOID && >- !strcasecmp(function->entry.pszOID, pszOID))) > > Looks like HIWORD(function->entry.pszOID is just missing a closing bracket to me. -- Rob Shearman

2 1

Re: wined3d: print real unhandled D3DCMPFUNC value
by Jan Zerebecki 21 Aug '06

21 Aug '06

On Sun, Aug 20, 2006 at 01:37:04PM -0700, Chris Robinson wrote: > --- dlls/wined3d/device.c 10 Aug 2006 09:43:54 -0000 1.275 > +++ dlls/wined3d/device.c 20 Aug 2006 20:31:10 -0000 > @@ -3666,7 +3666,7 @@ > case D3DCMP_GREATEREQUAL: glParm = GL_GEQUAL; break; > case D3DCMP_ALWAYS: glParm = GL_ALWAYS; break; > default: > - FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", Value); > + FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", This->stateBlock->renderState[WINED3DRS_ALPHAFUNC]); (I forgot if I verified this, but) I think that when a state is beeing set This->stateBlock->renderState[State] has the previous value and only Value has the one to be set. From a quick glance it seems the code for this renderstate (and maybe more renderstates) wrongly assumes the contrary. Jan

3 2

KDE wineconfig module & audio
by Yuriy 21 Aug '06

21 Aug '06

Hi, I'm creating a KDE guidance module for wine. I'm stuck on something. winecfg tries to open each audio driver to get a list of available drivers. So far, I've just put in the list of all possible drivers, but I want to get a list consistent with winecfg. I don't know how to go about testing which drivers are available. I'm using regedit for settings, so I'm not linking to wine so I can't just use the function(s) provided in wine. Also, I'd like to put in a button to test if sound is working. Is there any software included in wine to play a wav? It needs to be something that would be installed by default when wine is installed, rather than something that's just in the source like the tests in winmm. Thanks for any help ~Yuriy

3 3