On Sun, 18 May 2003 11:18:52 +0200, Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Sounds like we definitely have a problem here. The more advanced Wine gets, the more it gets set back by introducing a newly stubbed out system DLL, thus it's a real problem.
Is there any "really" good solution to this which is better than having to submit complete, finished and fire proof DLL implementations? ;-)
What about adding a flag to the function information that says what the status of a DLL/function is? For stubs this can be automatically done by winebuild and this it can be tracked which functions are proven to be working ok. You can do this either on function level or on DLL level. This way you could also evaluate this flag at runtime which would make it easier to use for people that are not developing on wine. It will also be easier to track which functions are fully implemented, which one are partialy, etc.
Maybe we should introduce some kind of communication bit that tells the Wine loader that this DLL is "dangerous" and the native version should be used if possible? (if that's even possible or useful)
Possible it would be. :)
That way it'd even work for all people that have a setting defaulting to builtin and never upgrade their config file.
I always use native because I refuse to use original DLLs, as long as they are part of the core Windows. My aim is to run wine without any stuff from MS. Anything else I consider pointless, but for other people that may be different. :)