wine-devel June 2007

wine-devel@winehq.org

101 participants
249 discussions

make test in winsock segfaulting after patch 4c5b55a0f8...
by Kai Blin 29 Jun '07

29 Jun '07

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.

1 1

WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442
by Kai Blin 29 Jun '07

29 Jun '07

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.

3 2

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Misha Koshelev 29 Jun '07

29 Jun '07

1 0

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Misha Koshelev 29 Jun '07

29 Jun '07

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 */

1 0

Re: msi [1/10]: Implement MsiSourceListGetInfoA
by James Hawkins 29 Jun '07

29 Jun '07

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

1 0

shelllink patches
by Misha Koshelev 29 Jun '07

29 Jun '07

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

1 0

Re: msi 1: Implement MsiSourceListGetInfoA [try2]
by Alexandre Julliard 28 Jun '07

28 Jun '07

"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. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Evan Stade 28 Jun '07

28 Jun '07

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

1 0

Re: wincrypt: add missing defines
by Mounir IDRASSI 28 Jun '07

28 Jun '07

You forgot the attachement... Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > --Juan > > > > ____________________________________________________________________________________ > Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. > http://autos.yahoo.com/carfinder/ > > > > >

2 1

Wine networking broke on Debian Sid
by Ben Hodgetts (Enverex) 28 Jun '07

28 Jun '07

Just to make this clear before starting this is a Sid issue (as far as I can tell) not a Wine issue. Anyway, to the point. Networking is broken on Debian Sid and has been for at least a week. I can't find out what has changed in Sid for it to stop working but basically anyone running Wine on Sid wont be able to use any form of network access. Firefox wont work, games wont be able to access servers or anything else, Gecko wont work, etc. This is using GIT, not the distros own packages. I tried using the x86_64 package for Ubuntu 7.04 (because no x86_64 package exists for Debian) and Wine acted exactly the same way with a clean .wine so it's not related to any build time issues. I reset to 0.9.34 in GIT and built that to make sure it wasn't anything that has changed in Wine itself and the issue continued, so it's not something that's changed in Wine. Although using an earlier version of Wine gives a "Winehq.com could not be found, please check the address and try again". Current Wine (or rather Gecko) doesn't bother giving you an error message. Could this be the work of the removal of an unspoken Wine dependency or something more sinister? All native apps still work perfectly which is what makes this such a hard thing to track down. I just thought I'd throw this out there in-case any of you are using Sid and wondering what the the hell happened to Wine. Log attached for completeness. Ben H.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2007