Documentation fixes

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > What primarily intrests me now is how should the needed 
> information be
> > stored? The problem with normal entry point is solved, the 
> question is
> > how the stubs and forwards should be stored? Before we know that
> > we can't really write any working extraction tool can we?
> 
> Sure we can, that's the easy part; the hard part is making it work for
> the normal entry points. And I'm not going to add anything to support
> stubs etc. until it's clear that we can do it for normal entry points
> in a way that I consider acceptable.

Fair enough. However note that I'm not suggesting that we shuld.
I said "While we probably should not actually change the .c files to 
look like this until we have a tool of acceptable complexity
that can generate the .spec files, there is quite a few preparations
that need to be done before that"

But OK, I will concentrate on supporting normal entry points
in an acceptable way first.

> > While we probably should not actually change the .c files to 
> > look like this until we have a tool of acceptable complexity
> > that can generate the .spec files, there is quite a few preparations
> > that need to be done before that and I would really like to have the
> > "Exported external functions" patch applied in the meantime
> > for other reasons like winapi_check likes to know where all
> > the DLL:s functions are "implemented".
> 
> Then fix winapi_check. I don't want to have to add a bunch of external
> declaration for C library functions, that's very ugly.

First of all ugly is subjective, I can't see what is ugly about it,
but OK you decide what you want, so arguing that point is no use.

However I'm a little curious where the documentation, 
and yes I'm talking about real documentation not just
the external name and the ordinal, should be placed.
Sure you have the underlying Unix man pages at least 
if we are talking about the MSVCRT and NTDLL functions,
but it would be nice to have a proper Windows style
man page for them eventually. Perhaps the some of the
functions have some limitation in Windows that the
Unix variant doesn't have (or vice versa) and thus if
you extend the Winelib application you really want to
know that, so the Unix man page will not really be
enough.

So yes, I'm really curious to know where you think the
documentation should be placed. I think my solution
is quite good since it solve three problem.
1. Provides somewhere to write the documentation
2. Provides a C compiler checkable prototype that can
give a warning if any of the native system functions
happends to have another prototype.
3. Helps tools like winapi_check a place to check things
that the .spec files entries are correct.

Even if you still considers it ugly, it might be worth it
considering what you get.

> So no, I'm not
> going to apply your patch.

I can't fix winapi_check properly. I can kludge it yes, but fix no.

There is no implementation or anything else in the source that 
indicates that it is supposed to use functions from another DLL.
But sure I can kludge winapi_check to ignore the atom functions
and lstrcmpi in USER. The functions from the C Library is
already kludged since a long time ago, so what the hell
lets just add another kludge, it is only 5 new functions.
If you don't apply it I don't have much choice have I.