Documentation fixes

[Alexandre Julliard]

Patrik Stridvall <ps at leissner.se> writes:

> > 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.

Actually no, the atom functions are similar to lstrcmpi, they are
exported from kernel so we don't need to link to libkernel32.so to get
them (and they shouldn't have USER comments either). The real problem
is the internal kernel functions called by user, things like
THUNK_Alloc or LOCAL_Alloc.

> 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?

Well, it's a more general problem, namely that the spec files can
reference functions that are not implemented directly in the dll.

You also have for instance:

@ cdecl strcpy(ptr str) strcpy

in MSVCRT, and strcpy is clearly not implemented there since it's in
the C library. So you cannot assume that only the functions contained
in the dll can be used in the spec files, it is legal for the spec
file to reference external functions.

> 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?

You'll need a file somewhere that specifies all the entries that
cannot be determined automatically from the source. You simply cannot
build a 100% correct spec file based only on the function comments.
And you definitely do not want to need to parse KERNEL source files
(like the ones in memory/) to build the USER spec file.

-- 
Alexandre Julliard
julliard at winehq.com