[PATCH 1/5] d3dx9_36: Implement D3DXFileCreate. (try 3)

[Rico Schüller]

On 24.10.2012 19:39, Nikolay Sivov wrote:
> On 10/24/2012 19:02, Rico Schüller wrote:
>> On 24.10.2012 16:33, Dmitry Timoshkov wrote:
>>> Christian Costa <titan.costa at gmail.com> wrote:
>>>
>>>>>> +static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface,
>>>>> REFIID riid, void **ret_iface)
>>>>>> +{
>>>>>> +    TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid),
>>>>>> ret_iface);
>>>>>> +
>>>>>> +    if (IsEqualGUID(riid, &IID_IUnknown) ||
>>>>>> +        IsEqualGUID(riid, &IID_ID3DXFile))
>>>>>> +    {
>>>>>> +        iface->lpVtbl->AddRef(iface);
>>>>>
>>>>> Isn't there an appropriate xxx_AddRef() macro?
>>>>>
>>>>
>>>> No.
>>>
>>> Is there a reason why?
>>>
>> Yes, they are not in the headers which are supplied by the SDK (at
>> least not in the one I checked). I guess you have to ask ms why they
>> didn't add it. So I think we shouldn't add that in our headers.
> Actually I don't see why we can't add an .idl for it and let widl
> produce a header. It still will be accessible directly through vtbl
> pointer if someone feels like build with our headers. Header we're
> talking about d3dx9xof.h is small enough to be a first converted to idl
> imho, instead of adding more code that uses in SDK way. As an example we
> have dwrite.idl now that SDK does not provide.
>
I have nothing against it, we just need to agree on something.

Last time 
(http://www.winehq.org/pipermail/wine-devel/2010-June/084633.html) it 
was also criticized ... Do we care that some of our code eventually may 
be built with dxsdk headers? (That won't work for all dlls, but for 
some). How far do we go with compatibility?

Cheers
Rico