Hi,
On Sat, May 17, 2003 at 03:29:07PM -0700, Alexandre Julliard wrote:
"Gerhard W. Gruber" sparhawk@gmx.at writes:
I submitted a patch about a week (maybe more) ago to include a new DLL w95inf32 into wine. The patch has not been included and there was also no feedback as to why it is not included. How long does it usually take until a patch will be taken in? Or is there some other reason why this is not done?
I'd prefer that you write a bit more code before including it. Because we are using builtin by default now, a stub only dll is going to break every app that uses it.
If you meant a *bit* more code, then I'd agree. However I don't think that it's a good idea to only accept a new DLL if a major part of its infrastructure is implemented. OSS development is often about getting things done fast and in small steps, so this hinders this concept.
Maybe we could add specific entries to the config file to set these new DLLs to native? Hmm, ok, I guess your point was that most people have one specific Wine configuration file (which has builtin as default, incidentally!) and never care about updating their settings to match the Wine Configuration File Of Da Week (tm).
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? ;-)
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) That way it'd even work for all people that have a setting defaulting to builtin and never upgrade their config file.