How long for a patch?
Gerhard W. Gruber
sparhawk at gmx.at
Sun May 18 15:31:12 CDT 2003
On Sun, 18 May 2003 11:18:52 +0200, Andreas Mohr
<andi at 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
Für jedes menschliche Problem gibt es immer eine einfache Lösung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)
More information about the wine-devel