Robert Shearman rob@codeweavers.com writes:
Mike Hearn wrote:
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.
Obviously we can't blindly remove all stubs, each individual case needs to be looked at. But there aren't that many ordinal exports, and adding dummy functions for them shouldn't be that hard.
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.
Yes but that doesn't require winebuild support, a commented out entry in the spec file can serve the same purpose.
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.
Replacing stubs by real functions is a step in that direction IMO. At least this way we'll have prototype information that will make it more likely that someone starts working on the function.