How long for a patch?

[Mike Hearn]

> 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