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