[Mesa-dev] Mesa (d3d1x): d3d1x: add new Direct3D 10/11 COM state tracker for Gallium

[Luca Barbieri]

> The basic rule Wine uses is that if you've ever seen Microsoft code,
> you can't work on similar code for Wine.
OK, but that means source code as far as I can tell from the FAQ, not
SDK headers.
In this case, I'm not aware of any public Microsoft source code
implementing any of the functionality in question at all, except the
ATL and MFC implementations of IUnknown, which I haven't looked at and
I'm not even sure how they are designed.

> The only reason we can look at e.g. PSDK headers at all is because you
> can't copyright facts like constant values or structure layouts.
I don't see how the DDK headers are different from the Windows SDK
headers in this regard.
Also, DDK documentation is available online on MSDN, just like the SDK one.

> Also, at least a couple of years ago the license for
> the DDK explicitly restricted its use to Windows development. That's
> again something that may or may not hold up, but we're not going to
> try.

The current license does not attempt to restrict you from developing
alternative implementations.
It only attempts to prevent reverse engineering, disassembly and
decompilation, and does not grant you distribution rights under
copyright law in the case that you distribute Microsoft code to run on
non-Windows platform or license it under a copyleft license.

No Microsoft code is being the distributed, and no
disassembly/decompilation is required, since it's all documented
either on MSDN or in header files.

> Note that I've looked at neither the DDK nor your actual
> implementation. The fact that apparently you looked at the DDK while
> writing the code makes me cautious to avoid it.

I just looked at the d3d11TokenizedProgramFormat.h header because the
documentation on MSDN says that the shader bytecode format is
documented in that file (e.g. see
http://msdn.microsoft.com/en-us/library/ff540655%28v=VS.85%29.aspx).

Knowledge about DXBC has been obtained by reading the Wine code, but
none of that Wine code has been used, and again the code is structured
very differently.
Some LGPLed headers from Wine are distributed with changes, but I
believe it is OK because the rest of code is not a derived code of the
headers, since it could be compiled against the Microsoft headers as
well.