September 2011 - Wine-Devel

Re: wpp: Shed an unused parameter from generic_msg. (RESEND)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > I sent basically this in February without any feedback, and it still > applies. It's still wrong, the parameter is used inside the #ifdef. -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2011

Re: cmd/tests: Add tests for combined CALLs/GOTOs

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14056 Your paranoid android. === WVISTAADM (32 bit) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Sept. 8, 2011

Re: comctl32: Fix the wizard and property sheet dialog styles.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14049 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Sept. 7, 2011

Re: Updated Clang static analysis results / Valgrind update

by Austin English

Valgrind (ac0a7b644fa464fa640e06a6e26b2191b5a29a92) : http://austinenglish.com/logs/valgrind/2011-09-07-11.07/ Clang (f74a897f0eb47bea874b9247a24ad0dd61aa3507): http://www.sendspace.com/file/nvoxsk c8521b390e70a3ed31c00e69a095a35b702e1b0f scan-build-2011-09-06-1.tar.bz2 we're down to 1629 from 1815 (though some of that could be improved Clang analyzer) :). -- -Austin

Sept. 7, 2011

Re: Marking test cases as flaky?

by Dan Kegel

André wrote: > Plan C could be to do what testbot does and remember possible fails, maybe including the out of the blue ones. Testbot still suffers from a lot of false positives, I think. Yes, a build bot can do all sorts of workarounds, but we shouldn't forget about normal developers. It would be great if the average developer got in the habit of running 'make test' frequently and could rely on it not failing randomly.

Sept. 7, 2011

Re: [2/3] msxml3: Register XML Parser interfaces (try 2)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: >> Do you really need this? I think existing coclasses are registered >> with .idl in /msxml3. Maybe just add new .idl in it? >> > Since these interfaces aren't part of the msxml3 typelib, we properly > want to keep them separated. You still want to generate the registration from an idl file. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2011

Re: ntdll: check for string and stringlength in _wcslwr and _wcsupr

by Octavian Voicu

2011/9/7 André Hentschel <nerv(a)dawncrow.de>: > + if (!str || !*str) return NULL; > return strlwrW( str ); >+ if (!str || !*str) return NULL; > return struprW( str ); It seems strange to return NULL when called with an empty, non-NULL string. Maybe it should be `return str' instead (so it covers both the NULL and empty cases sensibly), though strlwrW/struprW seems to be able to cope with zero-length strings as the NULL char is mapped to NULL. Octavian

Sept. 7, 2011

Re: ntdll: check for string and stringlength in _wcslwr and _wcsupr

by Nikolay Sivov

2011/9/7 André Hentschel <nerv(a)dawncrow.de>: > Fixes http://bugs.winehq.org/show_bug.cgi?id=28303 (str="") > --- > dlls/ntdll/wcstring.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/wcstring.c b/dlls/ntdll/wcstring.c > index 7f0035d..d75f10e 100644 > --- a/dlls/ntdll/wcstring.c > +++ b/dlls/ntdll/wcstring.c > @@ -47,6 +47,7 @@ INT __cdecl NTDLL__wcsicmp( LPCWSTR str1, LPCWSTR str2 ) > */ > LPWSTR __cdecl NTDLL__wcslwr( LPWSTR str ) > { > + if (!str || !*str) return NULL; > return strlwrW( str ); > } > > @@ -65,6 +66,7 @@ INT __cdecl NTDLL__wcsnicmp( LPCWSTR str1, LPCWSTR str2, INT n ) > */ > LPWSTR __cdecl NTDLL__wcsupr( LPWSTR str ) > { > + if (!str || !*str) return NULL; > return struprW( str ); > } > Please add tests for that.

Sept. 7, 2011

Re: [3/3] msxml3: Support creating IXMLParser Interface (try 2)

by Nikolay Sivov

On Wed, Sep 7, 2011 at 4:13 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > On 7/09/2011 9:43 PM, Nikolay Sivov wrote: > >> >> (not related to patch contents) >> >> First time I saw this on a list I thought - god dammit, another parser >> interface. But looking at methods list it's probably a first candidate >> to be independent from libxml2 without any loss in functionality or >> big overhead like XPath or XSL things. We'll see. Is it mentioned as >> obsolete by any chance? Seems to be a kind of low level parser. >> > Yes, these are marked as obsolete but are still valid interfaces for > embedded windows. They are defined in xmlparser.idl but since there are > marked as local, I believe they wont be registered as per normal. Embedded windows, what's that? We probably can't use SAX for that parser, after a brief look at next patch some 'node' types seems to be low level token or something. Also IE4-quirk sounds promising. It's interesting to see what parts are really used by applications. > > Best Regards > Alistair Leslie-Hughes >

Sept. 7, 2011

Re: ntdll: Fix two buffer overflow conditions in RtlDosPathNameToNtPathName_U.

by Vitaliy Margolen

On 09/06/2011 08:46 AM, Octavian Voicu wrote: > On Tue, Sep 6, 2011 at 4:40 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >> The fix is not entirely correct. UNICODE_STRING does not have to have a >> terminating \0 character. The code should not use str* functions on not >> zero-terminated strings. > > I was also unsure about this when coding the patch, but I read here [1] that: > > "Specifies the length, in bytes, of the string pointed to by the > Buffer member, not including the terminating NULL character, if any." > > So it's not a mistake to include a NULL character. I figured it's not > worth the trouble to change the last strcpy into memcpy, especially > because it could also be the case that it would introduce regressions > (in case some other code wrongly depends on that NULL). > > Should I change offending strcpyW to memcpy? Some ntdll functions do put terminating \0 character into UNICODE_STRINGs. You can write a test to see if RtlDosPathNameToNtPathName_U is one of them. But by definition U_S does not require terminating \0. And many places don't put it there. Regardless, last strcpy & strlen should go and be replaced with memcpy & pointer arithmetic. Vitaliy.

Sept. 7, 2011

Re: Getting Wine's PO files on Launchpad

by Aric Stewart

So Newman and I just got a Pootle server setup for CrossOver translations and I was going to talk here about putting winehq's po files up on it also. I am still just getting use to admin for pootle, and I am not sure if i can get it hooked up directly to git or not. But if people are interested in the idea I am happy to admin the pootle install (since I am doing it anyway for the CrossOver stuff) -aric On 9/7/11 7:24 AM, André Hentschel wrote: > Am 07.09.2011 12:43, schrieb Francois Gouget: >> But Launchpage is certainly not the only option. We could set up our own >> Pootle server for instance. >> >> http://translate.sourceforge.net/wiki/pootle/features >> >> A number of projects do so. >> http://translate.sourceforge.net/wiki/pootle/live_servers >> >> An advantage is that we would be in control of the policies and >> copyright management. The drawback is that it requires more effort for >> translators as they would have to create yet another account just for >> Wine. > > Too bad that openid for pootle seems to be an old gsoc idea, but no one took it: > http://translate.sourceforge.net/wiki/developers/gsoc2008_ideas#pootle_open… >

Sept. 7, 2011

Re: [3/3] msxml3: Support creating IXMLParser Interface (try 2)

by Vijay Kiran Kamuju

On Wed, Sep 7, 2011 at 2:13 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > On 7/09/2011 9:43 PM, Nikolay Sivov wrote: > >> >> (not related to patch contents) >> >> First time I saw this on a list I thought - god dammit, another parser >> interface. But looking at methods list it's probably a first candidate >> to be independent from libxml2 without any loss in functionality or >> big overhead like XPath or XSL things. We'll see. Is it mentioned as >> obsolete by any chance? Seems to be a kind of low level parser. >> > Yes, these are marked as obsolete but are still valid interfaces for > embedded windows. They are defined in xmlparser.idl but since there are > marked as local, I believe they wont be registered as per normal. > > Best Regards > Alistair Leslie-Hughes > There is a bug# 5841 which depends on these functionality. This is a deprecrated functionality provided only by msxml3 Thanks, Vijay

Sept. 7, 2011

Re: Getting Wine's PO files on Launchpad

by André Hentschel

Am 07.09.2011 12:43, schrieb Francois Gouget: > But Launchpage is certainly not the only option. We could set up our own > Pootle server for instance. > > http://translate.sourceforge.net/wiki/pootle/features > > A number of projects do so. > http://translate.sourceforge.net/wiki/pootle/live_servers > > An advantage is that we would be in control of the policies and > copyright management. The drawback is that it requires more effort for > translators as they would have to create yet another account just for > Wine. Too bad that openid for pootle seems to be an old gsoc idea, but no one took it: http://translate.sourceforge.net/wiki/developers/gsoc2008_ideas#pootle_open… -- Best Regards, André Hentschel

Sept. 7, 2011

Re: [2/3] msxml3: Register XML Parser interfaces (try 2)

by Alistair Leslie-Hughes

On 7/09/2011 9:39 PM, Nikolay Sivov wrote: > On Wed, Sep 7, 2011 at 2:04 PM, Alistair Leslie-Hughes > <leslie_alistair(a)hotmail.com> wrote: >> Hi, >> >> >> Changelog: >> msxml3: Register XML Parser interfaces >> > > Do you really need this? I think existing coclasses are registered > with .idl in /msxml3. Maybe just add new .idl in it? > Since these interfaces aren't part of the msxml3 typelib, we properly want to keep them separated. Best Regards Alistair Leslie-Hughes

Sept. 7, 2011

Re: [3/3] msxml3: Support creating IXMLParser Interface (try 2)

by Alistair Leslie-Hughes

On 7/09/2011 9:43 PM, Nikolay Sivov wrote: > > (not related to patch contents) > > First time I saw this on a list I thought - god dammit, another parser > interface. But looking at methods list it's probably a first candidate > to be independent from libxml2 without any loss in functionality or > big overhead like XPath or XSL things. We'll see. Is it mentioned as > obsolete by any chance? Seems to be a kind of low level parser. > Yes, these are marked as obsolete but are still valid interfaces for embedded windows. They are defined in xmlparser.idl but since there are marked as local, I believe they wont be registered as per normal. Best Regards Alistair Leslie-Hughes

Sept. 7, 2011

Re: Marking test cases as flaky?

by André Hentschel

Am 07.09.2011 06:14, schrieb Dan Kegel: > Hi folks, > I've been running "make test" a lot lately, and occasionally > (it happened five times today), a test will fail out of > the blue, in one out of twenty or a hundred runs. > It would be bad form for buildbot to reject a patch > because of a spurious test failure, so I've been making a list of > tests that fail, adding to it each time I run into a test > that fails occasionally, and skipping the tests on that list > during "make test". This is all fine... but one of the tests that > fails occasionally is ddraw/visual.ok (see > http://bugs.winehq.org/show_bug.cgi?id=28301 ). > It really doesn't feel right to skip that entirely just > because a few particular pixel comparisons fail sometimes. > > Plan A would be to fix the tests to not be flaky, but that's hard, > and the buildbot needs a quick solution. > > Plan B might be to conditionally compile the flaky tests away, e.g.: > Plan C could be to do what testbot does and remember possible fails, maybe including the out of the blue ones. -- Best Regards, André Hentschel

Sept. 7, 2011

Re: winecoreaudio: Fix AudioRenderClient Get/ReleaseBuffer protocol (resend)

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > [unmodified & sent alone. There's no apply failure in testbot.] > > With this patch, MacOS will be the first to correctly implement the allowed ordering of Get and ReleaseBuffer according to my rendering tests (see bug #27937). > > [...capture mode] >>I believe that ReleaseBuffer(0) always returns S_OK, like in the render case. > Verified indeed. But I've not finalized capture code yet (I'm not > familiar with capture, so it takes more time). > > Because my patch changes the type of getbuf_last, I had to slightly modify AudioCaptureClient already: > @@ -1781,7 +1797,7 @@ static HRESULT WINAPI AudioCaptureClient_GetBuffer(IAudioCaptureClient *iface, > *flags = 0; > This->written_frames += *frames; > This->inbuf_frames -= *frames; > - This->getbuf_last = TRUE; > + This->getbuf_last = 1; This fake patch fragment in the message confuses git apply. Please don't do that. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2011

Re: [3/3] msxml3: Support creating IXMLParser Interface (try 2)

by Nikolay Sivov

On Wed, Sep 7, 2011 at 2:05 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > Use a skip if we cannot create the control. > > Changelog: > msxml3: Support creating IXMLParser Interface > > > Best Regards > Alistair Leslie-Hughes > > (not related to patch contents) First time I saw this on a list I thought - god dammit, another parser interface. But looking at methods list it's probably a first candidate to be independent from libxml2 without any loss in functionality or big overhead like XPath or XSL things. We'll see. Is it mentioned as obsolete by any chance? Seems to be a kind of low level parser.

Sept. 7, 2011

Re: [2/3] msxml3: Register XML Parser interfaces (try 2)

by Nikolay Sivov

On Wed, Sep 7, 2011 at 2:04 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > > Changelog: > msxml3: Register XML Parser interfaces > Do you really need this? I think existing coclasses are registered with .idl in /msxml3. Maybe just add new .idl in it?

Sept. 7, 2011

Re: [PATCH 1/2] cmd: Remove attrib from builtins list

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > The changes to the PO files would have to be committed as some point, > so why not generate them yourself rather than force Alexandre to alter > the patch after submission IMHO. > > Maybe Alexandre can bring some light on this subject? It's all auto-generated, so it's better to not include the po files diffs in the patch, unless you have made manual changes. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2011

Re: [PATCH 1/2] cmd: Remove attrib from builtins list

by Francois Gouget

On Wed, 7 Sep 2011, Frédéric Delanoy wrote: [...] > The changes to the PO files would have to be committed as some point, > so why not generate them yourself rather than force Alexandre to alter > the patch after submission IMHO. I don't think it generates more work for Alexandre. The reason for not including them would be the same as those for not including the changes to the configure script: they are automatically generated files. The wiki does not say anything about PO files though: http://wiki.winehq.org/SubmittingPatches#head-130662b8497eb838d0fd14cbc2c9e… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

Sept. 7, 2011

Re: Getting Wine's PO files on Launchpad

by Francois Gouget

On Tue, 6 Sep 2011, Austin English wrote: [...] > There's at least one other option: > http://translationproject.org/html/welcome.html It does not look like they make it possible to translate online. They seem to be more like a repository for PO files. So it seems less translator friendly and not as 'modern' as Launchpad. The upside is that it does not look like they try to automatically suggest translations from other projects so there may be less copyright issues from this side. However the web site is not clear on copyright issues, except for pushing translators to disclaim the copyright on their work. http://translationproject.org/html/whydisclaim.html They also strongly discourage projects from accepting translations from other sources that the translation project. I don't think we want to introduce such a limitation in Wine so if their translators share that point of view it could cause a clash. http://translationproject.org/html/maintainers.html But Launchpage is certainly not the only option. We could set up our own Pootle server for instance. http://translate.sourceforge.net/wiki/pootle/features A number of projects do so. http://translate.sourceforge.net/wiki/pootle/live_servers An advantage is that we would be in control of the policies and copyright management. The drawback is that it requires more effort for translators as they would have to create yet another account just for Wine. All these options are also not necessarily mutually exclusive either (though it raises coordination issues if a given language is worked on on two sites). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Sept. 7, 2011

Re: [PATCH 1/2] cmd: Remove attrib from builtins list

by Frédéric Delanoy

2011/9/7 Francois Gouget <fgouget(a)free.fr>: > On Wed, 7 Sep 2011, Frédéric Delanoy wrote: > >> On Wed, Sep 7, 2011 at 09:09, Christian Costa <titan.costa(a)wanadoo.fr> wrote: >> > -- >> > >> > This series remove attrib from the builtins list. Only the brief description in the global help is kept. >> > An externals list of commands shipped with cmd.exe is created so when the help builtins is called, the >> > requested help is obtained by invoking the command with the /? option as for native cmd.exe. > [...] >> You should probably commit the po changes as well, as is usually done > > My understanding is that the PO files are updated automatically when > Alexandre applies the patch (because he is in maintainer mode). > Or did you mean that Christian should modify the translations to remove > the corresponding line? The changes to the PO files would have to be committed as some point, so why not generate them yourself rather than force Alexandre to alter the patch after submission IMHO. Maybe Alexandre can bring some light on this subject? Frédéric

Sept. 7, 2011

Re: [PATCH 1/2] cmd: Remove attrib from builtins list

by Francois Gouget

On Wed, 7 Sep 2011, Frédéric Delanoy wrote: > On Wed, Sep 7, 2011 at 09:09, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > > -- > > > > This series remove attrib from the builtins list. Only the brief description in the global help is kept. > > An externals list of commands shipped with cmd.exe is created so when the help builtins is called, the > > requested help is obtained by invoking the command with the /? option as for native cmd.exe. [...] > You should probably commit the po changes as well, as is usually done My understanding is that the PO files are updated automatically when Alexandre applies the patch (because he is in maintainer mode). Or did you mean that Christian should modify the translations to remove the corresponding line? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Sept. 7, 2011

Re: [PATCH 1/2] cmd: Remove attrib from builtins list

by Frédéric Delanoy

On Wed, Sep 7, 2011 at 09:09, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > -- > > This series remove attrib from the builtins list. Only the brief description in the global help is kept. > An externals list of commands shipped with cmd.exe is created so when the help builtins is called, the > requested help is obtained by invoking the command with the /? option as for native cmd.exe. > --- > programs/cmd/cmd.rc | 1 - > programs/cmd/wcmd.h | 91 +++++++++++++++++++++++------------------------ > programs/cmd/wcmdmain.c | 1 - > 3 files changed, 45 insertions(+), 48 deletions(-) You should probably commit the po changes as well, as is usually done

Sept. 7, 2011