September 2011 - Wine-Devel

Re: winecfg: Remove driver selection from Audio tab.

by Vitaliy Margolen

On 09/29/2011 02:11 AM, Alexandre Julliard wrote: > Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: > >> The part you forgot is Linux (referring to kernel here) being the most >> successful FOSS project, used on super computers, stock exchanges, >> banks, etc. While Wine still in it's perpetual alpha-beta state, >> limited user base, and not recommended for production use. >> >> Not saying that AJ's ways are all that bad, but obviously not giving >> the same results. Don't you think it's time to change things up a bit? > > So what do you suggest? > I can think of few things can be implemented right away and see how it goes: 1. Longer release cycle. Lets start with 3-4 weeks and extend if needed. Allow any new features first week of the release cycle only. Next two weeks are bug fixes and stabilization before release. Or have same 2 week release cycle with every other release being release candidate and code freeze for the second 2 weeks to stabilize it. 2. All major changes (substantial code rewrites, new dlls (excluding stubs), core dll / server changes) should be submitted as a whole series. Alternatively available as an external tree. To not completely stop development of major features it should be ok for small trickle of changes like DIB which one by one replacing existing functionality. While still requiring same level of testing. Such changes should have complete design proposal sent to wine-devel for discussions, preferably prior to codding. Don't need diagrams but at a minimum explanation what is the plan, how it supposed to work, what's wrong with current code that can't be fixed. To not put all weight lifting on one person, person(s) most familiar with the area _have_ to review and approve before continuing. Even tho we don't have official maintainers, this might be the time to assign this responsibility. Example of major changes: dsound rewrites, substantial d3d changes, wineserver/ntdll/kernel/user. 3. All regressions should be treated as blockers. And fixed before next release. If a regression is in some other area then patch introducing regression, no patches should be accepted from anyone else to the area in question until this regression is fixed. Or a work around found. Of course this is just a suggested plan not set in stone. Just wanted to bring this up before Wineconf so people can think about it. Can continue the conversation there as well. -Vitaliy

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Dan Kegel

2011/9/29 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > Apparently a preliminary "make clean" seems to fix that issue. Sorry > for the noise. > Dan, did buildbot had those issues or does it do a 'make clean'? The buildbot always starts with a clean directory, so it won't catch problems like that :-(

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by David Kiefer

While this patch indeed fixes bug 2666, it also kills performance, at least with Age of Empires II. The frame rate in the menu for me is about one frame every three seconds and about 1 fps in-game. With the patch, the work previously done by X11DRV_DIB_MapColor is now done by X11DRV_DIB_GetNearestIndex. Unlike GetNearestIndex, MapColor avoids traversing the entire palette most of the time by reusing the previous index in the destination bitmap if the color has not changed. However, MapColor only checks for exact matches and returns the first palette entry if none was found, effectively causing bug 2666. A possible solution is to have MapColor call GetNearestIndex as a last resort instead. This both fixes the problem and results in acceptable performance. David

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Alexandre Julliard

Martin Wilck <mwilck(a)arcor.de> writes: > This will also be my last attempt to get this merged. Saying this is the best way to ensure that they won't be merged. Why would people spend time reviewing your code if you've already decided that you are not going to address the issues they find? -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2011

Favorite bug: deadlock preventing backtraces?

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

Dan Kegel wrote: >Sadly, no backtrace follows I've not had midi.ok crash on me, but now that you mention it, I've had occasional crashes of random reasons in various apps yet got no backtrace. I seem to remember that there have been times where backtraces would be produced more reliably. So perhaps 1/2 a suggestion would be to try how an older version behaves. It shouldn't matter with midi. But which older version to choose? Regards, Jörg Höhle

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Frédéric Delanoy

2011/9/29 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > I've also had some weird test failures running "make testclean && make > test" for patch 2 > batch.c:302: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 18 (got '0 ', wanted '0(a)space@') > batch.c:302: Test failed: unexpected char 0x65 position 0 in line 19 > (got 'error 9009', wanted '1(a)space@') > [and some additional messages] > Those are probably due to an issue with the testrunner, since the line > numbers aren't correct, and the test_cmdline.cmd works nicely when > test_builtins.* files are removed. > I'll look into that . Apparently a preliminary "make clean" seems to fix that issue. Sorry for the noise. Dan, did buildbot had those issues or does it do a 'make clean'? Frédéric

Sept. 29, 2011

winecfg: Remove driver selection from Audio tab.

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

Michael Stefaniuc wrote: >- We can directly motivate Andrew to fix those regressions "Oh, >regressions still open? No dinner for you tonight!". I still think Andrew deserves kudos for the vast amount of work he did. mmdevapi, winmm, DSound, ALSA, OSS and CoreAudio are a lot for one person to tackle! Which yields the question of how an open source project can do major changes. It didn't happen within the last 10 years, it happened now with financial backing from a commercial company, that's why his commits say "Andrew Eikum for CodeWeavers". Wine may have a very large user base, but there are very few "key" developers. There are more people at my family's meetings then at WineConf. The sound systems (wine's DSound, but also ALSA etc.) being a can of worms certainly raised the complexity. Any major change one does may reveal something previously hidden by double errors. This is not a pleasant situation and is clearly lowering patch creation rate. Reflecting what happened, the one major flaw in the process I've identified is lack of significant test upfront. The mmdevapi tests are ok for testing a COM component, but not an audio renderer. Had my mmdevapi tests been available earlier, it would have been clear that the current OSS and CoreAudio drivers are not ready for release. See bugs #28056, #28093, #28039, #28047, #27937. Regards, Jörg Höhle

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Frédéric Delanoy

Hi Martin, I reviewed your patches and have found some (minor) issues: * Your patches email line subjects should have '(try N') appended. I *believe* this is needed for the project leader patches handling scripts You can just sed the "git format-patch" generated patches for instance * PATCH 1/5 create mode 100755 programs/cmd/tests/test_cmdline.cmd create mode 100755 programs/cmd/tests/test_cmdline.cmd.exp These files are added as executable. They should be marked as non-executable since they contain/can potentially contain @keyword(a)s (e.g. @space@, @todo_wine@ which won't be recognized by a native cmd, but need to be processed beforehand). While one might argue that test_cmdline.cmd is executable, test_cmdline.cmd.exp definitely isn't. (this may be due to the fact the files were created on windows) * PATCH 2/5 - args = argc; + cmdline = WCMD_strdupW(GetCommandLineW()); + if (cmdline == NULL) { + SetLastError(ERROR_OUTOFMEMORY); + exit(1); + } Using SetLastError before exit(1) is a bit pointless IMHO. You'd better use something like WINE_ERR("Could not allocate memory\n"); * PATCH 5/5 The WCMD_parameter doc should remain in front on WCMD_parameter function That's all. Great work! I've also had some weird test failures running "make testclean && make test" for patch 2 batch.c:302: Test succeeded inside todo block: unexpected char 0x0 position -1 in line 18 (got '0 ', wanted '0(a)space@') batch.c:302: Test failed: unexpected char 0x65 position 0 in line 19 (got 'error 9009', wanted '1(a)space@') [and some additional messages] Those are probably due to an issue with the testrunner, since the line numbers aren't correct, and the test_cmdline.cmd works nicely when test_builtins.* files are removed. I'll look into that . Frédéric

Sept. 29, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Henri Verbeet

2011/9/29 Rico Schüller <kgbricola(a)web.de>: > 4. Implement each version on it's own, so each dll would get it's own code > base. This way all differences could be handled correctly. > > Thus the only version which would really work 100% is #4, but due to not > knowing the small differences and the huge amount of work which is needed, > #4 seems to be practically out of scope. We have to switch to that later if > we see no way to solve the version differences. It's probably not worth it if it's just a few functions and a couple of interfaces, but you could also create a static library like e.g. libwpp.

Sept. 29, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Rico Schüller

Am 29.09.2011 00:13, schrieb Erich Hoover: > On Wed, Sep 28, 2011 at 2:45 PM, Alexandre Julliard<julliard(a)winehq.org> wrote: >> ... >> In general it's better to have the individual dlls handle their own >> differences, instead of requiring d3dx9_36 to handle all the quirks of >> 20 different versions. > It sounded like we were only talking about some functions not existing > on older versions, but if that's not the case then I would definitely > agree. > > Erich Hoover > ehoover(a)mines.edu > Maybe I wasn't that clear about the topic. The effect interface from d3dx9_36 has one more function (SetRawValue) than the effect interface from d3dx9_26. Because of this difference the GUID is different. My proposed solutions are: 1. If we implement the GUID in d3dx9_36 it will break the usage of native d3dx9_36 on wine because native doesn't support that interface and the forwards will be broken. Of course you would be able to use native d3dx9_26 in that case, but I think that's tricky, because the user has to take care to choose the correct d3dx9_xx.dll for each app. An example where this would be problematic is CIV 4, it querys for the GUID26 which would fail if native d3dx9_36 is used (which is mostly needed for other missing functions for now). It also has the problem with the "small changes" as #2. 2. Make a wrapper for each ID3DXEffectInterface in d3dx9_xx.dll where it is needed. That way it works with native d3dx9_36.dll on wine. The wrapper includes the complete interface like it is done in my patch. Problem: The problem I see with this is that there may be small differences within the d3dx9_xx.dll which may be hard to find, but that's a problem when reusing code which might have different versions on the native d3dx9_xx.dlls. This is a problem with all forwarding functions, but I don't think that's a problem we have now, because we don't know what's the specific difference, yet and the differences may be small enough so that they could easily handled. 3. We may use a wined3dx (as suggested by Luis) which could handle all GUIDs. That way it is possible to add a custom D3DXCreateEffect function which could return the correct interface. Well I would prefer that more than #1, but it has the same flaws and there would be the need to move a lot of code around. 4. Implement each version on it's own, so each dll would get it's own code base. This way all differences could be handled correctly. Thus the only version which would really work 100% is #4, but due to not knowing the small differences and the huge amount of work which is needed, #4 seems to be practically out of scope. We have to switch to that later if we see no way to solve the version differences. So I think the way with reusing the code like it is done now is more practically and #2 makes that really good. It doesn't break the current forwards and keeps the version specific stuff in the correct dll. #1 seems to be a no go for me, because it breaks a lot more which just works now and that would annoy users a lot and we may get trouble with that one. So definitively my preferred solution is #2. #3 seem to be an improvement over #1. It has the advantage to cover more differences with a smaller code base, but it would also break the forwards to d3dx9_36.dll. So in general it only moves the problem a way further, but with the chance to make the implementation a bit easier (e.g. like with a custom D3DXCreateEffect function). Though using #2 and #3 would make it really good I think. The suggestion with the wined3dx may improve all ways and it may be possible to handle even the "small changes" with less effort, but I think that's a different discussion. Well I haven't found the answer for that in the devel archive but I found http://www.winehq.org/pipermail/wine-devel/2007-November/060662.html . Maybe someone else knows more about that topic. Cheers Rico

Sept. 29, 2011