-----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.