February 2014 - Wine-Devel - list.winehq.org

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Jerome Leclanche <adys.wh(a)gmail.com> wrote: > >> >> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. > >> > > >> > Now they are going to think that they are supposed to set the version > >> > to Wine 1.0 or even 0.9, right? :) > >> > >> Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. > > > > In reality Wine version should be set to the one that user had used > > at the time it experianced the problem he/she were reporting. That's > > neither earliest nor the latest one, it's the one used at the bug > > reporting time. > > > > -- > > Dmitry. > > > > > > What is the reasoning behind that, really? What is the point of having > a version field that tells the developers absolutely nothing? One need to be a developer to comment on this I'd guess, but telling an exact used Wine version in the bug report is already a very good start. > As it stands the version field is only useful for a split second at > report time to tell users "The version you're using is too old". This > could be automated with a bit of javascript and prevent unnecessary > reports. Reports for too old versions could be avoided by not listing old versions at all, and telling a user that if he/she can't find his/her version in the list to upgrade. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Jerome Leclanche

On Mon, Feb 10, 2014 at 1:43 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Ken Thomases <ken(a)codeweavers.com> wrote: > >> >> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. >> > >> > Now they are going to think that they are supposed to set the version >> > to Wine 1.0 or even 0.9, right? :) >> >> Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. > > In reality Wine version should be set to the one that user had used > at the time it experianced the problem he/she were reporting. That's > neither earliest nor the latest one, it's the one used at the bug > reporting time. > > -- > Dmitry. > > What is the reasoning behind that, really? What is the point of having a version field that tells the developers absolutely nothing? As it stands the version field is only useful for a split second at report time to tell users "The version you're using is too old". This could be automated with a bit of javascript and prevent unnecessary reports. J. Leclanche

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Rosanne DiMesio

On Sun, 9 Feb 2014 18:14:35 -0800 > > Well, if that's the consensus that develops, then perhaps we could > either: a) rename it to Originally Reported Version, or b) disable editing > that field by non-admin users. (We might also disable non-admin users from > setting or editing the Severity field, too.) > > I'd vote for b). Me, too. Especially the part about disabling setting the Severity field for non-admin users--that's an even worse problem than the Version field. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Austin English

On Feb 9, 2014 6:11 PM, "Ken Thomases" <ken(a)codeweavers.com> wrote: > > On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote: > > > Version field should be never changed and left at the original version > > that the user had reported the problem for. There is no point in changing > > it to an earlier or a later one IMHO. > > Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.) I'd vote for b).

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Ken Thomases

On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote: > Version field should be never changed and left at the original version > that the user had reported the problem for. There is no point in changing > it to an earlier or a later one IMHO. Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.) -Ken

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Ken Thomases <ken(a)codeweavers.com> wrote: > >>>> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. > >>> > >>> Now they are going to think that they are supposed to set the version > >>> to Wine 1.0 or even 0.9, right? :) > >> > >> Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. > > > > In reality Wine version should be set to the one that user had used > > at the time it experianced the problem he/she were reporting. That's > > neither earliest nor the latest one, it's the one used at the bug > > reporting time. > > The problem is that users retest with new releases of Wine and then update the Version field when they shouldn't. The desired behavior is for them to leave it at the earliest one where they found the problem. And if somebody happens to test an earlier version and finds that the bug existed back then, they should update the Version field to show that earlier version. Or, at least, that's what I've seen experienced bug wranglers do. Version field should be never changed and left at the original version that the user had reported the problem for. There is no point in changing it to an earlier or a later one IMHO. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Ken Thomases

On Feb 9, 2014, at 7:43 PM, Dmitry Timoshkov wrote: > Ken Thomases <ken(a)codeweavers.com> wrote: > >>>> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. >>> >>> Now they are going to think that they are supposed to set the version >>> to Wine 1.0 or even 0.9, right? :) >> >> Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. > > In reality Wine version should be set to the one that user had used > at the time it experianced the problem he/she were reporting. That's > neither earliest nor the latest one, it's the one used at the bug > reporting time. The problem is that users retest with new releases of Wine and then update the Version field when they shouldn't. The desired behavior is for them to leave it at the earliest one where they found the problem. And if somebody happens to test an earlier version and finds that the bug existed back then, they should update the Version field to show that earlier version. Or, at least, that's what I've seen experienced bug wranglers do. -Ken

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Ken Thomases <ken(a)codeweavers.com> wrote: > >> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. > > > > Now they are going to think that they are supposed to set the version > > to Wine 1.0 or even 0.9, right? :) > > Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. In reality Wine version should be set to the one that user had used at the time it experianced the problem he/she were reporting. That's neither earliest nor the latest one, it's the one used at the bug reporting time. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Ken Thomases

On Feb 9, 2014, at 7:27 PM, Dmitry Timoshkov wrote: > Ken Thomases <ken(a)codeweavers.com> wrote: > >> I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. > > Now they are going to think that they are supposed to set the version > to Wine 1.0 or even 0.9, right? :) Probably. :) There's a reason why I said "reduced" and not "eliminated" in the above. People will always be people. -Ken

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Ken Thomases <ken(a)codeweavers.com> wrote: > I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. Now they are going to think that they are supposed to set the version to Wine 1.0 or even 0.9, right? :) -- Dmitry.

Feb. 10, 2014

Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Ken Thomases

Hi, I haven't been subscribed to the bug emails for long, but it seems there's an ongoing problem with users updating the Version field to the _newest_ affected version when we want it to indicate the _earliest_ affected version. Sorry if this is the sort of thing which has been discussed and dismissed before, but it seems the problem could be reduced by renaming the field. I'm attaching a Bugzilla patch which I think does this. I'm not submitting to wine-patches yet because I'm not able to test this. Also, I don't know if people think it's a good idea, so I thought I'd ask first. -Ken

Feb. 10, 2014

Re: Alexandre Julliard : Wine release 1.7.12

by Frédéric Delanoy

On Sat, Feb 8, 2014 at 1:17 AM, Joseph Facciponti <joefatch(a)gmail.com> wrote: > remove me from your list please You need to use wine-devel subscriptions interface (only a web search away). Regards, Frédéric Delanoy

Feb. 9, 2014

Re: FOSDEM Presentations

by Marcus Meissner

On Sun, Feb 09, 2014 at 07:20:19AM +0100, Rico Schüller wrote: > On 08.02.2014 19:20, Marcus Meissner wrote: > >On Sat, Feb 08, 2014 at 07:06:00PM +0100, Stefan Dösinger wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >>Hi, > >> > >>Do we collect FOSDEM presentations in a central place? > > > >http://wiki.winehq.org/FOSDEM2014 > > > >Ciao, Marcus > > There are some videos on the FOSDEM page: > http://video.fosdem.org/2014/AW1120/Sunday/ , sadly they seem to > lack sound. They probably only used the right channel instead of the left... The microphone was only on the left channel. Will see if we get them to redo it ;) Ciao, Marcus

Feb. 9, 2014

Re: FOSDEM Presentations

by Rico Schüller

On 08.02.2014 19:20, Marcus Meissner wrote: > On Sat, Feb 08, 2014 at 07:06:00PM +0100, Stefan Dösinger wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Do we collect FOSDEM presentations in a central place? > > http://wiki.winehq.org/FOSDEM2014 > > Ciao, Marcus There are some videos on the FOSDEM page: http://video.fosdem.org/2014/AW1120/Sunday/ , sadly they seem to lack sound. Cheers Rico

Feb. 9, 2014

Re: FOSDEM Presentations

by Marcus Meissner

On Sat, Feb 08, 2014 at 07:06:00PM +0100, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Do we collect FOSDEM presentations in a central place? http://wiki.winehq.org/FOSDEM2014 Ciao, Marcus

Feb. 8, 2014

FOSDEM Presentations

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Do we collect FOSDEM presentations in a central place? Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS9nIIAAoJEN0/YqbEcdMwXWIP/iB5Hb647oT5UcSiUy7Zru7a YaFb5/uTkBpOJZhD9KAa/u6XT8l7jh9pB633RgZSPl4xBY9/T3aIo+5amMF7IOvA 3NP3I0bRehnlbzAaeqhoN97BIHJQ4Y2ulub+FPx/GDY/kxwXayd0jurEcf+ZL4K2 csOtkgSplI05YXxBw1ZmYjiOGfXgqRH1DCEyaFaFgEWenYrfER7XzaiT2xAK64JN 85Cmp2vh5zlTh3C5jChpoeaWIHcweHC5EYONYOCAk9W2wxZdin0QWjYVnja5+DzR HnrcIsiFAXdD9IRxBStc+y4yqUq5YIDfZczpj0fI5cuPrqOxvnomyNI/y2Zs4epz sq1lL5eEyo5hTQS99PbqbENrT7IRF0IpSIebcrPCTbCpuKHctwWe3oFFS2BuqIPl 4Q/6bsNXxvQW4B3es4vcGDov05Aiy/MT1NQZoEsIXvYNa/ufqiEDmmXVCRz7rI6f 9D4hiMzS6Dxh3VRSigBcg1R3H+rYc+v1gUxGutcXWplGrVLFuE3iBY7UYfdp9rkC 6zcidSNrUDMsQMKLbmCXQV361RcL03bi+rtTVzl4d/u5RhpgVZG8BSoq49+Nt3ea MHNplal9pHWXcBHXos3L0o4PeF2tf7rdNRuLOdVYya6bBYP/UpVtHeJ2/SD7WoOV HvlQe9zHcOxAKYSX0M0P =bd+Z -----END PGP SIGNATURE-----

Feb. 8, 2014

Re: oleaut32: Resolve embedded unnamed TypeLib dependencies using their GUID.

by Nikolay Sivov

On 2/8/2014 03:27, guillaume.charifi(a)sfr.fr wrote: > This patch is designed to fix the bug: > http://bugs.winehq.org/show_bug.cgi?id=34184 > It appears that while the dependency checking of a TypeLib is being > processed, some programs have the requested TypeLib in their Resource > section/TYPELIB. Before this patch, the behavior was to look for the > TLB on the disk, using the name provided. Obviously, when it is > embedded into the program, the function fails everytime. Now, > considering the GUID in place of the TLB name, and searching into the > Resource section, the TLB is correctly loaded. > This is what happens with Skype's "uc.tlb", whose name is only > referenced in the TLB skControl, and nowhere else. Using instead the > GUID, we are able to find and load the unnamed "uc.tlb" from the > program resources. > > --- > dlls/oleaut32/typelib.c 193 > +++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 192 insertions(+), 1 deletion(-) > We already have a code to load from resource section, it should be reused instead of duplicating it like this. Also a test would be nice.

Feb. 8, 2014

Re: Alexandre Julliard : Wine release 1.7.12

by Joseph Facciponti

remove me from your list please On Fri, Feb 7, 2014 at 2:04 PM, Alexandre Julliard <julliard(a)winehq.org>wrote: > Module: website > Branch: master > Commit: 14ca1bc06c384e1a3c2d51b3205a7e1e54045519 > URL: > http://source.winehq.org/git/website.git/?a=commit;h=14ca1bc06c384e1a3c2d51… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Fri Feb 7 20:04:34 2014 +0100 > > Wine release 1.7.12 > > --- > > news/en/2014020701.xml | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/news/en/2014020701.xml b/news/en/2014020701.xml > new file mode 100644 > index 0000000..ce004de > --- /dev/null > +++ b/news/en/2014020701.xml > @@ -0,0 +1,16 @@ > +<news> > +<date>February 7, 2014</date> > +<title>Wine 1.7.12 Released</title> > +<body> > + The Wine development release 1.7.12 is now available. > + <a href="{$root}/announce/1.7.12">What's new</a> in this release: > +<ul> > + <li>Initial support for Window Media Player interfaces.</li> > + <li>Some more Task Scheduler support.</li> > + <li>Various C++ runtime fixes.</li> > + <li>More dlls with ugly names for Windows 8 API set support.</li> > + <li>Various bug fixes.</li> > +</ul> > +The source is <a href=" > http://prdownloads.sourceforge.net/wine/wine-1.7.12.tar.bz2">available > now</a>. > +Binary packages are in the process of being built, and will appear soon > at their respective <a href="{$root}/download">download locations</a>. > +</body></news> > > > >

Feb. 8, 2014

Re: Assorted spelling fixes

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 https://newtestbot.winehq.org/JobDetails.pl?Key=4688 Your paranoid android. === w2008s64 (64 bit url) === url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1674: Test failed: unexpected call OnProgress_CONNECTING === w7pro64 (64 bit url) === url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1674: Test failed: unexpected call OnProgress_CONNECTING url.c:1871: Test failed: binding failed: 800c0005, expected 00000000 url.c:1882: Test failed: res = 00002efd, expected 00000000 url.c:3141: Test failed: expected OnProgress_SENDINGREQUEST url.c:3147: Test failed: expected OnResponse url.c:3151: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3152: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3153: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3165: Test failed: expected OnDataAvailable url.c:1660: Test failed: unexpected call OnProgress_FINDINGRESOURCE

Feb. 7, 2014

Re: Assorted spelling fixes

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 https://newtestbot.winehq.org/JobDetails.pl?Key=4686 Your paranoid android. === wxppro (32 bit) === batch.c:312: Test failed: unexpected char 0x47 position 0 in line 686 (got 'Got unexpected result: "C:\Documents"', wanted 'Plain directory enumeration from provided root') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 687 (got 'Got unexpected result: "C:\Documents"', wanted 'File enumeration') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 688 (got 'Got unexpected result: "C:\Documents"', wanted 'File enumeration from provided root') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 689 (got 'Got unexpected result: "C:\Documents"', wanted 'Mixed enumeration') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 690 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted 'Mixed enumeration from provided root') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 691 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted 'With duplicates enumeration') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 692 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted 'Strip missing wildcards, keep unwildcarded names') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 693 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted 'for /R passed') batch.c:312: Test failed: unexpected char 0x50 position 0 in line 694 (got 'Plain directory enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 695 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 696 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 697 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 698 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 699 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 700 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 701 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 702 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 703 (got 'File enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 704 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 705 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 706 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 707 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 708 (got 'File enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 709 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 710 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 711 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 712 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x4d position 0 in line 713 (got 'Mixed enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 714 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 715 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 716 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 717 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 718 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 719 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 720 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 721 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 722 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 723 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 724 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 725 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x4d position 0 in line 726 (got 'Mixed enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 727 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 728 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 729 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 730 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 731 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 732 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 733 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 734 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 735 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 736 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 737 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 738 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x57 position 0 in line 739 (got 'With duplicates enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 740 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 741 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 742 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 743 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 744 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 745 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 746 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 747 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 748 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 749 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 750 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 751 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 752 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 753 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 754 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 755 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 756 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 757 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 758 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 759 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 760 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 761 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 762 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 763 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 764 (got 'Strip missing wildcards, keep unwildcarded names', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 765 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 766 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 767 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 768 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 769 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 770 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 771 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 772 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 773 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 774 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 775 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 776 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x66 position 0 in line 777 (got 'for /R passed', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1361 (got 'Finished:', wanted 'value2') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1362 (got 'value2', wanted '2set1endvalue1') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1363 (got 'C:\Documents and Settings\winetest\My Documents\foobar\foodir2', wanted '@pwd@\foobar\foodir3') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1364 (got 'value1', wanted 'Finished:') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1365 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted 'value2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1366 (got '--- Extra endlocal in called batch', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1367 (got '--- Extra endlocal in called batch', wanted 'value1') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1368 (got '--- Extra endlocal in called batch', wanted '@pwd@\foobar') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1370 (got 'Finished:', wanted 'value2') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1373 (got 'value1', wanted 'value2') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1374 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1375 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1376 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1377 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1378 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1379 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@pwd@\foobar')

Feb. 7, 2014

Re: [Tools] winetest: Make the WineTest executable links more visible.

by André Hentschel

Am 07.02.2014 18:31, schrieb Alexandre Julliard: > Francois Gouget <fgouget(a)free.fr> writes: > >> --- >> >> As per WineConf. >> Note that the choice of a 'legend' class rather than nothing or some >> other class is mostly a matter of taste. > > I don't think that users not finding the test binary is a major > problem. A better approach would be to add some help page on the wiki > and link to that. > After fosdem i checked that again and in fact i think we link quite good to it: wiki.winehq.org/ConformanceTests

Feb. 7, 2014

Re: kernel32: In FindFirstFileExW(), call NtQueryDirectoryFile() again to determine if it read all files.

by Ken Thomases

On Feb 7, 2014, at 5:59 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> On Feb 4, 2014, at 4:37 AM, Alexandre Julliard wrote: >> >>> Ken Thomases <ken(a)codeweavers.com> writes: >>> >>>> I'm open to suggestions for other ways to fix it. Can a directory >>>> handle be made to carry additional state? >>> >>> Not at this point, but we probably want to add a mechanism for that and >>> get rid of the whole getdirentries mess. >> >> Instead of getdirentries(), we'd use readdir()? And the extra state would be an index of the next entry to return (so NtQueryDirectoryFile() would skip that many entries, unless told to restart)? >> >> Or did you have something else in mind? > > My plan is rather to move the caching of the whole directory from > kernel32 to ntdll. Hmm. Isn't a file handle potentially shared among processes? How would the cache, as well as the read position within it, be coordinated? -Ken

Feb. 7, 2014

Re: Preferred License for Presentations?

by Michael Stefaniuc

On 02/07/2014 06:34 PM, Vincent Povirk wrote: > Is there any reason not to just choose the most permissive one? I already went with Creative Commons. bye michael

Feb. 7, 2014

Re: Preferred License for Presentations?

by Vincent Povirk

Is there any reason not to just choose the most permissive one?

Feb. 7, 2014

Re: [Tools] winetest: Make the WineTest executable links more visible.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > --- > > As per WineConf. > Note that the choice of a 'legend' class rather than nothing or some > other class is mostly a matter of taste. I don't think that users not finding the test binary is a major problem. A better approach would be to add some help page on the wiki and link to that. -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2014

Re: Call for updating recent news queue

by Rosanne DiMesio

On Fri, 07 Feb 2014 00:42:12 +0100 André Hentschel <nerv(a)dawncrow.de> wrote: > So it would be nice if everyone could have a look at: > > http://wiki.winehq.org/RecentNewsQueue > > and update it again. I know this worked last time, but we had no WWN for it. Even if this will be my first try to push out a WWN, i'll make sure this won't happen this time. > Thanks in advance > It might be a good idea to start by deleting most of what's there now--that stuff is 4 years old. However, some of the info about the old testbot might be usable in an updated article on the new testbot. One thing I have to ask, though: who is the target audience for WWN? It always seemed to me to be too technical for users and not technical enough for developers. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 7, 2014

Re: [PATCH 2/2] d3d9/tests: Test that Direct3D restores the pixel format on the window it targets. (try 2)

by Henri Verbeet

On 7 February 2014 02:13, Ken Thomases <ken(a)codeweavers.com> wrote: > > + ZeroMemory(&present_parameters, sizeof(present_parameters)); > + present_parameters.Windowed = TRUE; > + present_parameters.hDeviceWindow = hwnd; > + present_parameters.SwapEffect = D3DSWAPEFFECT_DISCARD; > + > + hr = IDirect3D9_CreateDevice(d3d9, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, > + hwnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &present_parameters, &device); > + if (FAILED(hr) || !device) > + { > + skip("Failed to create device\n"); > + goto cleanup; > + } Please use create_device() for creating the device, unless there's some reason it can't work here. > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "Present failed %#x\n", hr); I think an interesting test would be Present() with a non-NULL destination window. I'd also like the equivalent test for d3d8, and ddraw with a clip window.

Feb. 7, 2014

Preferred License for Presentations?

by Michael Stefaniuc

Hello guys, what license do we prefer to use for Wine presentations and the related material? For the LinuxTag presentation I have the option to pick one of: - Creative Commons License - UVM Lizenz für die freie Nutzung unveränderter Inhalte - GNU General Public License - UVM Lizenz für Freie Inhalte - GNU Free Documentation License thanks bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Supervisor, APAC/EMEA IT Network/Telephony Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera

Feb. 7, 2014

Re: questionarie

by Akihiro Sagawa

On Thu, 6 Feb 2014 22:01:55 +0900, Akira Nakagawa wrote: > Why my patch,101880 and 102083 are not commited? > They have no problem,certified by Akihiro. I know translation is important to Japanese users. But I can't approve your patches at this time. There are some points to need improvement. Patch 101880 (po file update): Translation looks good for me. I'm not sure why your patch is `New' status. But, if I were you, I would (1) remove X-Generator (redundant) header and (2) add explanation why translator mail address needs to update, then resubmit. Patch 102083 (Japanese man page): There are no update descriptions, thus it's not so easy to figure out your changes. From my point of view, my comments on Jan 22 are completely ignored in revised version. At least, I'd like to know why my comment isn't suitable. On a different note, please don't forget to set your e-mail client to send your English name. Awaiting your feedback. Regards, Akihiro Sagawa

Feb. 7, 2014

Re: kernel32: In FindFirstFileExW(), call NtQueryDirectoryFile() again to determine if it read all files.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > On Feb 4, 2014, at 4:37 AM, Alexandre Julliard wrote: > >> Ken Thomases <ken(a)codeweavers.com> writes: >> >>> I'm open to suggestions for other ways to fix it. Can a directory >>> handle be made to carry additional state? >> >> Not at this point, but we probably want to add a mechanism for that and >> get rid of the whole getdirentries mess. > > Instead of getdirentries(), we'd use readdir()? And the extra state would be an index of the next entry to return (so NtQueryDirectoryFile() would skip that many entries, unless told to restart)? > > Or did you have something else in mind? My plan is rather to move the caching of the whole directory from kernel32 to ntdll. -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2014

Re: [PATCH 1/2] msvcrt: Return error on invalid handle in _open_osfhandle

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 https://newtestbot.winehq.org/JobDetails.pl?Key=4655 Your paranoid android. === wxppro (32 bit file) === file.c:1417: Test failed: bad position 0 expecting 8 file.c:1419: Test failed: Couldn't read back the data file.c:1987: Test failed: i 0, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:1987: Test failed: i 1, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:1987: Test failed: i 2, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:2024: Test failed: fread() returned 0: ferror=0 file.c:2027: Test failed: got '' expected 'Hello worldHello worldHello world'

Feb. 7, 2014

Re: Call for updating recent news queue

by Jerome Leclanche

I suggest you talk about the command stream progress. It's a big deal for a lot of people. J. Leclanche On Thu, Feb 6, 2014 at 11:42 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Hi, > After getting some very positive feedback at FOSDEM2014 i decided (even with lack of time) to get WWN started again. > I'm still a developer, so my time is limited, therefor it would be nice if we could crowdsource this as far as possible. > So it would be nice if everyone could have a look at: > > http://wiki.winehq.org/RecentNewsQueue > > and update it again. I know this worked last time, but we had no WWN for it. Even if this will be my first try to push out a WWN, i'll make sure this won't happen this time. > Thanks in advance > >

Feb. 7, 2014

Re: [PATCH 2/2] d3d9/tests: Test that Direct3D restores the pixel format on the window it targets.

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 https://newtestbot.winehq.org/JobDetails.pl?Key=4644 Your paranoid android. === wxppro (32 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2 === wvista (32 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2 === w2008s64 (32 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2 === w7pro64 (32 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2 === w2008s64 (64 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2 === w7pro64 (64 bit device) === device.c:7445: Test failed: window has pixel format 0, expected 2 device.c:7455: Test failed: window has pixel format 0, expected 2

Feb. 7, 2014

Call for updating recent news queue

by André Hentschel

Hi, After getting some very positive feedback at FOSDEM2014 i decided (even with lack of time) to get WWN started again. I'm still a developer, so my time is limited, therefor it would be nice if we could crowdsource this as far as possible. So it would be nice if everyone could have a look at: http://wiki.winehq.org/RecentNewsQueue and update it again. I know this worked last time, but we had no WWN for it. Even if this will be my first try to push out a WWN, i'll make sure this won't happen this time. Thanks in advance

Feb. 6, 2014

Re: kernel32: In FindFirstFileExW(), call NtQueryDirectoryFile() again to determine if it read all files.

by Ken Thomases

On Feb 4, 2014, at 4:37 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> I'm open to suggestions for other ways to fix it. Can a directory >> handle be made to carry additional state? > > Not at this point, but we probably want to add a mechanism for that and > get rid of the whole getdirentries mess. Instead of getdirentries(), we'd use readdir()? And the extra state would be an index of the next entry to return (so NtQueryDirectoryFile() would skip that many entries, unless told to restart)? Or did you have something else in mind? -Ken

Feb. 6, 2014

FOSDEM Videos - previews

by Marcus Meissner

Hi, The FOSDEM Video team is still processing our videos. But! Previews can be checked out at: http://video.fosdem.org/2014/previews/AW1120/2014-02-02/ They are basically in order of appearance. The filenames are UTC (so Bruessel - 1 hour). (timetable:) https://fosdem.org/2014/schedule/track/wine/ Notes: - We only got the master recording laptop around 9:10, so Alexandres keynote is mostly lost in time and space. I did not dare him to redo it for us ;) - I failed to select the +48V switch in fear of blowing up the microphone. So sound arrived at 42:20 in the Pipelight Talk after the audio angel helped us. Sound is only on the left side. - The presenter laptop->slave laptop firewire cable was broken, so it only started working for Rosannes talk. (Its also the reason her talk is cut into various pieces as we rebooted the machines inbetween.) - Talks after Rosannes are good. - As there were no BOF topics, the recording slot is empty. - We did not record the blame session. Ciao, Marcus

Feb. 6, 2014

Re: msvcrt: Don't prevent msvcrt from getting unloaded

by Piotr Caban

On 02/06/14 15:54, Piotr Caban wrote: > --- > dlls/msvcrt/main.c | 3 --- > 1 file changed, 3 deletions(-) Please ignore this patch for now. It breaks the app it was originally added for (bug 21930).

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Michael Stefaniuc

On 02/06/2014 01:11 AM, Ken Thomases wrote: > On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: > >> - I will submit a talk proposal: "Is Wine Still Relevant?" … > > To me, this invites the reader to think "no" (even with a subtitle). > How about something like "Uses of Wine Today and in the Future"? That is a rhetoric question. Though people asked me indirectly or directly that question; that's why I've chosen it as title. bye michael

Feb. 6, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

On Feb 6, 2014, at 4:19 AM, Henri Verbeet wrote: > … It does have me wondering > slightly if wglMakeCurrent() shouldn't behave like that anyway if the > DC it gets passes is the same as the one the context was last current > with, but perhaps not enough to go find out. I don't think it can work that way. DC handle values get recycled pretty aggressively. Just because the handle value is the same between point A and point B doesn't mean it references the same window. > On 5 February 2014 20:20, Ken Thomases <ken(a)codeweavers.com> wrote: > >> In experimenting with implementing the extension and making wined3d use it, I discovered a complication. At the same point where wined3d attempts to restore the app's GL context, it also tries to restore the pixel format on the app's DC. On the one hand, my extension doesn't help with that which undermines its rationale since the DC is still required. On the other hand, that's the wrong thing for wined3d to try to do there! Wined3d has set the pixel format on its target window (through a DC it obtained itself). In many cases, the app will be targeting the same window with its GL context, but not always (as we've seen). So, wined3d should be trying to restore the pixel format of the window it modified, not the window the app's GL context may be targeting. >> > It may not be enough in some cases, and redundant in others, but I > don't think it's wrong as such. I.e., if the wined3d GL DC and the > application's GL DC aren't the same, restoring the pixel format on the > application's GL DC is redundant because we didn't touch it, but it > should never restore the wrong pixel format. Agreed, it won't restore the wrong pixel format. > There are two cases where it wouldn't be enough: > - The application has set a pixel format on the wined3d DC before, > is not currently using GL on that DC, but will do so (again) in the > future. I think this case can be fixed, although it's not entirely > trivial because of e.g. context_update_window(), and IMO a bit of a > rare case. I think I have a patch for this. It may not be ideal because it tracks the window to restore the pixel format on separately from the context window. (In some cases, e.g. swapchain backup DC, the context window is not what the context DC references.) I'll send it along in a bit. I suppose I need to add a test case, too. Anyway, I believe it's necessary to decouple restoring the pixel format from restoring the GL context, anyway, in order to use wglMakeContextCurrentWINE(). > - The application has never set a pixel format on the wined3d DC, > but will try to do so in the future. I don't think we can fix this > with the current WGL_WINE_pixel_format_passthrough implementation. As > soon as wined3d sets a pixel format, it becomes impossible for the > application to do so in the future. This is essentially bug 29934. Right. I don't have a solution for that with current APIs but WGL_WINE_surface will sidestep it. > In theory this entire issue should go away with wglGetSurfaceDCWINE() > though, because in that case we'd never have to restore the pixel > format at all, provided there's no way the application can get at the > same DC wined3d is using. Yeah, but, as I said, I think I need to solve the current case anyway, to the degree it can be solved. -Ken

Feb. 6, 2014

questionarie

by Akira Nakagawa

Why my patch,101880 and 102083 are not commited? They have no problem,certified by Akihiro. -- Akira Nakagawa <matyapiro31(a)gmail.com>

Feb. 6, 2014

Re: Profiling CS:GO

by Stefan Dösinger

Am 05.02.2014 um 17:22 schrieb Brock York <twunknown(a)gmail.com>: > >Quick reply from my phone: wglShareLists on Windows had to be called with neither context being current. I once hacked a workaround >together that created 20 extra contexts in advance with the primary one before making the first context current in one thread > Is this why WineD3D can't be used multithreaded under wine in CS:GO? I don't know much about how OpenGL and DirectX let alone their windows counterparts but I'm trying. It should work in current Wine (on Linux), but you may have to enable StrictDrawOrdering. Without that you may get some texture corruption, e.g. HUD parts are broken in CS:S if the game’s multithreading is enabled but StrictDrawOrdering isn’t. StrictDrawOrdering kills performance though. CSMT supersedes StrictDrawOrdering. > >One more thing: there are a few issues with the nvidia driver on the command stream. For testing, try to remove vertex buffer objects and >pixel buffer objects from the extension table in directx.c, disable glsl and enable the game's multithreading. That got me pretty decent >performance in cs:s. > This is for running and testing WineD3D under windows for testing that I should remove the VBO's and PBO's? Or is this for getting better performance when under wine in linux? This is for getting better performance on Wine in Linux.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Stefan Dösinger

Am 05.02.2014 um 21:26 schrieb Michael Stefaniuc <mstefani(a)redhat.com>: > <_Marcus_> and a Playing Windows games with Wine could be seperate if > necessary /& wanted... would surely also be interesting I think I could come up with something here, but not by tomorrow evening. I might need some advice in tailoring the message to the LinuxTag audience, whatever it may be.

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > >> + strcpy(buffer2, nonexistent); > >> + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); > > > > There is no need for a strcpy(). > Well, I'll add more tests later(like trailing \\). strcpy() could be added later when new tests get added. > >> + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); > >> + handle = FindFirstFileA(buffer2, &data); > >> + ok(handle != FindFirstFileA, "failed to find an existent file\n"); > > > > It would be useful to actually test what FindFirstFileA() returns. > > Also not leaking the handle *twice* would be a bonus point. > Thank you for mentioning that. > Most of the previous testcases leak the handle. > After this patch, is it necessary to fix them? Every handle leak is bad on its own, and may lead to unwanted side effects like inability to destroy an object or delete a file. Another thing that could be improved in this test is printing last error code in the failure message. Also you may find that making failure messages shorter and simpler makes your life a bit easier. For axample: "CreateFile(%s) error %d\n", name, GetLastError() and "FindFirstFile(%s) error %d\n", name, GetLastError() -- Dmitry.

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Zhenbo Li

Thank you. 2014-02-06 15:56 GMT+08:00 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Zhenbo Li <litimetal(a)gmail.com> wrote: > >> + strcpy(buffer2, nonexistent); >> + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); > > There is no need for a strcpy(). Well, I'll add more tests later(like trailing \\). > >> + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); >> + handle = FindFirstFileA(buffer2, &data); >> + ok(handle != FindFirstFileA, "failed to find an existent file\n"); > > It would be useful to actually test what FindFirstFileA() returns. > Also not leaking the handle *twice* would be a bonus point. Thank you for mentioning that. Most of the previous testcases leak the handle. After this patch, is it necessary to fix them? -- Have a nice day! Zhenbo Li

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Henri Verbeet

On 6 February 2014 10:29, Francois Gouget <fgouget(a)free.fr> wrote: > That would be true if Wine was universally viewed as important. However > there is a sentiment among free software radicals that because Wine > makes it possible to run Windows applications (which are viewed as 100% > non open-source), it's bad for Linux, open-source software, etc. So this > title just confirms that sentiment and is thus not necessarily > provocative (except on a Wine mailing list). > That was perhaps true at some point, but I have the impression that these days the sentiment is more that "Valve and Icculus are going to fix Linux gaming, nobody uses Wine for anything else anyway, and Free Software is just this thing that makes it harder for them to do so."

Feb. 6, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

On 5 February 2014 20:20, Ken Thomases <ken(a)codeweavers.com> wrote: >> Right. I was under the impression it would be used by >> wined3d_caps_gl_ctx_create() to avoid changing the current WGL DC. If >> it's only for restoring the application's GL context, I'm not sure how >> that's effectively much different from just making the application's >> GL context current on wined3d's DC? (I'd have to look into the details >> again, but IIRC that wasn't enough for bug 28869, even as a hack.) > > Well, it would be different because it wouldn't change the app's GL context to point at a potentially-different drawable. Which, by the way, is actually happening in bug 28869. The app does GL against a top-level window but uses ddraw/wined3d on a child window of that window. So, your hack wouldn't work because it would make the app's GL context current on a window that's destroyed soon after. > Actually, what confused me there was thinking of the current DC as thread state as opposed to context state. So yeah, wglMakeContextCurrentWINE() should work. It does have me wondering slightly if wglMakeCurrent() shouldn't behave like that anyway if the DC it gets passes is the same as the one the context was last current with, but perhaps not enough to go find out. > In experimenting with implementing the extension and making wined3d use it, I discovered a complication. At the same point where wined3d attempts to restore the app's GL context, it also tries to restore the pixel format on the app's DC. On the one hand, my extension doesn't help with that which undermines its rationale since the DC is still required. On the other hand, that's the wrong thing for wined3d to try to do there! Wined3d has set the pixel format on its target window (through a DC it obtained itself). In many cases, the app will be targeting the same window with its GL context, but not always (as we've seen). So, wined3d should be trying to restore the pixel format of the window it modified, not the window the app's GL context may be targeting. > It may not be enough in some cases, and redundant in others, but I don't think it's wrong as such. I.e., if the wined3d GL DC and the application's GL DC aren't the same, restoring the pixel format on the application's GL DC is redundant because we didn't touch it, but it should never restore the wrong pixel format. There are two cases where it wouldn't be enough: - The application has set a pixel format on the wined3d DC before, is not currently using GL on that DC, but will do so (again) in the future. I think this case can be fixed, although it's not entirely trivial because of e.g. context_update_window(), and IMO a bit of a rare case. - The application has never set a pixel format on the wined3d DC, but will try to do so in the future. I don't think we can fix this with the current WGL_WINE_pixel_format_passthrough implementation. As soon as wined3d sets a pixel format, it becomes impossible for the application to do so in the future. This is essentially bug 29934. In theory this entire issue should go away with wglGetSurfaceDCWINE() though, because in that case we'd never have to restore the pixel format at all, provided there's no way the application can get at the same DC wined3d is using.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Francois Gouget

On Wed, 5 Feb 2014, Rosanne DiMesio wrote: > On Wed, 5 Feb 2014 18:11:18 -0600 > Ken Thomases <ken(a)codeweavers.com> wrote: > > > On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: > > > > > - I will submit a talk proposal: "Is Wine Still Relevant?" … > > > > To me, this invites the reader to think "no" (even with a subtitle). > > How about something like "Uses of Wine Today and in the Future"? > > IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. That would be true if Wine was universally viewed as important. However there is a sentiment among free software radicals that because Wine makes it possible to run Windows applications (which are viewed as 100% non open-source), it's bad for Linux, open-source software, etc. So this title just confirms that sentiment and is thus not necessarily provocative (except on a Wine mailing list). So I think the opposite tack would be more provocative: What makes Wine THE most important open-source project or Wine: Still the most important open-source project or for a different talk: Status and future of the most important open-source project: Wine -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Feb. 6, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > + strcpy(buffer2, nonexistent); > + handle = CreateFileA(buffer2, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0 ); There is no need for a strcpy(). > + ok(handle != INVALID_HANDLE_VALUE, "failed to create a file\n"); > + handle = FindFirstFileA(buffer2, &data); > + ok(handle != FindFirstFileA, "failed to find an existent file\n"); It would be useful to actually test what FindFirstFileA() returns. Also not leaking the handle *twice* would be a bonus point. -- Dmitry.

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Rosanne DiMesio

On Wed, 5 Feb 2014 20:38:18 -0600 Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 5, 2014, at 7:52 PM, Rosanne DiMesio wrote: > > > On Wed, 5 Feb 2014 18:11:18 -0600 > > Ken Thomases <ken(a)codeweavers.com> wrote: > > > >> On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: > >> > >>> - I will submit a talk proposal: "Is Wine Still Relevant?" … > >> > >> To me, this invites the reader to think "no" (even with a subtitle). How about something like "Uses of Wine Today and in the Future"? > >> > > > > IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. > > Well, you're right that my alternative suggestion is dull as dirt. Terrible. Don't use that. > > But I stand by my first sentence. > Oh, I agree with your first sentence, too. But that's what makes the title so intriguing: it tells me the speaker knows I might say "no" and is going to challenge my thinking. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 6, 2014

Re: Wine at LinuxTag in Berlin

by Erich E. Hoover

On Wed, Feb 5, 2014 at 7:38 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 5, 2014, at 7:52 PM, Rosanne DiMesio wrote: > >> On Wed, 5 Feb 2014 18:11:18 -0600 >> Ken Thomases <ken(a)codeweavers.com> wrote: >> >>> On Feb 5, 2014, at 2:26 PM, Michael Stefaniuc wrote: >>> >>>> - I will submit a talk proposal: "Is Wine Still Relevant?" ... >>> >>> To me, this invites the reader to think "no" (even with a subtitle). How about something like "Uses of Wine Today and in the Future"? >>> >> >> IMO, "Is Wine Still Relevant?" sounds like a much more interesting, provocative talk. > > Well, you're right that my alternative suggestion is dull as dirt. Terrible. Don't use that. > > But I stand by my first sentence. > > -Ken "How Wine Remains Relevant" ? Best, Erich

Feb. 6, 2014