Documentation fixes

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > PS. And yes, the added lstrcmpi (USER.471) in memory/string.c
> > should really be there. Both KERNEL and USER uses the memory
> > directory.
> 
> No, USER does not use the memory directory. It links directly to
> libkernel32.so because it needs some internal functions in there,

Like the atom functions that are implemented in memory/atom.c I guess
you mean.

> but
> that's a different problem. lstrcmpi is a purely KERNEL function, that
> happens to be imported by USER (and by other dlls too), 

That might be so, but it is also _exported_ by USER:

grep lstrcmpi dlls/user/user.spec
471 pascal16 lstrcmpi(str str) lstrcmpiA

and lstrcmpiA is not implemented anyware else

The same goes for the atom functions:

grep Atom dlls/user/user.spec
268 pascal16 GlobalAddAtom(str) GlobalAddAtomA
269 pascal16 GlobalDeleteAtom(word) GlobalDeleteAtom
270 pascal16 GlobalFindAtom(str) GlobalFindAtomA
271 pascal16 GlobalGetAtomName(word ptr s_word) GlobalGetAtomNameA

> so USER must
> not be mentioned in the comment IMO.

The problem is that if I say that the memory directory doesn't
"belong" to dlls/user/user.spec winapi_{check,extract,fixup} will
not find implementations for all functions, which will cause
problems.

For example how should winapi_extract know that I should generate the line
471 pascal16 lstrcmpi(str str) lstrcmpiA
when it generates the spec files?

Of course the automatic generation of spec files is not 100% complete
most importantly handling of forwards and stubs is not supported.

I think that we need to move the solution of this problem one step
up the "ladder" and discuss the more general problem:
How should we store the information needed to generate
the spec files in the source, especially concerning
the forwards and stubs?

I will address this issue in a separate mail, but you are welcome
to add comments specific to this problem in this thread, 
I'm not sure I feel to writing it today. I have been
postponing the writing of mail for quite some time and
I'm currenly beginning to get rather tired.

PS. Why not as an interim solution simply add support for forward in
the Win16 spec files so 
471 pascal16 lstrcmpi(str str) lstrcmpiA
becomes 
471 forward lstrcmpi(str str) USER32.lstrcmpiA
which winebuild until actual need simply interprets as
471 pascal16 lstrcmpi(str str) lstrcmpiA

Hmm. Perhaps we should have forward16 and forward
to separate the pascal16 and pascal cases?

Anyway this gives winapi_{check,fixup} enough information to
handle the situation where the memory directory doesn't
"belong" to dlls/user/user.spec.