Maybe we could add specific entries to the config file to set these new DLLs to native?
This would seem to be mostly a packaging issue - when people do little more than track CVS snapshots, stuff like like this *will* cause problems.
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).
Exactly. I think the real solution to this is to get Wine 0.9 out and then from then on do regular, "real" releases, ie that are somewhat sanity tested - 0.9.1, 0.9.2, 0.9.3, 1.0, 1.1 and so on. Not necessarily regression tested against lots of apps, though that'd be nice, just a case of "hmm, does this work". Then the package would merge a new registry for default entries. User-specific overrides in the winecfg tool would be the way users choose native vs builtin.
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.
That's always been the case though, at first introducing a new builtin dll might cause regressions. It's still better than no builtin DLL at all.
Is there any "really" good solution to this which is better than having to submit complete, finished and fire proof DLL implementations? ;-)
Submitting them is not really possible. I think the best solution is to split the builtin/native settings into 2, one which is controlled by wine/packaging then with user overrides if needed.
thanks -mike