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