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

Re: Direct3D Game test framework

by Stefan Dösinger

Am Donnerstag, 28. Juni 2007 18:05 schrieb Stefan Dösinger: > So whats left? > *) Make the Email system send custom test return data, not just success / > failure I found a simple solution for that: I just dump the results onto the log channel, which is sent to the server which can then grep the numbers out. > *) extend the server side infrastructure to handle that test data. Any volunteers? I tried to avoid web development as good as possible and I'm pretty crappy at it :-/ > *) Write tests for more games Will write more :-)

June 28, 2007

Re: request to change appdb message

by Chris Morgan

On 6/28/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Ben Hodgetts (Enverex <ben <at> atomnet.co.uk> writes: > > > > > Me and Chris Morgan changed it to this because we were sick of people > > pasting pages and pages of terminal output into the What works or What > > doesn't work boxes of the test data which is NOT where it belongs. The > > information in test data should be written in plain English, not pastes > > of lots of (mostly useless) terminal output which just looks awful and > > isn't any use to most users of the AppDB. > > > > I agree with point 2 but the problem is most AppDB submitters just... > > too stupid to be able to use some sense or judgement about what they > > are asked to actually put in the test reports. > > > > What you'd rather change it to would make the previous situation much, > > much worse so under no circumstances should it be changed to that though. > > > > Ben > > > Then i would vote for a kind of extra field in which users can paste their > crash/debug output , but that field wouldn't get sent into the appdb. Something > like that should be possible i guess. Otherwise i fear in many cases i cannot > really judge if the test result lots are valid or not...... > How do you normally judge if the result is valid or not? What if the result says that everything works? It seems like any result could be faked, and we can't reject a test result from a user that had problems just because a handful of other users didn't. What else can we do with the issue you raised in #1? If users report their app doesn't work but don't report the crash data then at least we know the app doesn't work and thats valuable data. If it is too difficult to report bugs in bugzilla we should see if there are ways to assist with this. For instance we could have an option on the test submission page of the appdb where a user could submit a new bug by attaching the crash log and this bug would be linked to the application/version they were submitting the test results for and also noted in the text of the test result. Duplicating crash/bug reports in the appdb seems the opposite of where we should be heading. I'm not entirely sure what your point #2 is. You are arguing that we want to see crash results in test submissions because then we can reply with a suggestion about how to fix the issue? It seems like this is exactly the kind of thing we want in bugzilla since it reflects issues users have with Wine. In the example you used in #2 it seems like the issue is that the application wasn't installed under Wine. I'd recommend that in the cases where wine can't find dlls that we popup a dialog box and suggest that the user install the application under wine and that this should install the required dlls. If this dll is something wine needs to ship with then this is a legit bug and should go in bugzilla. I guess my point about #2 is that assuming the user didn't do something really crazy, the issues the user has tend to be deficiencies in wine or its documentation and these really are legitimate issues that should be addressed. Chris

June 28, 2007

Re: msi 1: Implement MsiSourceListGetInfoA [try2]

by James Hawkins

On 6/28/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "James Hawkins" <truiken(a)gmail.com> writes: > > > By this definition, for any particular property requested, the size > > returned should be exactly the same for both the A and W call. This > > eliminates the need for a W size variable, and in fact, setting the > > returned A size by manipulating the returned W size (the usual divide > > by sizeof WCHAR) would be wrong. Have I messed up somewhere in my > > logic? > > For the A size TCHARs are bytes, not logical characters, so there > isn't a 1:1 equivalence with the W size. The only way to return the > correct size is to convert with WideCharToMultiByte and return the > resulting length. That's how all A functions work. > Ok, thanks for clearing this up for me. I'll fix it and resend. -- James Hawkins

June 28, 2007

Re: msi 1: Implement MsiSourceListGetInfoA [try2]

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > By this definition, for any particular property requested, the size > returned should be exactly the same for both the A and W call. This > eliminates the need for a W size variable, and in fact, setting the > returned A size by manipulating the returned W size (the usual divide > by sizeof WCHAR) would be wrong. Have I messed up somewhere in my > logic? For the A size TCHARs are bytes, not logical characters, so there isn't a 1:1 equivalence with the W size. The only way to return the correct size is to convert with WideCharToMultiByte and return the resulting length. That's how all A functions work. -- Alexandre Julliard julliard(a)winehq.org

June 28, 2007

WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442

by Kai Blin

The tests added in patch commit e39dca6af6c87a30ab1d907c0468de2602a6e442 Author: Damjan Jovanovic <damjan.jov(a)gmail.com> Date: Thu Mar 22 08:03:28 2007 +0200 ws2_32: WSASendTo should always re-enable the FD_WRITE event. break the ws2_32 sock.c tests on WinXP SP2. sock.c:1832: Test failed: WaitForSingleObject failed, error 258 I'm afraid I don't really know what's going wrong there. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

June 28, 2007

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]

by Evan Stade

On 6/27/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > sorry for the post on wine-patches. How can I improve this test? -- Evan Stade

June 28, 2007

Re: request to change appdb message

by Louis Lenders

Ben Hodgetts (Enverex <ben <at> atomnet.co.uk> writes: > > Me and Chris Morgan changed it to this because we were sick of people > pasting pages and pages of terminal output into the What works or What > doesn't work boxes of the test data which is NOT where it belongs. The > information in test data should be written in plain English, not pastes > of lots of (mostly useless) terminal output which just looks awful and > isn't any use to most users of the AppDB. > > I agree with point 2 but the problem is most AppDB submitters just... > too stupid to be able to use some sense or judgement about what they > are asked to actually put in the test reports. > > What you'd rather change it to would make the previous situation much, > much worse so under no circumstances should it be changed to that though. > > Ben Then i would vote for a kind of extra field in which users can paste their crash/debug output , but that field wouldn't get sent into the appdb. Something like that should be possible i guess. Otherwise i fear in many cases i cannot really judge if the test result lots are valid or not......

June 28, 2007

Re: msi 1: Implement MsiSourceListGetInfoA [try2]

by James Hawkins

On 6/28/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > "James Hawkins" <truiken(a)gmail.com> writes: > > > + ret = MsiSourceListGetInfoW(product, usersid, dwContext, dwOptions, > > + property, value, pcchValue); > > + if (ret == ERROR_SUCCESS) > > + WideCharToMultiByte(CP_ACP, 0, value, -1, szValue, *pcchValue, NULL, NULL); > > The handling of pcchValue is wrong, you need a separate variable for > the W size, and you need to set *pcchValue to the correct A size. > To quote msdn for convenience: "pcchValue: A pointer to a variable that specifies the number of TCHAR in the szValue buffer. When the function returns, this parameter is set to the size of the requested value whether or not the function copies the value into the specified buffer. The size is returned as the number of TCHAR in the requested value, not including the terminating null character." By this definition, for any particular property requested, the size returned should be exactly the same for both the A and W call. This eliminates the need for a W size variable, and in fact, setting the returned A size by manipulating the returned W size (the usual divide by sizeof WCHAR) would be wrong. Have I messed up somewhere in my logic? -- James Hawkins

June 28, 2007

Re: Crosscompile failures for gdiplus

by Stefan Leichter

Am Thursday 28 June 2007 10:45 schrieb Paul Vriens: > Hi, > > Ever since gdiplus tests (roughly 2 weeks ago) got added to Wine we have > crosscompile failures: > > i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual > -o brush.cross.o brush.c brush.c:1: warning: -fPIC ignored for target (all > code is position independent) i386-mingw32-gcc -c -I. -I. > -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe > -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings > -Wpointer-arith -Wcast-qual -o pen.cross.o pen.c pen.c:1: warning: -fPIC > ignored for target (all code is position independent) > ../../../tools/make_ctests -o testlist.c brush.c pen.c > i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual > -o testlist.cross.o testlist.c testlist.c:1: warning: -fPIC ignored for > target (all code is position independent) i386-mingw32-gcc brush.cross.o > pen.cross.o testlist.cross.o -o gdiplus_crosstest.exe -lgdiplus > -lkernel32 > /usr/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/bin/ld: > cannot find -lgdiplus > collect2: ld returned 1 exit status > make: *** [gdiplus_crosstest.exe] Error 1 > > Does anybody feel up to fixing MingW so we will have a new winetest > executable soon? No new one since June 12 on > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ . > Hello Paul, the patches are already in the inbox of Paul Millar, but it looks like he did not find the time to include them into the build environment. The last patches were from yesterday (msi,mshtml). And it looks like i need to send at lesat one today (pdh). Bye Stefan

June 28, 2007

Re: wincrypt: add missing defines

by Juan Lang

No, Yahoo mail has falsely identified it as a virus. Switching to another account.. --Juan --- Mounir IDRASSI <mounir.idrassi(a)idrix.fr> wrote: > You forgot the attachement... ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting

June 28, 2007