Mike Hearn wrote:
On Tue, 2004-12-14 at 15:41 +0100, Alexandre Julliard wrote:
Not adding the functions at all is even easier, and the results are
pretty much the same... As you noted, in general the only advantage of
stubs is that you get a better error message, but that would be fairly
easy to handle at the loader level. The problem with adding stubs
everywhere is that now we don't know which ones are really needed.
Hmm, you mean we could remove the spec file entries that apps never
actually link against?
I would like to remove the Callback* stubs in kernel32, that aren't linked to by any apps and aren't present in the WinNT kernel32.
Perhaps the first step then would be to implement support in winebuild
and the loader such that the list of stubbed functions is exported then
the loader can link imports from those to stubs generated on the fly. At
that point the winebuild support for stubs could be removed, and all the
@ stub entries also deleted in one go.
I think that's a step backwards. Look, for example, in shlwapi or shdocvw. There are stubs there that are exported by ordinal only in the native dll and so removing them would lose the name of the function. Not to mention that I've fixed one bug with nasty stack corruption caused by missing ordinal exports.
Also, I see the stubs in the .spec file as a really broad todo list. A stub in a dll that I am interested in working on tells me to look up documentation for that function and write a test for it, then implement it. I don't need an obscure application to let me know that it is unimplemented.
IMHO, the Wine project should be moving away from just-in-time implementing of functions and moving towards implementing *everything* (with some obvious exceptions). This is the only way a high percentage of applications will work on Wine.
Rob
