Patrik Stridvall ps@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