Stubs in PE build

[Robert Shearman]

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