dsound: Avoid using the COM method implementations directly.

[Michael Stefaniuc]

On 09/05/2016 11:54 AM, Henri Verbeet wrote:
> On 5 September 2016 at 10:04, Michael Stefaniuc <mstefani at redhat.com> wrote:
>> On 09/05/2016 09:50 AM, Henri Verbeet wrote:
>>> On 5 September 2016 at 09:39, Michael Stefaniuc <mstefani at redhat.com> wrote:
>>>> On 09/02/2016 07:17 PM, Andrew Eikum wrote:
>>>>> I guess I'm not opposed to this, but are these changes useful?
>>>> It makes the code consistent aka one way to call the COM methods.
>>>>
>>> I'm all for consistency, but these do different things. One calls a
>>> method from an interface that may have different implementations, and
>>> the other calls a specific function/implementation. Other than taking
>> Right, and by using the COM macro it is always guaranteed that the
>> correct method implementation is used.
> At the cost of making it less obvious what that implementation
> actually is. I'll also note that for ddraw in particular it isn't
> necessarily always safe to change from one variant to the other. There
> are applications that modify the call tables to install their own
> hooks, and picking one variant or the other would make those hooks get
> called or not for internal calls.
> 
>> And by consistent I mean that we don't have IFooImpl_AddRef() paired
>> with IFoo_Release() like in the bulk of diff that my script generated.
>>
> If a large part of the diff is in D3D code, I'd question whether
> that's really the bulk of the diff. But sure, that's awkward. If you
I have mentally excluded ddraw as that stands out. The bulk of the
patches I would submit would just fix a  "dangling" AddRef or Release.
Some of those look like copy and paste from the wrong example code than
any deeper reason.

> have an implementation pointer I'd argue you should just use
> IFooImpl_Release() as well in those cases though.

bye
	michael