ddraw: Fixed last part of regression bug #13277

Jens Albretsen jens at albretsen.dk
Thu May 22 13:37:17 CDT 2008


On Thursday 22 May 2008 20:08:57 you wrote:
> Am Donnerstag, 22. Mai 2008 19:17:34 schrieb Jens Albretsen:
> > Well, as remember this the normal procedure of d3d, textures, surfaces
> > and streams is to hold on to ddraw/d3d until everything is destroyed or
> > the process is terminated.
>
> DirectDraw 7 does this, but DirectDraw (1) doesn't
>
> > Anyway I thought that the idea about fixing regressions is to fix them
> > for 1.0?
>
> Yes, but we can't fix them in an incorrect way. What happens to fix one app
> could break other apps
>
> > Ehh, where?
> > I see no test doing the following
> > 1. DirectDrawCreate
ref=1, myref=1
> > 2. CreateSurface
ref=1. myref=2
> > 3. Release DirectDrawObject from step 1
ref=0(release ddraw), myref=1
> > 4. Use the surface
crash, myref=1
> > 5. Release surface to release ddraw
dead, myref=0(release ddraw)
You're sure this is not the correct ddraw behavior, I have no way of testing 
this at home, only got windows at work.

> I think I once wrote a test that does this:
> DirectDrawCreate		
ref=1, myref=1
> CreateSurface
ref=1, myref=2
> DirectDraw_AddRef
ref=2, myref=3
> ref = DirectDraw_Release
ref=1, myref=2
> ok(ref == 1)
So this does'nt really get directdraw object released

> of course even if CreateSurface doesn't addref the publically visible
> refcount, it could still hold some internal reference to prevent the ddraw
> object from beeing destroyed. If that's the case, we need an additional
> test showing that the ddraw object survives even though it has ref 0

So what you're saying I should not use the public visible refcount and add a 
internal AddRef/Release so surfaces can keep ddraw alive this way.




More information about the wine-devel mailing list