September 2011 - Wine-Devel

Re: [2/3] cmd: Avoid checking whether we're in console mode for every read (try 2)

by Eric Pouech

Le 28/09/2011 01:01, Frédéric Delanoy a écrit : > --- > programs/cmd/batch.c | 9 ++++----- > programs/cmd/builtins.c | 4 ++-- > programs/cmd/wcmd.h | 5 +++-- > programs/cmd/wcmdmain.c | 21 +++++++++++++-------- > 4 files changed, 22 insertions(+), 17 deletions(-) actually, console handles have their 2 lower bit set you could use it to even simplify further the code A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Sept. 28, 2011

Re: [PATCH 1/2] mmdevapi: Don't fail if dwChannelMask is not set correctly

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14610 Your paranoid android. === WVISTAADM (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W2K8SE (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PRO (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000

Sept. 28, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Austin English

On Wed, Sep 28, 2011 at 11:55, Scott Ritchie <scott(a)open-vote.org> wrote: > On 09/28/2011 05:57 AM, Vitaliy Margolen wrote: >> On 09/28/2011 04:18 AM, Alex Bradbury wrote: >>> Do correct me if I'm wrong here, but users who don't want regressions >>> in their favourite apps/games should be using the stable release. It >>> doesn't seem fair to complain about regressions being ignored unless >>> 1.4 releases with a significant number of them. >> >> If Wine would release stable versions every 3-4 months sure. But last >> stable version released on April 8. And only contains small number of >> fixes since wine-1.2 which was released on July 16. >> >> Many programs don't work with wine-1.2.3 for number of reasons. Besides, >> everywhere (forum, bugzilla, irc) we tell users to upgrade to latest >> development version, because we not going to fix any bugs in old >> "stable" versions. >> >> > > There's a reason I've consistently been advocating for more frequent, or > even regular, stable releases. We don't need fancy big features to > justify a release, mere apps working is enough. There's no reason you (as a package manager) couldn't choose a particular development release and mark it as stable in your distribution. E.g., Fedora does this, currently has wine 1.3.21, unless you enable updates-testing, which has 1.3.29. In any case, I think this topic is best reserved for discussion at Wineconf, especially since it's not that far away ;). -- -Austin

Sept. 28, 2011

Re: winecfg: Remove driver selection from Audio tab.

by André Hentschel

Am 28.09.2011 15:09, schrieb Vitaliy Margolen: > On 09/28/2011 05:31 AM, Michael Stefaniuc wrote: >> Vitaliy Margolen wrote: >>> On 09/27/2011 12:17 PM, Michael Stefaniuc wrote: >>> Wine is driven by wrong objectives. Most developers here don't give much >>> rip about regressions if the code they've put in is "right". This is >> Yes, sadly there are Wine developers that consider regressions they have >> introduced "just normal bugs" which they will fix eventually if they are > My suggestion would be to revert those "fixes" unless said developers willing to fix what they broke. Linus was pretty clear that he won't accept patches from such developers. Complete 180 from Alexandre's view. Still Linus isn't our projectleader, but AJ. And AJ was pretty clear he won't do reverts everytime somethings wrong, but will look for a fix. And AJ does his job for Wine nearly as long as Linus does for Linux and look where Wine is today, so i don't see the point for quoting Linus in that discussion. -- Best Regards, André Hentschel

Sept. 28, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Scott Ritchie

On 09/28/2011 05:57 AM, Vitaliy Margolen wrote: > On 09/28/2011 04:18 AM, Alex Bradbury wrote: >> Do correct me if I'm wrong here, but users who don't want regressions >> in their favourite apps/games should be using the stable release. It >> doesn't seem fair to complain about regressions being ignored unless >> 1.4 releases with a significant number of them. > > If Wine would release stable versions every 3-4 months sure. But last > stable version released on April 8. And only contains small number of > fixes since wine-1.2 which was released on July 16. > > Many programs don't work with wine-1.2.3 for number of reasons. Besides, > everywhere (forum, bugzilla, irc) we tell users to upgrade to latest > development version, because we not going to fix any bugs in old > "stable" versions. > > There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough. -Scott

Sept. 28, 2011

Re: browseui/tests: Skip some tests if IEnumACString is not supported.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14608 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154 === WXPPROSP3 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K3R2SESP2 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === WVISTAADM (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K8SE (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PRO (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Erich Hoover

SetRawValue is at the end of the table, so it being extra will not influence any older application. So, you should be able to get the same functionality with way less code by adding that alternative GUID to the QueryInterface in d3dx9_36. Erich Hoover ehoover(a)mines.edu

Sept. 28, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Vitaliy Margolen

On 09/28/2011 05:31 AM, Michael Stefaniuc wrote: > Vitaliy Margolen wrote: >> On 09/27/2011 12:17 PM, Michael Stefaniuc wrote: >> first place. It would be much better to see the entire conversion to >> mmdevapi in a separate tree stabilized before making it's way to main tree. > Like in a development tree? The Wine 1.3.x tree is a development tree. > Also how many people would you think would use that extra mmdevapi tree? > One? Two? So you'll get the same untested code merged at a later time. I'd expect most developers to test it it. Or at least those who interested in the specific area. Some users, especially those who reported errors about sound would be pointed to that tree as well. So it will get testing. >> Wine is driven by wrong objectives. Most developers here don't give much >> rip about regressions if the code they've put in is "right". This is > Yes, sadly there are Wine developers that consider regressions they have > introduced "just normal bugs" which they will fix eventually if they are My suggestion would be to revert those "fixes" unless said developers willing to fix what they broke. Linus was pretty clear that he won't accept patches from such developers. Complete 180 from Alexandre's view. > interested. But there are a lot of other developers that fix the > regressions they have introduced with a hight priority. I venture to say > that most Wine developers prioritize regression bugs above normal bugs. Unfortunately no one goes back and fixes those other regressions. Many users quit using Wine because of them. Not because of all other great stuff was added to Wine. > And no, Andrew's code is *NOT* "right" by any means! If we preferred the > "right" code we would have taken Maarten's code which nuked dsound out More so reasons to have a separate tree to stabilize it before merging with main line. > Again this is an 1:1 backend replacement with feature parity on the I think not! Andrew's biggest desire was to drop hardware acceleration support. The only part that actually did work and produced best sound. >> I'd like you guys to think about what really is important users or code? > Users. But you seem to prefer the old code... I prefer working code, regardless of it's age. What I really like to see is stable Wine versions being released more often if you think that the development tree is the right place to test nuclear options... - Vitaliy

Sept. 28, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Vitaliy Margolen

On 09/28/2011 04:18 AM, Alex Bradbury wrote: > Do correct me if I'm wrong here, but users who don't want regressions > in their favourite apps/games should be using the stable release. It > doesn't seem fair to complain about regressions being ignored unless > 1.4 releases with a significant number of them. If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16. Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old "stable" versions. -Vitaliy

Sept. 28, 2011

winecfg: Remove driver selection from Audio tab.

by Joerg-Cyril.Hoehle＠t-systems.com

Alex Bradbury wrote: >Do correct me if I'm wrong here, but users who don't want regressions >in their favourite apps/games should be using the stable release. There's some chicken and egg problem. 1. Users find bugs in the stable release. 2. Should they ever report a bug, they'll be asked whether the "unstable" version is still affected, hence: => "nice" users (these who report bugs) end up using the "unstable" version, which they may not have wanted to run originally. 3. Furthermore, these users are expected to re-check the "unstable" version from time to time. Perhaps the Wine Wiki should explain extremely well how people can keep 2 versions of Wine side by side, esp. when using distros. - one to play games; - another to play with bug reports. Then one should explain very well why these people should invest time to maintain 2 versions of Wine. Probably the Wine bugzilla should explain why users are expected to do all this. I guess it's based on the number of users: with so many users, you can't expect the few devs to fill holes in bug reports. The users need do more work than when filing a bug on a project with few users where the devs may spend a lot of time on each individual bug report. If this were explained, perhaps more people would be willing to help (instead of writing a short note to the forum). Well, maybe the Debian way is excellent: ideally, Debian "stable" would contain a particular release of Wine which has proven very good overall (not necessary 1.2.x). For instance, on the Mac with nVidia, 1.1.24(!) is still an excellent choice. Regards, Jörg Höhle

Sept. 28, 2011