August 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] ddraw: Fix its vs it's typos

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://testbot.winehq.org/JobDetails.pl?Key=24668 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

Aug. 1, 2016

Re: [PATCH 2/2] winex11: track glx windows per thread

by Miklós Máté

On 07/22/2016 03:11 AM, Alexandre Julliard wrote: > Miklós Máté<mtmkls(a)gmail.com> writes: > >> Hmm, you are right. Mesa does set an XCloseDisplay callback to clean >> things up for the display connections it encounters. If I use >> data->display instead of gdi_display for pglXCreateWindow in line 1358 >> of opengl.c, the tests pass, and no zombie glx windows remain. I don't >> know if I should dare to take responsibility for this change, though, >> as I know almost nothing about GDI. > If it works then it's the right thing to do. I did some further testing, and it doesn't work. Mesa glx maintains its state per-display, and creating a drawable with one display connection but makecurrent with an other one can lead to bad things. Unfortunately, wine-csmt likes to do those from separate threads, so the thread-specific display connections cannot be used instead of the global gdi_display. MM

Aug. 1, 2016

Re: [PATCH 2/2] kernel32/tests/thread: Add tests for fiber-local storage.

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://testbot.winehq.org/JobDetails.pl?Key=24663 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

Aug. 1, 2016

Re: [PATCH 1/2] kernel32/tests/loader: Add tests for fiber-local storage.

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://testbot.winehq.org/JobDetails.pl?Key=24662 Your paranoid android. === w1064 (32 bit loader) === loader.c:2979: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2979: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2979: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2987: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 3: Wrong callback count: 0 loader.c:2987: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784

Aug. 1, 2016

Re: Wine's forked version of fontforge

by Jens Reyer

On 30.04.2016 04:13, Jens Reyer wrote: > On 04/22/2016 12:54 PM, Alexandre Julliard wrote: >> Jens Reyer <jre.winesim(a)gmail.com> writes: >> >>> Wine and Debian are both using the quite old fontforge version >>> 20120731-b, the patches apply cleanly in Debian. >>> But upstream is actively developing and in Debian someone is working on >>> packaging a recent version (not sure with what outcome, e.g. afaik there >>> is at least one upstream regression blocking an update). >>> Are there any plans in Wine to update to a newer version? >> >> No plans currently, but I can certainly look into it if it helps. > > Thanks. First off, I successfully tested the current fontforge > 20160404. I built Wine and the .ttf files with it, and verified in one > app that relies on them that they are working. So no immediate need to > update, but it might be a good idea generally. > > After looking into your patches and explanation my understanding is > that we may regenerate the .ttf files in Debian without having to > worry about the results. However for contributing to Wine the current > Debian fontforge is not suitable. So I started trying to get your > changes applied upstream: > >>> 1. Various hacks to avoid putting timestamps in generated files (AJ). > > Created issue https://github.com/fontforge/fontforge/issues/2711 > The timestamps are also a hindrance for reproducible builds, and need > to be tackled somehow in fontforge anyway. fyi, fontforge upstream is currently discussing this issue.

Aug. 1, 2016

Re: [2/3] wininet: Start the first chunk as soon as we have some data.

by Jacek Caban

Hi Hans, On 21.07.2016 16:32, Hans Leidekker wrote: > On Thu, 2016-07-21 at 14:25 +0200, Jacek Caban wrote: >>> --- >>> dlls/wininet/http.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c >>> index 2c62d97..c4cf66b 100644 >>> --- a/dlls/wininet/http.c >>> +++ b/dlls/wininet/http.c >>> @@ -2921,6 +2921,7 @@ static DWORD set_content_length(http_request_t *request) >>> !strcmpiW(encoding, szChunked)) >>> { >>> chunked_stream_t *chunked_stream; >>> + DWORD res; >>> >>> chunked_stream = heap_alloc(sizeof(*chunked_stream)); >>> if(!chunked_stream) >>> @@ -2935,6 +2936,12 @@ static DWORD set_content_length(http_request_t *request) >>> memcpy(chunked_stream->buf, request->read_buf+request->read_pos, request->read_size); >>> chunked_stream->buf_size = request->read_size; >>> request->read_size = request->read_pos = 0; >>> + >>> + res = start_next_chunk(chunked_stream, request); >>> + if (res != ERROR_SUCCESS) { >>> + heap_free(chunked_stream); >>> + return res; >>> + } >> It seems to me that you're fixing a problem is a wrong place. >> start_next_chunk should be called by HTTP_ReceiveRequestData via >> refill_read_buffer anyway. I'd suggest to investigate why it doesn't >> work in your case. > This is required to make get_avail_data return the correct number of > bytes. Note that the line above sets the read size to 0, so (before my > second patch) the next call to get_avail_data would return 0. This may > trigger a read beyond available data. It is what happens with Outlook. Again, refill_read_buffer usually takes care of that. I think it probably didn't work in your case due to quirks we needed for non-blocking reads. I sent a patch that should improve chunked stream behaviour a lot [1]. There is still more work that could be done (like improvement of chunked_get_avail_data or taking advantage of now properly working non-blocking reads to improve InternetRead* functions), but I expect it to fix the problem that you were trying to solve with this patch. It's likely that your patch 3/3 may also not be needed (and if it is, it will need adjustment for the new way of storing chunk size). >> Also, see the attached test. We shouldn't need any chunk to complete >> requests. It's an existing problem in current Wine, which may be >> unrelated to your problem, but having such blocking calls here is not a >> step in the right direction. > Your test hangs with and without this patch. Why is having a blocking > call here a problem? Although it hangs on current Wine, it doesn't on Windows, and it shows that blocking reads should not be used here. Thanks, Jacek [1] http://source.winehq.org/patches/data/125006

Aug. 1, 2016

Re: [4/6] msvcirt: Implement istream::operator>> for integers.

by Piotr Caban

Hi, On 08/01/16 12:40, Iván Matellanes wrote: > Signed-off-by: Iván Matellanes <matellanes.ivan(a)gmail.com> > --- > dlls/msvcirt/msvcirt.c | 90 ++++++++++++++++++++++++++---- > dlls/msvcirt/tests/msvcirt.c | 128 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 205 insertions(+), 13 deletions(-) It causes following compilation warnings: ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:4891:5: warning: this decimal constant is unsigned only in ISO C90 int n, int_out[] = {123456789, 0, 1, -500, 0x8000, 2147483646, 2147483647, -2147483647, -2147483648, -1}; ^ ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:4893:5: warning: this decimal constant is unsigned only in ISO C90 LONG l, long_out[] = {2147483647l, -2147483648l};

Aug. 1, 2016

Re: wine-1.8.4-rc1

by Hugh McMaster

On Sunday, 31 July 2016 11:19 PM, André Hentschel wrote: >Am 30.07.2016 um 22:49 schrieb Michael Stefaniuc: >> Hello guys, >> >> I have pushed wine-1.8.4-rc1 (with tag) to >> https://github.com/mstefani/wine-stable > >It builds fine in buildroot, but then thinks it's a 1.8.3 build (./wine --version told me so), despite "Wine version >1.8.4" in the VERSION file It's just a mistake in the configure file. # Identity of this package. PACKAGE_NAME='Wine' PACKAGE_TARNAME='wine' PACKAGE_VERSION='1.8.3' PACKAGE_STRING='Wine 1.8.3'

Aug. 1, 2016

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL (try 2)

by Alexandre Julliard

Daniel Lehman <dlehman(a)esri.com> writes: > +@ extern ??_7?$num_put(a)_WV?$ostreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@6B@ MSVCP_num_put_wchar_vtable > +@ extern ??_7?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@6B@ MSVCP_time_get_char_vtable > +@ stub ??_7?$time_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@6B@ > +@ stub ??_7?$time_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@6B@ These should be extern, not stub. There are several more similar cases. Please check other msvcp versions to see where we are using commented out extern declarations. -- Alexandre Julliard julliard(a)winehq.org

Aug. 1, 2016