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?
"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.
On 17 May 2003 15:29:07 -0700, Alexandre Julliard julliard@winehq.org wrote:
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.
ok. I was assuming this, so I didn't ask earlier. I only submitted this because I was asking before and somebody said I should submit it anyway because it is better to have it in the tree and somebody might improve on it.
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.
Is there any "really" good solution to this which is better than having to submit complete, finished and fire proof DLL implementations? ;-)
How about having a compilltion define for a "release build" where it would not build dlls that are really new but with out that switch/config it will compile witch means releases will not have them but developers versions will have then as they are only good for developers while new (of course some users compile from cvs like developers so we need to note that in all docs and mailing list if we do)
I seen something like this in other programs...
Anyway, Just a thought, Hatky.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
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
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. :)
-
Alexandre Julliard -
Andreas Mohr -
Gerhard W. Gruber -
hatky -
Mike Hearn