September 2015 - Wine-Devel

Re: [2/2] wininet/tests: Fix a couple of test failures.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16819 Your paranoid android. === w2000pro (32 bit http) === http.c:2400: Test failed: InternetReadFile failed 12030 http.c:2401: Test failed: count was wrong === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [1/2] wininet/tests: Never use a proxy for connections to localhost.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16818 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: How to add the Signed-off-by field in the git patch
by Hin-Tak Leung Sept. 22, 2015

Sept. 22, 2015

You don't need to edit git's config by hand - 'git config --global ... ' can do that for you. read the documentation for git-config, and particularly the --global option. I also have colorised diff and a few other useful thing configured. ------------------------------ On Tue, Sep 22, 2015 3:21 PM BST Aaryaman Vasishta wrote: >Hi Dimitry, > >Thanks! this will definitely help if this info is added to the wiki too. >Though it seems to be down right now. There's a discussion going on about >it on IRC right now. > >Cheers, >Aaryaman > >On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Hi all, >> >> since I personally asked that question and investigated a bit the subject, >> here is some information that could be probably useful to someone else: >> >> >> http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… >> >> http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… >> >> http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… >> http://git-scm.com/docs/git-format-patch (CONFIGURATION section) >> >> Personally I've chosen to add >> [format] >> signOff = true >> to git.config file. >> >> -- >> Dmitry. >> >> >>

1 0

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const
by Nikolay Sivov Sept. 22, 2015

Sept. 22, 2015

On 22.09.2015 0:06, Marcus Meissner wrote: > Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dinput/device.c | 4 ++-- > dlls/dinput/device_private.h | 4 ++-- > include/dinput.h | 8 ++++---- > 3 files changed, 8 insertions(+), 8 deletions(-) > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case?

4 3

No release this week
by Alexandre Julliard Sept. 21, 2015

Sept. 21, 2015

Hey guys, Because of WineConf, it looks like I won't be able to make a release today. And since I'll be taking some vacation next week, I plan to release 1.7.52 on Friday two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Marvin Sept. 21, 2015

Sept. 21, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16808 Your paranoid android. === w2003std (32 bit string) === Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 === w7u (32 bit string) === Failure running script in VM: timed out waiting for the child process

2 1

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban Sept. 21, 2015

Sept. 21, 2015

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

2 1

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer Sept. 20, 2015

Sept. 20, 2015

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer Sept. 20, 2015

Sept. 20, 2015

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: psapi/tests: Don't check for exact value (try 7)
by Marvin Sept. 20, 2015

Sept. 20, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16805 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 No test summary line found === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 No test summary line found

2 1

Wine test update
by Jeremy White Sept. 20, 2015

Sept. 20, 2015

We reviewed my list of interesting test bot vm failures: https://www.winehq.org/~jwhite/latest.html and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. The following glorious people volunteered to work on one or more of these issues: Andrew, Alexandre, Aric, Francois, Huw, Stefan, Piotr, Jacek, Qian, Hans, and Sebastian, and I've emailed Bruno to ask him to look into one. Cheers, Jeremy

2 1

Winsock 2
by Christopher Harrington Sept. 20, 2015

Sept. 20, 2015

I'm looking at trying to implement some of the Winsock 2 stubs, namely WSALookupServiceBegin/Next/End. I'm probably only going to implement enough of it that my target binary will stop bailing out with "out of memory". I suspect the app is using it to resolve DNS... Am I stepping on anyone's toes? If not, can someone point me at the right place to look for where wine is currently doing DNS lookups so I can reuse that non-broken code? Thank you in advance. -Chris Harrington

3 4

Changes for Wine on Debian
by Kyle Auble Sept. 20, 2015

Sept. 20, 2015

Hi everyone, I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now. Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons. When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself. - Kyle

4 8

RFC - oleaut32: Cope with invalid icon data
by Bruno Jesus Sept. 19, 2015

Sept. 19, 2015

While testing bug [1] I noticed that invalid data is sent to OLEPictureImpl_LoadIcon. This patch is meant to resist these kind of issues and makes the game goes on a little further until other crash. I'm sending this as RFC because I don't know then icon structure but my tests seem very straight forward from what I can guess from the function. [1] https://bugs.winehq.org/show_bug.cgi?id=21012 Thanks in advance and best regards, Bruno

1 0

Re: wined3d: TRACE fixes. (try 2)
by Henri Verbeet Sept. 18, 2015

Sept. 18, 2015

On 16 September 2015 at 14:39, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > @@ -1243,7 +1243,7 @@ static int context_choose_pixel_format(const struct wined3d_device *device, HDC > unsigned int cfg_count = device->adapter->cfg_count; > unsigned int i; > > - TRACE("device %p, dc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > + TRACE("device %p, hdc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > device, hdc, debug_d3dformat(color_format->id), debug_d3dformat(ds_format->id), > auxBuffers, findCompatible); This isn't wrong, but I'd be more inclined to change the parameter to match the trace than the other way around. > @@ -157,8 +157,8 @@ HRESULT CDECL wined3d_palette_create(struct wined3d_device *device, DWORD flags, > struct wined3d_palette *object; > HRESULT hr; > > - TRACE("device %p, flags %#x, entries %p, palette %p.\n", > - device, flags, entries, palette); > + TRACE("device %p, flags %#x, entry_count %d, entries %p, palette %p.\n", > + device, flags, entry_count, entries, palette); Unsigned values should use %u instead of %d. > @@ -114,7 +114,7 @@ enum wined3d_event_query_result wined3d_event_query_finish(const struct wined3d_ > const struct wined3d_gl_info *gl_info; > enum wined3d_event_query_result ret; > > - TRACE("(%p)\n", query); > + TRACE("(%p, %p)\n", query, device); This isn't wrong per se either, but I'd prefer that as "query %p, device %p.\n" like the rest of wined3d. > @@ -1275,7 +1275,7 @@ static void shader_dump_decl_usage(const struct wined3d_shader_semantic *semanti > break; > > case WINED3D_DECL_USAGE_BLEND_INDICES: > - TRACE("blend"); > + TRACE("indices"); I'd either just leave that the way it is, or change it to "blendindices". In the latter case you'd have to change the one for WINED3D_DECL_USAGE_BLEND_WEIGHT to "blendweight", and the one for WINED3D_DECL_USAGE_TEXCOORD to "texcoord%u" as well. > @@ -2037,8 +2037,8 @@ static HRESULT shader_set_function(struct wined3d_shader *shader, const DWORD *b > unsigned int backend_version; > const struct wined3d_d3d_info *d3d_info = &shader->device->adapter->d3d_info; > > - TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u.\n", > - shader, byte_code, output_signature, float_const_count); > + TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u, type %#x, max_version %d.\n", > + shader, byte_code, output_signature, float_const_count, type, max_version); %d -> %u

1 0

Optimizing synchronization objects
by Daniel Santos Sept. 17, 2015

Sept. 17, 2015

Alexandre, First off I apologize for the size of this email, I'm trying to keep it as concise as possible. I've been experimenting with ways to optimize synchronization objects and have implemented a promising proof of concept for semaphores using glibc's nptl (posix) semaphore implementation. I posted revision 3 of this today, although I appear to have used the wrong msg id in the --in-reply-to header. :( So my goal is to eventually make similar optimizations for all synchronization objects, or at least those that have demonstrable performance problems. The basic theory of operation is that when a client sends a create_semaphore, the server creates a posix semaphore with a unique name which is passes to the client process so that it can open it locally. This allows the client to perform ReleaseSemaphore without a server call as well as WaitFor(Multiple|Single)Object(s) for cases where the wait condition can be determined to be satisfied without a server call (i.e., either bWaitAll = FALSE and a signalled semaphore is found in the handle list prior to a non-semaphore objects or bWaitAll = TRUE and all handles are signalled semaphores). For all other conditions, it uses a traditional server call. However, it has two problems: 1. It uses glibc's implementation of POSIX semaphores which uses shared memory to share them with other processes, and 2. It uses glibc's implementation of POSIX semaphores which are incompatible across 32- and 64-bit ABI processes. I have not been able to find any more flaws in a case where both program and wineserver are the same ABI. All tests pass and I've added one more (although more tests are clearly needed). Since this implementation only uses sem_trywait (and never sem_wait or sem_timedwait), we don't really even need a full-featured semaphore -- a simple 32- or 16-bit number that's accessed atomically would suffice as a replacement. Although I did plan to eventually explore having a client program block w/o calling the server, the benefit of that is minimal compared to the benefit of being able to avoid the server call for releasing a semaphore and "wait"ing when the semaphore is already available. So now I want to understand the minimum threshold of acceptability in wine for such a mechanism. We discussed this in chat and quite a bit and can I see many possibilities, each with its own particular issues. I'm listing them in order of my personal preference (most preferred first). Option 1: Simple shared memory & roll our own semaphore Similar to what glibc's NPTL semaphores are doing, except that we would only need a single integral value and not even a futex. The obvious downside is that a process can corrupt this memory and cause dysfunction of other processes who also have semaphores in that page. This could be minimized by giving every process their own page that is only shared between the server and the process unless a semaphore in that process is shared with another program, at which time the memory page could be shared with that process as well. Thus, the scope of possible corruption is limited to how far you share the object. In the worse case of memory corruption, the wineserver would either leave a thread of one of these processes hung, release one when it shouldn't be released or determine that the memory is corrupted, issue an error message, set the last error to something appropriate and return WAIT_FAILED. Option 2: System V semaphores On Linux, these are hosted in the kernel, so you can't just accidentally overwrite them. They will be slightly slower than shared memory due to the system call overhead. You probably know them better than I, but at the risk or stating the obvious, the following are their limitations. Their max value on Linux is SHRT_MAX so any request for a higher lMaximumCount would have to be clipped. There are also limits on Linux that can be adjusted by root if needed for some application, but the default is a maximum of 32000 (SEMVMX) total semaphores on the system, 128 (SEMMNI) semaphore sets and a max size of 250 (SEMMSL) semaphores per set. They are also persistent, so if the wine server crashes, they can leave behind clutter. Option 3: Move semaphores completely into the client In this scenario, the wine server can never be exposed to corrupted data. It is very fast when locking can be performed in the client, but very complicated and potentially slower for mixed locks. Calls to WaitForMultipleObjectsEx containing both semaphores and other objects (especially with bWaitAll = TRUE) may require multiple request/reply cycles to complete. The client must successfully lock the semaphores prior to the server calling satisfied on the server-side objects. Here is an optimistic use case that only requires a single request/reply cycle 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which succeeds. 3. Client passes request to server (with semaphore states) and blocks on pipe 4. Server gets value of all server-side objects and determines that the condition can be satisfied, so calls satisfied on all objects 5. Server sends response to client 6. Client wakes up and completes the wait call. Here is a slightly less optimistic case 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which fails on one semaphore. 3. Client rolls back locks on all which had succeeded. 4. Client passes request to server (with semaphore states) 5. Client blocks on the semaphore that was locked and the server pipe 6. Server updates thread status (blocking on native object) 7. Semaphore is signaled and client wakes up 8. Lock is obtained on semaphore that was previously locked 9. Client now calls trywait on remaining semaphores which again succeeds. 10. Client sends update to server and blocks on pipe 11. Server checks all server-side objects, which are all signaled, so calls satisfied on all objects 12. Server updates thread status and notifies client 13. Client wakes up and completes wait call. As you can see this can get more complicated. If the server discovers that an server object isn't signaled it will have to notify the client to rollback the locks and wait for server objects to be ready. So which of these solution is most appealing to you?

4 10

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.
by Henri Verbeet Sept. 17, 2015

Sept. 17, 2015

On 16 September 2015 at 00:02, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > This patch series fixes several places where glyph table values are > not const, preventing the compiler from placing the table in read-only > memory. > Did you verify this does what you think it does? I suspect you don't really understand const and relocations.

2 5

Prep for Wineconf - testing
by Jeremy White Sept. 17, 2015

Sept. 17, 2015

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [10/10] msvcirt: Implement strstreambuf::seekoff (resend)
by Piotr Caban Sept. 17, 2015

Sept. 17, 2015

Hi, On 09/17/15 11:06, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(strstreambuf_seekoff, 16) > streampos __thiscall strstreambuf_seekoff(strstreambuf *this, streamoff offset, ios_seek_dir dir, int mode) > { > - FIXME("(%p %d %d %d) stub\n", this, offset, dir, mode); > - return EOF; > + char *base[3]; > + > + TRACE("(%p %d %d %d)\n", this, offset, dir, mode); > + > + if (dir < 0 || dir > 2 || !(mode & (OPENMODE_in|OPENMODE_out))) > + return EOF; > + /* read buffer */ > + if (mode & OPENMODE_in) { > + base[0] = this->base.eback; > + base[1] = this->base.gptr; > + base[2] = this->base.egptr; The code will be easier to read if you use SEEKDIR_beg, SEEKDIR_cur and SEEKDIR_end instead of its values. > + if (this->base.gptr >= this->base.egptr) > + call_streambuf_underflow(&this->base); According to my testing call_streambuf_underflow should be called always, even so default implementation will just return in this case. I was not really checking it but it looks wrong that you store base table values before underflow is called. Patches 1-9 looks good for me. Thanks, Piotr

1 0

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME
by Henri Verbeet Sept. 17, 2015

Sept. 17, 2015

On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=39277 > > Side note: I'm pretty sure I've seen this or a similar issue on my > Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it > further at the time, so I'd really like to see this committed :). > This should probably go to winediag then.

2 2

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2)
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16776 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

Re: rsaenh/tests: Adjust length value to pass on Win 10
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16775 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

The fg-xxx VMs now accessible on demand
by Francois Gouget Sept. 16, 2015

Sept. 16, 2015

So as you may know I run WineTest in a variety of Windows configurations daily (28). The results can be seen on test.winehq.org but the problem is investigating the test failures because most of these configurations cannot be found on the Wine TestBot. I have three options to work around this: * As I mentionned before (1), if you're interested in a specific configuration I may be able to temporarily switch a WineTestBot VM to that configuration. * Another option is to send me an executable to run in the VM and I'll send back the results. * And the new option is that I can now give you VNC access to the VM. Access is open to any Wine developer (i.e. you got a patch accepted in Wine). To get access to the VM contact me on IRC or send me an email and give me the tag of the VM configuration you're interested in (e.g. fg-winxp-lusr). Then I'll start up the VM in the right configuration and send you the address to use to connect to the VM. Of course if I'm asleep or out you may have to wait a bit to get access. Also my uplink is not very fast so expect slow refreshes and some lag. But in the short test I've done it seems to be usable (at least to someone who's used to transatlantic VNC links with an elastic mouse pointer). And for reference here is a list of the available VM configurations. We may not care about some of them, for instance those running the earlier service pack revisions. Let me know if that's the case. Windows 2000 ------------ The French Windows 2000 Professional SP4 installed from an official Microsoft CD. Unless otherwise noted the tests are run in an administrator account. fg-win2000-4sp IE 5.00 SP2 fg-win2000-ie55 = 4sp + IE 5.5 SP2, MSXML3 fg-win2000-ie6 = ie55 + IE 6.0 SP1 fg-win2000-up1 = ie6 + all updates up to 2011/03/21 fg-win2000-uplast = up1 + DirectX 9.0c, WMP 9, .Net 1.1 & 2.0 fg-win2000-rusr = uplast but in a 'Restricted User' account fg-win2000-susr = uplast but in a 'Power User' account Windows XP ---------- I created this VM from the Compaq Windows XP partition of my (former) computer. So this started with a number of extra non-Microsoft applications (blasts from the past: Netscape 7, RealOne Player, etc.). On the one hand this is more representative of what Windows users normally have and on the other the configuration is not as 'straight out of the box' as the other VMs. That may not matter though. fg-winxp-1sp XP SP 1, IE 6.0 SP1, DirectX 8.1 fg-winxp-2sp = 1sp + XP SP2, IE 6.0, DirectX 9.0c, .Net 1.0 SP3 fg-winxp-2spie7 = 2sp + IE 7.0, WMP 10, .Net 1.1 fg-winxp-3sp = 2spie7 + XP SP3, WMP 11, .Net 2.0 SP2 & 3.0 SP2 & 3.5 SP1 fg-winxp-3spie8 = 3sp + IE 8 fg-winxp-last = 3spie8 + all updates up to 2011/09/08 fg-winxp-lusr = last but in a 'Limited User' account Windows 7 --------- Installed from an official English Windows 7 Ultimate CD. Unless otherwise noted the tests are run in an administrator account with Elevated Privileges. fg-win7u64-0sp Base install + French language pack (but still configured for English) fg-win7u64-1sp = 0sp + SP1 fg-win7u64-1spie9(64) = 1sp + IE 9.0, all language packs fg-win7u64-1spie9adm = 1spie9 but no 'Elevated Privileges' fg-win7u64-1spie9usr = 1spie9 but in a 'Standard user' account fg-win7u64-1spie9-ar = 1spie9 but in an Arabic locale fg-win7u64-1spie9-de = 1spie9 but in a German locale fg-win7u64-1spie9-es = 1spie9 but in a Spanish locale fg-win7u64-1spie9-fr = 1spie9 but in a French locale fg-win7u64-1spie9-he = 1spie9 but in a Hebrew locale fg-win7u64-1spie9-ja = 1spie9 but in a Japanese locale fg-win7u64-1spie9-ko = 1spie9 but in a Korean locale fg-win7u64-1spie9-mx = 1spie9 but in a mixed locale (1) https://www.winehq.org/pipermail/wine-devel/2015-September/109252.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

1 0

Re: [PATCH 1/4] xaudio2: Implement IXAudio2SourceVoice frequency functions
by Chris Robinson Sept. 16, 2015

Sept. 16, 2015

On 09/15/2015 10:25 AM, Andrew Eikum wrote: > @@ -801,14 +802,26 @@ static HRESULT WINAPI XA2SRC_SetFrequencyRatio(IXAudio2SourceVoice *iface, > float Ratio, UINT32 OperationSet) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %f, 0x%x\n", This, Ratio, OperationSet); > + > + EnterCriticalSection(&This->lock); > + > + This->freq_ratio = Ratio; > + This->freq = This->fmt->nSamplesPerSec * Ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; ... > @@ -816,7 +829,16 @@ static HRESULT WINAPI XA2SRC_SetSourceSampleRate( > UINT32 NewSourceSampleRate) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %u\n", This, NewSourceSampleRate); > + > + EnterCriticalSection(&This->lock); > + > + This->fmt->nSamplesPerSec = NewSourceSampleRate; > + This->freq = NewSourceSampleRate * This->freq_ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; > } ... > @@ -2989,7 +3012,7 @@ static BOOL xa2buffer_queue_period(XA2SourceImpl *src, XA2Buffer *buf, ALuint al > buf->offs_bytes += submit_bytes; > > alBufferData(al_buf, src->al_fmt, submit_buf, submit_bytes, > - src->fmt->nSamplesPerSec); > + src->freq); > > alSourceQueueBuffers(src->al_src, 1, &al_buf); > This doesn't strike me as correct. Assuming the SampleRate or FrequencyRatio can be altered in real-time, this will break the OpenAL buffer queue which needs to have the same sample rate on each buffer. SetFrequencyRatio looks like it'd map directly to the AL source's pitch property, while SetSourceSampleRate may be a bit trickier depending on when it's allowed to be called (it'd require stopping the source and clearing the queue, then rebuffering and requeueing the buffers to start where it left off). Also, I notice the OperationSet parameter isn't used. What is that for?

2 1

RFC: Hybrid (wineserver / process-local) native semaphores
by Daniel Santos Sept. 16, 2015

Sept. 16, 2015

This patch set fixes most performance problems caused by ReleaseSemaphore() and WaitForSingle/MultipleObject(s) making server calls. One victim of this is Star Wars Battlefront (https://bugs.winehq.org/show_bug.cgi?id=29582) where the majority of the CPU time is spent on context switching while the program spams ReleaseSemaphore, WaitForSingle/MultipleObject(s) and GetForgroundWindow, the later of which I made a work-around hack for and that some players have been using. This patch set doubles performance of bug #29582. (When combined with GetForgroundWindow hack the problem is completely resolved.) The patch set works by having the server create a POSIX semaphore object and sharing the key to that object with the client process, enabling the client process to be able to implement ReleaseSemaphore and optimistic-case wait calls (where no blocking is reburied) without a server call. Blocking waits and any wait-multiple that cannot be resolved in the client process (e.g., bWaitAll=TRUE and objects include non-semaphores) is still handled by the server. (Implementing blocking wait calls on the client can yield some performance improvements because a context switch to another thread in the same program won't require swapping out the memory map & such, but I would expect this to be less significant.) However, upon further experimentation, I discovered that POSIX semaphores in glibc are actually implemented using a shared memory page, which may not be acceptable since a bad process can corrupt that page and potentially cause sem_* function calls in the server to fail as well as other client programs fail and/or deadlock. I am working on a System V adaptation, but I thought it would be a good idea to see feedback & comments now. Another problem is that this causes the threadpool test fails at line 1299, where the previous "release all semaphores and wait for callback" test is done in reverse order. I presume this is due to the nature of the linux scheduler being inconsistent with how Windows *happens* to schedule its threads. I have an idea for a fix for this already, but I will still have to dig deeper into it. The code is still in experimental quality (assert(0)s and such) and I've already re-worked the configure.ac stuff, I'm mostly concerned with feedback on the general scheme. Thanks! Daniel

5 46

Re: [PATCH 1/3] oledb32: Add DataConvert support of DBTYPE_VARIANT(NULL) to DBTYPE_DBDATE
by Nikolay Sivov Sept. 16, 2015

Sept. 16, 2015

If it acts the same for all source variant types it looks like it'd be better to test them all and have this case handled once.

2 1

Re: [3/3] Add period to status bar, dialog box messages (try 2)
by Nikolay Sivov Sept. 16, 2015

Sept. 16, 2015

On 15.09.2015 11:28, Florian Pelz wrote: > STRINGTABLE > { > - IDS_STATUS_DONE "Done" > + IDS_STATUS_DONE "Done." > IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." > } I don't think it's better really to have punctuation in status bars. Probably messages can live without it, unless they consist of multiple sentences, then last one needs termination too.

2 2

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16750 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0003012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung Sept. 16, 2015

Sept. 16, 2015

------------------------------ On Wed, Sep 16, 2015 3:45 AM BST Vincent Povirk wrote: >> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? > >Currently, Wine does not have the ability to load pure .NET PE images >in a 64-bit process. > >Ntdll needs to call _CorValidateImage during the loading process. >_CorValidateImage needs to convert the image, in memory, to the >correct architecture. > >It's complicated, and I don't have a solution. Actually you do :-). Using http://madewokherd.nfshost.com/omgsecret/mono-64bit-exe.tar.gz from https://bugs.winehq.org/show_bug.cgi?id=30518 It is a bit dated, but does the job. I was very confused by both of libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll in c:/windows/mono/mono-2.0/bin/ In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll are never used, at the moment. When 64-bit mono loads a .NET PE image which then P/Invoke, it does so P/Invoke to 64-bit dlls.

2 1

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION. (try 2)
by Dmitry Timoshkov Sept. 16, 2015

Sept. 16, 2015

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > +void X11DRV_FlashWindow( HWND hwnd, BOOL bInvert ) > +{ > + struct x11drv_win_data *data = get_win_data( hwnd ); > + XEvent xev; > + > + if (!data) > + return; > + > + memset( &xev, 0, sizeof(xev) ); > + xev.type = ClientMessage; > + xev.xclient.window = data->whole_window; > + xev.xclient.message_type = x11drv_atom( _NET_WM_STATE ); > + xev.xclient.format = 32; > + xev.xclient.data.l[0] = 1; > + xev.xclient.data.l[1] = XInternAtom( data->display, "_NET_WM_STATE_DEMANDS_ATTENTION", > + False ); > + > + XSendEvent( data->display, DefaultRootWindow( data->display ), False, > + SubstructureNotifyMask, &xev ); > + release_win_data( data ); > +} This can't work, please have a look how XSendEvent is used in other parts of x11drv. -- Dmitry.

1 0

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with UrgencyHint flag.
by Dmitry Timoshkov Sept. 16, 2015

Sept. 16, 2015

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > This patch only set UrgencyHint flag when the window is minimized. > Because X11 only define UrgencyHint, the specific UI effect is > implemented by WM/DE. Different WM/DE may have different UI effect > which is quite different from Windows. Probably FlashWindow should be implemented with _NET_WM_STATE_DEMANDS_ATTENTION instead. -- Dmitry.

2 1

disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung Sept. 16, 2015

Sept. 16, 2015

Hi, I am not having any luck trying to disable wow64 temporarily to test 64-bit wine-mono P/invoke . I tried moving syswow64, removing 32-bit wine, moving wow32.dll, etc. It either insists on p/invoking 32-bit dlls, or not recognizing the .net assembly at all. What I like to do is to test a pure 64-bit code-path - starting with neutral .net assembly, p/invoke to 64-bit dll's. This is possible on windows - in fact cmd.exe on win 8 64-bit will refuse to p/invoke to 32-bit dll's. Is there any way of doing this with 64-bit wine and 64-bit wine-mono? Hin-Tak

2 1

Re: [PATCH 3/4] xaudio2: Call OnStreamEnd callback
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16733 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB6EDD4B7D === w1064 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFC549A4B7D

1 0

Re: [PATCH] mshtml: Fixed tests on some Windows versions.
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16726 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 === w1064 (64 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132

1 0

Re: ieframe: Fixed tests on some VMs.
by Marvin Sept. 16, 2015

Sept. 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=16725 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE === w1064 (32 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 === w1064 (64 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182

1 0

Re: [PATCH 7/7] wined3d: remove wined3d_surface_preload
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; You don't need this anymore.

1 0

Re: [PATCH 5/7] wined3d: remove wined3d_volume_from_resource from the public api
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 7fb136d..49ed8db 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2332,6 +2332,7 @@ BOOL volume_prepare_system_memory(struct wined3d_volume *volume) DECLSPEC_HIDDEN > HRESULT wined3d_volume_create(struct wined3d_texture *container, const struct wined3d_resource_desc *desc, > unsigned int level, struct wined3d_volume **volume) DECLSPEC_HIDDEN; > void wined3d_volume_destroy(struct wined3d_volume *volume) DECLSPEC_HIDDEN; > +struct wined3d_volume *wined3d_volume_from_resource(struct wined3d_resource *resource) DECLSPEC_HIDDEN; You never want to use this from inside wined3d. If there are any callers they should use volume_from_resource() instead.

1 0

Re: [PATCH 3/7] wined3d: introduce new wined3d_texture_(un)map functions
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static const struct wined3d_texture_ops texture2d_ops = > { > texture2d_sub_resource_load, > @@ -924,6 +935,8 @@ static const struct wined3d_texture_ops texture2d_ops = > texture2d_sub_resource_validate_location, > texture2d_sub_resource_upload_data, > texture2d_prepare_texture, > + texture2d_sub_resource_map, > + texture2d_sub_resource_unmap, > }; > Please keep the various sub_resource operations together. (I.e., keep texture_prepare_texture last.) You're probably also missing some wined3d_private.h changes here that ended up in the next patch. It doesn't make sense to introduce these without users, so what you'd want to do is e.g. first make the change for d3d10_texture2d_Map(), then for d3d10_texture2d_Unmap(), etc.

1 0

Re: [PATCH 2/7] wined3d: pass a wined3d_box to wined3d_surface_map
by Stefan Dösinger Sept. 15, 2015

Sept. 15, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:13 schrieb Riccardo Bortolato: > + hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect ? (const struct wined3d_box *)&box : NULL, flags); Why do you need the cast? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9x41AAoJEN0/YqbEcdMw5H4P/i9IrXL1PHd3pzoSmu2ObeSg rYWjMykbp0rh39JwXioBnMqbOCfneEjCSESHGqChNYQ4ZUHyMa6v8M0SOelvxlsA s9sQDs1YBRreXHTMlJSze4/jkHuOSFPCCiVueYLXsyoPunjER+KielzvICZ7lFYQ MQtHi6VwvUDiZJb7UaU3EeiUz2Drxq/Tki5OOgl+NS0rVQXRrecaA3qimPKEpbpI SkXChNulMWHM5q1cboxfP585R7SX12RnirNH0Wwx5kgv21gnvJGVB4eLirPNeKvA FnYAeGqo0ct3ruY9O77UMQFZTbAfn20Jv1EP4ZD0dAhUaUeSzPKQ9I68f+LYC5tG jiwZ7+8E/ReGWXRWcmHF3gnp3SumFl4RtQl8oz4jcqwoH42+xaaSMn5NDam4Hx0s sImgiqEG1ga7sCTOFUIL3q+0XkCpmXMwsjuBxxdZO1qRzSw9MlSgf1BpGsl3rJUb gHI4E+CsgHgUtP8ANyAPJBEbX87JEZ4SDycPwvgNIPQL84hRi0j+FvTJuJe26SN3 47qorsnjy9i/HrtTZXu613qhB07oMedyowWFRqI4EhRv8aKBUB6efzo8/LVHNU2v Sdfy3iI6d6Z+01sZa7nkdbAxeeASfEJ0tSKYN8ikRe0ahPhbRSFU0aD3/4+smQT6 EHW5Os4oDmiycqCxwogK =PePB -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/7] wined3d: store wined3d_texture and sub_resource_idx in d3d8, d3d9 and ddraw surfaces and volumes
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:13, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index d12805f..d1eebbb 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -193,10 +193,13 @@ struct d3d9_volume > struct d3d9_resource resource; > struct wined3d_volume *wined3d_volume; > struct d3d9_texture *texture; > + struct wined3d_texture *wined3d_texture; > + UINT sub_resource_idx; I'd prefer "unsigned int", but it's not that important. We'll probably want "wined3d_texture" and "sub_resource_idx" before "wined3d_volume". > -void volume_init(struct d3d9_volume *volume, struct d3d9_texture *texture, > - struct wined3d_volume *wined3d_volume, const struct wined3d_parent_ops **parent_ops) DECLSPEC_HIDDEN; > +void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > + const struct wined3d_parent_ops **parent_ops, > + struct wined3d_texture *wined3d_texture, unsigned int sub_resource_idx) DECLSPEC_HIDDEN; Please keep "parent_ops" the last parameter. You don't need the wined3d_volume parameter here. Affects the device_parent calls as well. > @@ -5395,6 +5395,7 @@ HRESULT wined3d_surface_create(struct wined3d_texture *container, const struct w > struct wined3d_surface *object; > void *parent; > HRESULT hr; > + UINT sub_resource_idx = layer * container->level_count + level; This probably doesn't need its own variable. I think it makes sense to split this patch in two, one making the change for volumes, and one making the change for surfaces.

1 0

Re: [PATCH 8/8] d3d11/tests: Add basic test for ID3D11InputLayout.
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1277,4 +1334,5 @@ START_TEST(d3d11) > test_depthstencil_view_interfaces(); > test_create_rendertarget_view(); > test_create_shader_resource_view(); > + test_create_input_layout(); > } I don't think this needs its own test. There will be plenty of places that create input layouts once we start drawing things. If nothing else, d3d10core has the test_il_append_aligned() test that tests some more specific input layout things.

1 0

Re: [PATCH 3/8] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > There's an ugly check if *immediate_context is NULL. It will go away > when we have a stub interface for the immediate context. > --- That usually means the ordering of the patches isn't quite right. :) Although I suppose it's not too bad in this case, but you should at least add some kind of FIXME comment. > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Looking at the associated test, you may have misunderstood what I meant yesterday. If "swapchain_out" is NULL, you're creating a swapchain only to release it right away again. It may be the case that that's correct because of the side effects like the validation of swapchain_desc and potential window messages that end up being sent, but I suspect we should simply skip creating the swapchain.

1 0

regsvr32.exe tests
by Hugh McMaster Sept. 15, 2015

Sept. 15, 2015

Over the past few weeks I've been sending a number of patches for regsvr32.exe to the wine-patches mailing list. Those patches are the product of a new test suite written for regsvr32.exe. The good news is that all of the tests now pass on Wine. The bad news is that the test suite is not suitable for wine-patches because I haven't been able to produce the test DLLs at runtime. The PE header format is complicated and I'm not too sure what I'm doing. In the meantime, anyone who is interested in the regsvr32.exe tests can download the source and test DLLs from the link below. https://www.dropbox.com/sh/39sytyithd76x97/AAD-FntoMfEvhvrqAnWyW6QJa?dl=0 Any comments on the tests and/or help with the PE header issue etc. are welcome.

1 0

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).
by Jacek Caban Sept. 15, 2015

Sept. 15, 2015

Hi Dmitry, On 09/02/15 07:44, Dmitry Timoshkov wrote: > + if (member == DISPID_HTTPREQUEST_OPTION) Why can't we use standard, ITypeInfo-based implementation here? > + { > + VARIANT ret_value, option; > + UINT err_pos; > + > + if (!result) result = &ret_value; > + if (!arg_err) arg_err = &err_pos; > + > + VariantInit( &option ); > + VariantInit( result ); > + > + if (flags == DISPATCH_PROPERTYPUT) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > + if (FAILED(hr)) > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > + if (FAILED(hr)) > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + > + return S_OK; I don't think silently returning S_OK is right for not handled flags. Thanks, Jacek

2 9

Re: wined3d: Fix TRACE in shader_dump_decl_usage().
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 11:11, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > case WINED3D_SHADER_RESOURCE_TEXTURE_3D: > - TRACE("_volume"); > + TRACE("_3d"); I think the change makes sense, but it's not really a fix. We can essentially call this whatever we like. Originally this was based on the d3d9 naming where you have "dcl_volume". OpenGL and d3d10+ call these 3D textures.

1 0

Re: [PATCH] ntdll/tests: Skip RtlRandom tests on Windows 10.
by Austin English Sept. 15, 2015

Sept. 15, 2015

On Mon, Sep 14, 2015 at 12:24 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Windows 10 uses a different algorithm for RtlRandom. > All the tests currently fail and produce tons of spam. > (There's already a similar case for Windows Vista.) > --- > dlls/ntdll/tests/rtl.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 9a4ec48..f42e313 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -739,6 +739,16 @@ static void test_RtlRandom(void) > return; > } > > +/* > + * Windows 10 uses different algorithms, so skip the rest of the tests > + * until that is figured out. Trace output for the failures is about 23 MB! > + */ > + > + if (seed == 0x7fffffc3) { > + skip("Most likely running on Windows 10 which uses a different algorithm\n"); > + return; > + } > + > ok(result == result_expected, > "pRtlRandom(&seed (seed == 0)) returns %x, expected %x\n", > result, result_expected); > -- > 2.5.1 This should probably be win_skip() rather than skip(). -- -Austin

3 2

Re: [2/3] Use quotes around service names in net program.
by Nikolay Sivov Sept. 15, 2015

Sept. 15, 2015

On 13.09.2015 18:51, pelzflorian(a)pelzflorian.de wrote: Please update resource file only, the rest will be regenerated with appropriate fuzziness (e.g. Russian strings are done wrong, regarding quotation marks).

2 3

Re: [PATCH 4/7] wined3d: replace wined3d_{surface, volume}_(un)map with wined3d_texture_(un)map
by Stefan Dösinger Sept. 14, 2015

Sept. 14, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:14 schrieb Riccardo Bortolato: > -HRESULT __cdecl wined3d_surface_map(struct wined3d_surface *surface, > - struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > -void __cdecl wined3d_surface_preload(struct wined3d_surface *surface); The wined3d_surface_preload removal seems premature and should be in patch 7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9yCsAAoJEN0/YqbEcdMwSh0P/1OCyBpwswYeaCD40J6YfpQb 8eXAgQlsbbqWQen6Zw+d0W3ixqJsrUJfnZM6gQu2vBp80RQxSNjuifizy3pJgXzy eHAuEWATtFrkGiyPF6EWjheGW7uM7FRyYt4DRXHCu+W3QnYkbpT0YXw7FhtGsPo2 GP/NzctDeGLwe0qrGyFtrg5WxhOA7RqdGaWIsAeMrcTiUzcS9Hbc0leTfYIJOprL bu5scnmKKobtadAOgB5um9hBSXynQzKLg8zzd5NzQMdqnRFJ3QTdZfw7YBtRpX63 0V6yVFztJgErsibvvyIUpTvGQIqq2KmAMpoDMR3p9NYzPEeyvLStnmqmHn5vZ8ZH KyP35umA552xYFQvxy/aAjttSovkrul7dv9X+W6HYW/HqwwU+XrEgCFHPpEwfM4Z 35i6onuZtrm0tSYdloCkf1hFmzn5R6izUrNvduxf64J7aSNJ3sZ2hYh56gGgSgCC uyJU9kp7SRXy7gBjEnwY95DN1V27v6+LR/VPoi2u5yaM9zAc2mOjzUBErsJSviNq phGCtnDKP6i25ajkIjEcmB9nGq7KIUV7EvgjuGz4hv4jrYtES3WsZYbPfJQs/hai pmPtOeCft7vZLkH/ZfzCx00Wggs0JwloJb5fPxDw1WYKiaq2zjXvL6yHivVqaiGN GqngsuTeKGkated3sg4H =gUhb -----END PGP SIGNATURE-----

1 0

Re: [PATCH 05/10] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet Sept. 14, 2015

Sept. 14, 2015

On 14 September 2015 at 00:13, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Is "desc" validated or modified in this case? Otherwise you could return a lot earlier. The test doesn't really cover that. > + hr = D3D11CreateDevice(adapter, driver_type, swrast, flags, feature_levels, levels, sdk_version, > + &device, NULL, NULL); > + if (FAILED(hr)) > + { > + WARN("Failed to create a device, returning %#x.\n", hr); > + *device_out = NULL; > + return hr; > + } ... > + > + if (obtained_feature_level) > + *obtained_feature_level = ID3D11Device_GetFeatureLevel(device); > + > + if (immediate_context) > + ID3D11Device_GetImmediateContext(device, immediate_context); This seems odd. Why not just pass these to D3D11CreateDevice()? If you like you can do things like the D3D11CreateDevice() call inside the if. I.e., "if (FAILED(hr = D3D11CreateDevice(...)))". I tend to do that for newer code, older code usually has it on separate lines.

2 2

WineTestBot test coverage
by Francois Gouget Sept. 14, 2015

Sept. 14, 2015

When setting up the WineTestBot VMs I have tried to make it so we can compare their results across Windows versions so we know if a specific behavior is specific to a given Windows version or was introduced in a specific Windows version. At the same time I tried to diversify the Windows configurations to get better coverage of various locales, particularly when they involve right-to-left text or asian characters, but also to test other aspects like having multiple network cards, two disks, etc. While ideally the WineTestBot would be able to switch each VM between multiple configurations (through the use of snapshots), currently this is not supported. Thus we can only test as many configurations as we have VMs (and Windows licenses). As a result choices have to be made, the coverage is not complete and there may be room for improvement. For instance w7u is configured for Japanese because it's an asian language and I know we have developers who know Japanese. But it turns out a number of test failures are specific to Korean. Ideally we'd have both but there are only two VMs(*) that can be configured for non-English locales and the other one is configured to check for right-to-left issues (previously Arabic and now through Hebrew). Similarly all VMs run the tests with elevated privileges because that's what allows running the maximum number of tests. But this means tests are never tested in unprivileged accounts leading to a bunch of failures when that happens. So should we change the configuration of some of the WineTestBot VMs? Which aspects are the most important? An additional note is that I can relatively easily reconfigure a VM and then switch between that configuration and what we have now. So for instance I could switch the Japanese VM to Korean if a developer needs it to debug things, and then switch it back to Japanese when he's done. Between the timezone delays and WineTestBot's own, the latency would be around a day. So here is a summary of the available configurations. Let me know if there are changes to do: w2000pro IE 6 sp1, DirectX 9.0c, MSXML 4&6, VC 2005/8/10, IPX, AppleTalk, data CD wxppro IE 8, DirectX extras, MSXML 4, VC 2005/8/10, winpcap w2003std IE 8, .Net 2.0 SP2, 3.0 SP2, 3.5 SP2, 4, MSXML 4, VC 2005/8/10. wvista IE 9, .Net 3.5 SP1 & 4.5.1, RMP wvistau64 IE 8, Hebrew, tests on e:, DirectX extras, MSXML 4, VC 2005/10. winpcap w2008s64 IE 9, .Net 4.0, no sound, two network cards w7u IE 11, Japanese, .Net 3.5 & 4.5, VC 2012/13, data CD w7pro64 IE 11, .Net 4.5.1 w8 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w864 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w1064 Edge, DirectX extras Legend: - DirectX extras: This installs some dlls that are not installed by default, for DirectMusic and DirectPlay for instance. - AppleTalk: The AppleTalk network protocol. - IPX: The IPX network protocol. - RMP: The Reliable Multicast Protocol network protocol. Known holes: * No Windows 8 (only Windows 8.1). * No IE 7 configuration. * No IE 10 configuration. * No non-elevated or regular user tests. * Korean locale. Other locales? * No mixed locale (to ensure the tests check the right locale API). (*) Though the locale of the new Windows 10 VM is probably configurable too. So that would be 3 VMs. But do we want to add failures to a VM that already has a lot? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0