Re: Ugly dclipper winapi_check hack

[Vincent Béron]

Le mer 20/04/2005 à 05:29, Francois Gouget a écrit :
> winapi_check assumes that all the functions declared in a given spec 
> file are implemented in a C file located in the same directory. This 
> seems to hold true except for DirectDrawCreateClipper() which is 
> implemented in a sub-directory.
>
> This causes winapi_check to not notice the DirectDrawCreateClipper() 
> implementation and to complain that it's missing. So I hacked it so it 
> also takes into account C files located in ddraw/dclipper/ for 
> ddraw.spec.
>
> 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.

Vincent

Ugly dclipper winapi_check hack

[Francois Gouget]

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.

Ugly dclipper winapi_check hack

[Alexandre Julliard]

Francois Gouget  writes:
> 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.

While you are cleaning things, it would be nice to finish moving the
code from tools/winapi_check to tools/winapi and get rid of the
winapi_check directory...

Ugly dclipper winapi_check hack

[Francois Gouget]

On Wed, 20 Apr 2005, Alexandre Julliard wrote:
> Francois Gouget  writes:
> > 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.
>
> While you are cleaning things, it would be nice to finish moving the
> code from tools/winapi_check to tools/winapi and get rid of the
> winapi_check directory...

Well, that hack seemed pretty easy but now it also seems not really 
necessary if the ddraw directory is about to get flattened.
Moving the code from tools/winapi_check to tools/winapi is way out of 
the scope of what I can/intended to do just now.

So if someone else wants to pick it up go right ahead.

winapi_check is a nice tool that can really turn up some issue in the 
Wine code. It just hasn't seen very much maintenance in the recent past 
and could use some love and care every now and then in order to work 
great. IOW I really think it's a worthwhile project.