December 2007 - Wine-Devel - list.winehq.org

Re: bugs audit volunteers required

by Vijay Kiran Kamuju

On Dec 31, 2007 5:19 PM, Austin English <austinenglish(a)gmail.com> wrote: > I've been doing this a little bit at a time for a while. I just wanted > to check base and make sure all on the same page. For starters, here's > a search of all bugs not touched in 6 months: > http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=al… Cool, I generally do it manually by checking every old bug <8000 > Which is the main list I work from for triaging old bugs. Here's > another link with bugs that have a download available: > http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=al… > > Furthermore, what criteria are we using for considering a bug > abandoned? I've been closing bugs that have had a lingering > question/request (e.g., requested a log/test) but received no reply in > 6 months. Generally we consider the bug as abandoned if the submitter does not respond for more than 1yr(at least 6months). Generally we consider the time factor if we could not get the application name. or if the submitter does not clearly explain the problem. (with to implementation of features or specialized test cases) And we check whether it belongs to any of the metabugs already present. Mostly for the older apps we would like to manually test ourselves with the links provided. As for the old bugs submitters might have forgotten about them. So we need to test it ourselves and put the logs or somethiing like still present in latest git. > > Lastly, how long are we trying to do this over? I try to limit my > testing/requests so as to not spam everyone too much, but if we go > through and verify all these old bugs, it's going to be _a lot_ of > bugzilla activity. Is everyone prepared for/okay with that? We would be doing this for 1-2 months as the Wine 1.0 release might happen in may be next 6-7 months time. We might expect lotta bugzilla activity as wine goes out of beta. and all the old bugs will be ignored and bugs grow exponentially. There will be lotta bugzilla spam, we cant avoid it ;) Last time it was mostly done by Jonathan Ernst and others, also by me -- VJ > > -Austin > > > > On Dec 31, 2007 5:05 PM, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > Hi, > > > > just like last year we did an audit of all the bugs in bugzilla. > > I think this year also we should do the same, the bugs are growing > > large and older bugs are being neglected. > > just wanted to say that we need to check all the old open bugs, and > > test them/ask the user for status. > > Close the bug as Abandoned if there is no response. also test the > > application yourself on latest git. > > this is the work to be done. and we need volunteers for this work. > > > > need volunteers to clear up the mess(old abandoned bugs) in bugzilla > > > > Thanks, > > vj > > > > > > >

Dec. 31, 2007

Re: bugs audit volunteers required

by Austin English

I've been doing this a little bit at a time for a while. I just wanted to check base and make sure all on the same page. For starters, here's a search of all bugs not touched in 6 months: http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=al… Which is the main list I work from for triaging old bugs. Here's another link with bugs that have a download available: http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=al… Furthermore, what criteria are we using for considering a bug abandoned? I've been closing bugs that have had a lingering question/request (e.g., requested a log/test) but received no reply in 6 months. Lastly, how long are we trying to do this over? I try to limit my testing/requests so as to not spam everyone too much, but if we go through and verify all these old bugs, it's going to be _a lot_ of bugzilla activity. Is everyone prepared for/okay with that? -Austin On Dec 31, 2007 5:05 PM, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > just like last year we did an audit of all the bugs in bugzilla. > I think this year also we should do the same, the bugs are growing > large and older bugs are being neglected. > just wanted to say that we need to check all the old open bugs, and > test them/ask the user for status. > Close the bug as Abandoned if there is no response. also test the > application yourself on latest git. > this is the work to be done. and we need volunteers for this work. > > need volunteers to clear up the mess(old abandoned bugs) in bugzilla > > Thanks, > vj > > >

Dec. 31, 2007

bugs audit volunteers required

by Vijay Kiran Kamuju

Hi, just like last year we did an audit of all the bugs in bugzilla. I think this year also we should do the same, the bugs are growing large and older bugs are being neglected. just wanted to say that we need to check all the old open bugs, and test them/ask the user for status. Close the bug as Abandoned if there is no response. also test the application yourself on latest git. this is the work to be done. and we need volunteers for this work. need volunteers to clear up the mess(old abandoned bugs) in bugzilla Thanks, vj

Dec. 31, 2007

Re: have a reference somewhere for mingw

by Steven Edwards

On Dec 31, 2007 6:38 AM, Jérôme Gardou <jgardou(a)yahoo.fr> wrote: > Why not include it into the wine wiki ? Support for mingw is always halfway broken anyway.... If you search the wine-devel archives, directions for how to properly setup your trees for cross-compiling are floating around. I think there is already documentation on how to setup your tree for crossbuilding the regression tests. This should be the same as for building the dlls but I have not looked at it in a while. Feel free to the wiki. See my old directions here and bottle to taste http://www.kerneltraffic.biz/wine/wn20050225_263_print.html#5 -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 31, 2007

Re: IDirectSound and Unknown IID

by Reece Dunn

On 31/12/2007, Guillaume B. <guillaume.benny(a)sympatico.ca> wrote: > Stefan Dösinger wrote: > > > Am Montag, 31. Dezember 2007 10:25:15 schrieb Vijay Kiran Kamuju: > >> > So the problem is that the interace > >> > {2a8af120-e9de-4132-aaa5-4bdda5f325b8} is not supported by the current > >> > Wine implementation. I've searched around but I couldn't find anything > >> > about this IID. If I knew what interface it was, maybe I could > >> > implement a stub and it might make the sound work. > > Huh, that IID is really Unknown... Google only finds your mail, and one > > other similar unanswered question. > > > > This will be tricky to figure out. The best starting point is probably to > > write a small test which queries this interface on Windows and see what > > happens. See dlls/dsound/tests for other dsound tests. > > Hi, > > I know it's unknown, that's why I asked! :) I thought someone might have an > idea: some kind of hardware specific IID maybe... It might be documented > somewhere in the DirectX SDK... > > For the record, the game is Rise of Nations and there's already a bug > reported on this: http://bugs.winehq.org/show_bug.cgi?id=9027 ... But the > trace of the bug report doesn't get to this unknown IID because I used the > native dmime and dswave DLL and a small hack so that the game gets farther. I can't see it in the Vista and XP CLSID section of the registry. Is it an interface that is being queried for internally by dmime or dswave (as you are using the native versions)? That is, MS may not be publicizing it (as it is not part of the DirectSound API), but are using it to coordinate interaction between dswave and dsound. It would be useful to find out if it is the game that is querying for this interface, or if it is the native DLLs. - Reece

Dec. 31, 2007

Re: IDirectSound and Unknown IID

by Guillaume B.

Stefan Dösinger wrote: > Am Montag, 31. Dezember 2007 14:51:26 schrieb Guillaume B.: >> Stefan Dösinger wrote: >> > Am Montag, 31. Dezember 2007 10:25:15 schrieb Vijay Kiran Kamuju: >> >> > So the problem is that the interace >> >> > {2a8af120-e9de-4132-aaa5-4bdda5f325b8} is not supported by the >> >> > {current >> >> > Wine implementation. I've searched around but I couldn't find >> >> > anything about this IID. If I knew what interface it was, maybe I >> >> > could implement a stub and it might make the sound work. >> > >> > Huh, that IID is really Unknown... Google only finds your mail, and one >> > other similar unanswered question. >> > >> > This will be tricky to figure out. The best starting point is probably >> > to write a small test which queries this interface on Windows and see >> > what happens. See dlls/dsound/tests for other dsound tests. >> >> Hi, >> >> I know it's unknown, that's why I asked! :) I thought someone might have >> an idea: some kind of hardware specific IID maybe... It might be >> documented somewhere in the DirectX SDK... > If it was documented in the directx sdk, Google would have found it, since > the sdk docs are available online at www.msdn.com I've searched thought it anyway but I could not find anything about it. I've set up a dummy COM object with a virtual table so I can see what functions get called. In this virtual table, the 4th function get called first, then the 3rd function. I know that the 3rd function is Release() so all I need is to understand what are the parameters and the return type of the 4th function. The return type is probably HRESULT: if I return S_OK, it continues but crashes farther but if I return E_NOTIMPL, it releases all music and sound COM object and it continues the game without sound, like if it detected an error. I wanted to use winedbg to see the assembly code that calls my dummy function (to see how many parameters there are) but even when I add a breakpoint for my function, it doesn't break. I've compiled Wine with CFLAGS="-g" to get the debug information but it doesn't work... Any idea? Thanks, Guillaume

Dec. 31, 2007

Re: Bug 8236 - broken animations in Dungeon Siege 2

by Rob Wilderspin

On Mon, 2007-12-31 at 14:27 +0100, Stefan Dösinger wrote: > Am Sonntag, 30. Dezember 2007 19:49:16 schrieb Rob Wilderspin: > > Greetings, > > > > I'm wondering if I can help anyone with the investigation of bug 8236, > > as I've recently acquired Dungeon Siege 2 and it's unplayable because of > > one seemingly small bug. > I wrote a reply to the bugreport This prompted the suggestion to use the native msvcrt.dll, which indeed does work around the biggest problem with Dungeon Siege 2, enough to make it fully playable. Wonderful! Many thanks to yourself, Rico and Matthias for looking at this. If I can help anyone track down what's wrong with the wine version of msvcrt, please don't hesitate to ask, as it would of course be better to have this fixed rather than sidestepped. Regards, Rob

Dec. 31, 2007

Re: IDirectSound and Unknown IID

by Stefan Dösinger

Am Montag, 31. Dezember 2007 14:51:26 schrieb Guillaume B.: > Stefan Dösinger wrote: > > Am Montag, 31. Dezember 2007 10:25:15 schrieb Vijay Kiran Kamuju: > >> > So the problem is that the interace > >> > {2a8af120-e9de-4132-aaa5-4bdda5f325b8} is not supported by the current > >> > Wine implementation. I've searched around but I couldn't find anything > >> > about this IID. If I knew what interface it was, maybe I could > >> > implement a stub and it might make the sound work. > > > > Huh, that IID is really Unknown... Google only finds your mail, and one > > other similar unanswered question. > > > > This will be tricky to figure out. The best starting point is probably to > > write a small test which queries this interface on Windows and see what > > happens. See dlls/dsound/tests for other dsound tests. > > Hi, > > I know it's unknown, that's why I asked! :) I thought someone might have > an idea: some kind of hardware specific IID maybe... It might be documented > somewhere in the DirectX SDK... If it was documented in the directx sdk, Google would have found it, since the sdk docs are available online at www.msdn.com

Dec. 31, 2007

Re: comctl32: Remove unneeded casts (1 of 3)

by Michael Stefaniuc

Andrew Talbot wrote: > Please do not commit this patch. It relies on UINT (= unsigned int) and > DWORD (= unsigned long int) both being 32 bits wide. Those are 32 bits wide on Win64 too. Even LONG is 32 bits on Win64. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Dec. 31, 2007

Re: [PATCH] ddraw: Return a nullpointer as lpSurface in Lock() if the rect is invalid.

by Günther Brammer

Stefan Dösinger <stefan <at> codeweavers.com> writes: > Am Mittwoch, 26. Dezember 2007 22:35:16 schrieb Günther Brammer: > > + memset(&locked_desc, 1, sizeof(locked_desc)); > > + locked_desc.dwSize = sizeof(locked_desc); > > + > > hr = IDirectDrawSurface_Lock(surface, rect, &locked_desc, > > DDLOCK_WAIT, NULL); ok(hr == DDERR_INVALIDPARAMS, "Lock returned 0x%08x for > > rect [%d, %d]->[%d, %d]" ", expected DDERR_INVALIDPARAMS (0x%08x)\n", hr, > > rect->left, rect->top, rect->right, rect->bottom, DDERR_INVALIDPARAMS); + > > ok(!memcmp(&locked_desc, &surface_desc, sizeof(locked_desc)), > > "IDirectDrawSurface_Lock did not set lpSurface in the surface desc\n"); } > I think you should just compare lpSurface instead of memcmp'ing the entire > structure. I was told on IRC to "test as much as you can get tested", and memcmp'ing the entire structure made me change my patch. Initially I had Lock fill the entire structure as it did in Wine 9.35. But ok, Baldurs Gate certainly only cares about lpSurface. > Also, in the patch that changes surface.c, it seems that the patch changes a > few whitespaces(unless I missed something). It does not change existing whitespace but adds two empty lines with trailing whitespace. I'll resend without that. Günther

Dec. 31, 2007