[PATCH 4/4] d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame3

Stefan Dösinger stefandoesinger at gmail.com
Tue Mar 31 18:59:04 CDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

Am 2015-03-31 um 23:44 schrieb Stefan Dösinger:
> I'll do a few experiments with these interfaces myself. I am still
> a bit puzzled by IDirect3DRMObject(2), and in particular the Clone 
> method, which apparently allows these objects to be aggregated.
I've satisfied my curiosity for now. It seems that
IDirect3DRMObject::Clone always returns a new object. When the
UnkOuter parameter is NULL this is relatively straightforward. It gets
funny when aggregation is used: The only way the caller can get his
hands on the inner IUnknown is to pass IID_IUnknown as iid parameter.
If the caller passes anything else there's no way he can release the
inner object once his outer object is destroyed.

I checked the theory that the inner object destroys itself when the
outer unknown's Release method returns 0. This is not the case. It
would be a fairly shaky setup after all - maybe the final Release call
is called on one of the outer object's vtables directly, rather than
through an inner vtable.

Finding out whether the clone is a deep copy or not is left as your
exercise. Also, no guarantees that my findings are complete or free of
errors.

What does this mean for your patches? Since you're not implementing
Clone() for now not too much. Please port the tests to d3drm1 and 2
and add tests for which interface pointer is returned when
IDirect3DRMObject, IDirect3DRMVisual and IUnknown are queried.
Properly testing all the details of Clone and aggregation is something
that can be done later.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVGzTIAAoJEN0/YqbEcdMw/EAQAIkFiLYPy48zY0qEOXNj4wKf
0dTtBJCre9Z4QcMk2WqpPFEvza6xxnEPLZQLq1P3oQQ+zmtVn0RpMIEmuP54Pg+s
Gyr46R+vZiZXqSj+2MPoJ8GctOiWo4LvTL/OEScJffuQWZdJ+mc2vqaxElIgMOuH
HUkyAtB5tJAv0OMI2QxdCVoJMZ6vbphcFTBhuTQdxMuSdVvIc+xWuJEyj1/wnXf8
WMzQs5yTJ1oud4zbViVpg+2B4tQxmkjAYnvXtTmpth85kNsuwI+2C7OAc5sAnVwK
zk/80EdBacLJZwjnDnwMGS3eYnGO272sT1mWJT4img0VIuSUURtV9rgv197+BvPu
HsxJtsOFWLOGwiXBE1QoD7oMd+aDq7N1CwD0CsVlIEeUn5a4h9011NYShqWCZxCT
2kbY+axvplmU12HxjBA2NRYs/MfM9WjsaWQatjyRXVG9O2QkWmxFoprzfBqJfYtc
6ALzLKJdZ9cE4dXWIXFQ2rYrSAP3Ntd9Mum1TwaWbEWi/vpyknLyWvFouvxOWPeb
xz10/yrne2KisKSJVfbMMCQE918kGB8W7S6+IRv/omoaGOCnj1JqtsqANsiTmkt8
/Y7NhiZDmcwb3jKmjyIDKxYrDvFCVahmzyU06uuYtaGnfcrxYy4XQFyWM9YoDi2r
LKOZaYS91eUlGNg4Li0+
=mI5S
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list