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