On Wed, 20 Apr 2005, Vincent Béron wrote: [...]
If anyone has an idea for a better fix (or if you know of other APIs that should have the same problem) I'm all ears as I don't like this solution much.
If you're heading that way (a bit of spring cleaning of winapi_check), could you also look at how it thinks api names are unique? It complains about ValidateVertexShader (in d3d8 and d3d9), but that function takes 1 arg in d3d8 and 2 in d3d9. I'm not sure if it read one of the spec file before the other or what.
I had a look in this area in the past but it's really complex so I don't think I'll tackle it. I'll just tweak Wine and winapi_check to reduce the size of the winapi_check output so it's less overwhelming.
Here are some of the winapi_check shortcomings in case someone is interested in fixing them:
1) Type handling is wrong and this messes up the generated.c conformance tests. In particular there is no way to handle structs or unions nested inside a struct. This means these structures cannot be tested and that's a lot of them :-(
2) It does not find the implementation of functions declared with the DEFINE_REGS_ENTRYPOINT macro (e.g. MSVCRT__setjmp, _alloca_probe).
3) ValidateVertexShader() shows a problem with module matching because it has different prototypes in DirectX8 and DirectX9.
4) It gets easily confused when checking the documentation. Fortunately this can usually be fixed by adding empty but 'proper' documentation comments. However some errors, like the riched20 and richedit DllMain errors, are pretty mysterious.
I have roughly sorted these issues in their order of importance (in my view). In particular, fixing issue 1 would make it possible to add tests for a lot more types and make sure our structures have the right packing, that each field has the right size and is at the right offset. All these new tests would also exercise the compatibility of our headers with the Platform SDK ones. So if you have perl skills I think this is a good (if complex) issue to tackle.