d3dx9_26: Add custom ID3DXEffect interface.

[Michael Stefaniuc]

On 09/28/2011 11:03 PM, Rico Schüller wrote:
> Am 28.09.2011 22:18, schrieb Erich Hoover:
>> 2011/9/28 Rico Schüller<kgbricola at web.de>:
>>> ...
>>> d3dx9_25 and 24 needs it's own implementation because it's not only
>>> the last
>>> function which changed and that way it would look the same for all
>>> forwarding effect interfaces in d3dx9_2{4,5,6}.dlls.
>> I'm not an expert on this area, but I'd be tempted to implement this
>> by having everything go through d3dx9_36.  I might be missing
>> something, but it seems like you could easily declare different
>> virtual function tables and switch to the appropriate one based on the
>> GUID passed to QueryInterface.
>>
>> Erich Hoover
>> ehoover at mines.edu
>>
> That's possible but D3DXCreateEffect needs to return the correct effect
> interface for the corresponding dll, too. The D3DXCreateEffect in
> d3dx9_36.dll doesn't know anything about which version it should return.
> So at least that function is needed 3 times. Maybe a QueryInterface in
> D3DXCreateEffect25 after the D3DXCreateEffect call should do the trick,
> but it breaks native d3dx9_36.dll in that case or the interfaces still
> need to be known to 24/25, 26 and 36 dlls, but don't have to be public.
> Well that would really make the code a lot smaller.
> 
> Sure the possible problem with the "wrong" supported GUID would then
> affected all d3dx9_xx.dlls. I'm fine with both versions. The question is
> what's more important, compatibility or code size? From a quick look now
Not making a mess out of COM else it will come haunt you ;)

> I don't think that the "compatibility issue" affects any app, but I
> couldn't prove it. I could only say, that only the corresponding
> interface is allowed by each dll.

bye
	michael