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

Re: request to change appdb message

by Louis Lenders

Chris Morgan <chmorgan <at> gmail.com> writes: > > How do you normally judge if the result is valid or not? What if the > result says that everything works? Basically i'm only talking about garbage test results. If the app is gold/platinum there's of course no need to paste debug output >It seems like any result could be faked, and we can't reject a test result >from >a user that had problem just because a handful of other users didn't. > Yeah, i agree, there's no way to solve that. > 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. I don't think it's too difficult, most users just don't bother to do this. > > 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. Unfortunately , if anyone would open a bug with the example >i gave in issue #2,it would be closed immediately with a comment "Invalid" -> "Closing". > > 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. Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess. Something like: Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135 Solution: winetricks vcrun60 or Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc......... Solution: winetricks mdac27 Would that be something useful? Cheers, Louis

June 29, 2007

Re: WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442

by Paul Vriens

Damjan Jovanovic wrote: > On 6/28/07, Kai Blin <kai.blin(a)gmail.com> wrote: >> 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 > > Really strange, I remember that test passing when I wrote it. > >> I'm afraid I don't really know what's going wrong there. > > I'll run the tests myself this weekend. > >> 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. > > Damjan > > > Briefly looking at http://test.winehq.org/data agrees with Kai's findings. Ever since the March 23 version of winetest, this test is failing for all NT4+ systems. Cheers, PAul.

June 29, 2007

Re: WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442

by Damjan Jovanovic

On 6/28/07, Kai Blin <kai.blin(a)gmail.com> wrote: > 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 Really strange, I remember that test passing when I wrote it. > I'm afraid I don't really know what's going wrong there. I'll run the tests myself this weekend. > 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. Damjan

June 29, 2007

make test in winsock segfaulting after patch 4c5b55a0f8...

by Kai Blin

The following commit breaks the winsock test for me. commit 4c5b55a0f82e83793814a21eadec8b50d48751f3 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Jun 4 18:16:48 2007 +0200 server: Run async I/O APCs from the SIGUSR1 handler. I have attached the backtrace. This is currently stopping me from confirming if my WSAStringToAddress patch is correct. 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 29, 2007

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

by Misha Koshelev

On 6/27/07, Evan Stade <estade at 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 > > Also, the attached (much shorter) diff makes all your tests conform on wine for me. I am a little confused as to where the non-open-path part of your PolyDraw patch came from (maybe I am missing something). Misha

June 29, 2007

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

by Misha Koshelev

On 6/27/07, Evan Stade <estade at 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 > > Well I am obviously not Alexandre but I'll hazard a guess. I don't think my advice/style comments which I sent yesterday kept the patch out, but the second patch definitely looks like it might have kept the patchset out. Specifically, a gem from gdi_private.h: /* It should not be necessary to access the contents of the GdiPath * structure directly; if you find that the exported functions don't * allow you to do what you want, then please place a new exported * function that does this job in path.c. */ Now I would almost be willing to bet money on the fact that Alexandre would want you to split your second patch up into a PATH_PolyDraw and your non-path case, then the PolyDraw in painting.c would go something like: if(PATH_IsPathOpen(dc->path)) ret = PATH_PolyDraw(dc, ...); else if(dc->funcs->pPolyDraw) ret = dc->funcs->pPolyDraw(dc->physDev, ...); else { /* Stuff to do in case of no open path */ } GDI_ReleaseObj(hdc); return ret; --- Misha p.s. Also your BYTE polydraw_tps should be static (minor point). p.p.s. Just to satisfy my anal retentiveness, and to make the test patch look nicer, if you end up resubmitting anyway you might as well put this in (note I changed some of your 1's to 2's because technically a 2 means an entry is completely skipped in wine, and a 1 means it is present in wine but does not quite match, although in this case either one will get you a successful todo_wine so it doesn't really matter): static const path_test_t polydraw_path[] = { {300, 300, PT_MOVETO, 0, 0}, /* 0 */ {150, 200, PT_LINETO, 0, 0}, /* 1 */ {200, 150, PT_LINETO | PT_CLOSEFIGURE, 0, 0}, /* 2 */ {300, 300, PT_MOVETO, 0, 1}, /* 3 */ {300, 300, PT_LINETO, 0, 0}, /* 4 */ {400, 300, PT_LINETO, 0, 0}, /* 5 */ {400, 350, PT_LINETO, 0, 0}, /* 6 */ {50, 100, PT_MOVETO, 0, 0}, /* 7 */ {100, 50, PT_LINETO, 0, 0}, /* 8 */ {400, 250, PT_LINETO, 0, 0}, /* 9 */ {500, 300, PT_LINETO, 0, 0}, /* 10 */ {500, 350, PT_LINETO, 0, 0}, /* 11 */ {350, 400, PT_MOVETO, 0, 2}, /* 12 */ {600, 200, PT_LINETO, 0, 2}, /* 13 */ {500, 150, PT_LINETO, 0, 0}, /* 14 */ {500, 350, PT_MOVETO, 0, 2}, /* 15 */ {500, 150, PT_LINETO, 0, 2}, /* 16 */ {100, 200, PT_LINETO, 0, 0}, /* 17 */ {400, 150, PT_LINETO, 0, 0}, /* 18 */ {400, 350, PT_LINETO, 0, 0}}; /* 19 */

June 29, 2007

Re: msi [1/10]: Implement MsiSourceListGetInfoA

by James Hawkins

On 6/28/07, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Correctly handled pcchValue. > > Changelog: > * Implement MsiSourceListGetInfoA. > Please disregard this series. -- James Hawkins

June 29, 2007

shelllink patches

by Misha Koshelev

Btw, in case it was not clear from the patches themselves, without these patches out shelllinks for non-executables currently point to the application that is assigned to open them (e.g., notepad), rather than to the actual file as on native. Misha

June 29, 2007

Re: request to change appdb message

by Jesse Allen

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...... > > > > No, I don't agree. Bug reports should be filed when the user has a crash or problem and a log to go along with it. I started asking people a long time ago to not paste logs anywhere on my appdb pages. I don't want a scroll bar the size of a flea which can happen with just one poor log. Honestly, for a test report, a comment like: "X doesn't work correctly. Filed bug report: bug Y" would be wonderful. I've been slowly pruning all the comments with logs on my page too. Hope that doesn't upset anyone.

June 28, 2007

illegal characters in file names

by Lei Zhang

Hi, I noticed a mismatch between the list of illegal characters in file names between Wine and Windows. On Wine the list of characters is: /:<>| and on Windows, it is: \/:*?"<>| Is this intentional or something we should fix? - Lei

June 28, 2007