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

Re: [3/3] ntdll/tests: Add tests for setting debug registers with NtSetContextThread.

by Sebastian Lackner

On 02.01.2016 04:51, Marvin wrote: > 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=19333 > > Your paranoid android. > > > === wvistau64 (32 bit exception) === > exception.c:485: Test failed: 42: Wrong exception address 002D0000/002D0001 > exception: unhandled exception 80000004 at 002D0000 > exception.c:485: Test failed: 42: Wrong exception address 77BAED97/002D0001 > > === w7u (32 bit exception) === > exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 > exception: unhandled exception 80000004 at 003D0000 > exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/003D0001 > > === w1064 (32 bit exception) === > Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) > > === w1064 (64 bit exception) === > Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) > Those issues look unrelated to the patch.

Jan. 2, 2016

Re: [3/3] ntdll/tests: Add tests for setting debug registers with NtSetContextThread.

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=19333 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 002D0000/002D0001 exception: unhandled exception 80000004 at 002D0000 exception.c:485: Test failed: 42: Wrong exception address 77BAED97/002D0001 === w7u (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/003D0001 === w1064 (32 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === w1064 (64 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

Jan. 2, 2016

Re: [PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter. (try 2)

by Sebastian Lackner

On 01.01.2016 23:50, Christopher Thielen wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=13683 > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. > > Tested on Windows XP and Fedora Workstation 22. > > Re-submitting to simplify based on wine-devel feedback. > Re-submitting after 1.8 release. > > Signed-off-by: Christopher Thielen <cthielen(a)gmail.com> > Where are the tests you initially had in your patch? I assume you accidentially resent an old version. The tests are still useful to make sure, that noone will break this fix again. Also, please review all the occurances of WM_CAPTURECHANGED, and fix them accordingly. If the code doesn't look like it can handle the double notification, then just ignore them based on the condition lParam == hWnd. This could also be done in separate patches before. Regards, Sebastian

Jan. 2, 2016

Re: [PATCH 3/3] ddraw/tests: Use a slop for test_shademode.

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=19330 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2337: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2186: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2522: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

Jan. 1, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-01 um 18:15 schrieb Aaryaman Vasishta: > + expected = (info_header.biWidth + 3) & ~3; > + ok(expected == img->bytes_per_line, "Expected bytes per line == %d, got %d.\n", expected, img->bytes_per_line); > + if (depth == 8) > + { > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (img->bytes_per_line * (h - i - 1)) : (img->bytes_per_line * i); > + for (j = 0; j < img->bytes_per_line; j++) > + { > + if (buffer1[k++] != buffer2[offset++]) > + return FALSE; > + } You want j < img->width here, otherwise you compare the padded bytes against the next line of the input image. (You'll then also compare the follow-up lines incorrectly and read past the input buffer). It works here because you pass an image with a width that's a multiple of 4 when this codepath is used. So iterate over width pixels, but advance the read offset / pointer by bytes_per_line bytes after processing one line. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWhs9jAAoJEN0/YqbEcdMwx6kP/RXJJdivWRU1ouvEP32VWNRA O/tOZxGNJnXw0Rz40QQz1rtckN3GGAe54pwilQbaPAqrZeIDAEWfk4gWMKIvHvUw Vdg3w7dfQv6fpKK16EWWb83gdaQU9X3Nc7bFzHx4XwvkjHgV/ztsk/t6cqkAOv2Y cWul6MpQcWvehGyEv+vk1siMxO5zFjLvBpT7jgFh+7Ehzbk8ziZWdBYGjV18PnAQ 4eT5MrsNbaA99wKj7ibhz9I4GsKLf8oQQAFFqcVTutCOLeQh7zvHkQ4Z4glXSEYu VvNRmLdMYNSYho+Z9lZEABNvaw9lkxJ6/r1OYd3tP2A0TZzKur732iUYwTo1RnFB Hlv6K/PKzTTMN1m9GZ8UiltnjsEq5G+05nkaywsh7pkr9bGU2pfSEihZ8BSX1/4a zG+vLJipg/rdHalQKfCflxWpKcHiIFjm5E/+Bdtgzb3sSksPh2bfmdVDW/bl3lvD OMXD2FgHB4BE+lexisBV7+qlQhlv8vEPgWryoJ8xomfyAc0ZHioOgTrq0XSMrTdC 19oNGDWZd/8P1guTTC3eRlBFA3jYt/yvjzINRYG1h9L5DbYISuMbp0oUSFx3412o YB7HTHjbyxcWhZFEXc9oDHoMzfIEyJI1QOa8fCNkisucCc/idN7Zrqz+3wYJhHCu PjleVblBVMqsSN/Qw2OE =ftwX -----END PGP SIGNATURE-----

Jan. 1, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 5).

by Aaryaman Vasishta

On Fri, Jan 1, 2016 at 6:39 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2015-12-27 um 10:23 schrieb Aaryaman Vasishta: > > + if (info_header.biWidth % 4 != 0) > > + expected = (info_header.biWidth & ~0x03) + 4; > > + else > > + expected = info_header.biWidth; > This is more complicated than it needs to be: > > expected = (info_header.biWidth + 3) & ~3 > > should work as well. > Much better solution :) I've sent try 6 with the changes. Cheers, Aaryaman

Jan. 1, 2016

Re: [PATCH] ieframe: Don't write icon file path and index to storage if not specified in shortcut (Valgrind)

by Nikolay Sivov

On 01.01.2016 19:24, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> - U(pv[1]).iVal = iconIndex; >> + U(pv[1]).lVal = iconIndex; > > This change is wrong and doesn't match the code below it in the patch. > The change is correct, line below has to be fixed too, thanks.

Jan. 1, 2016

Re: Mac OS X beta packages!

by Michael Müller

Am 01.01.2016 um 09:08 schrieb Aaryaman Vasishta: > Not always, atleast in my case. I had a third party app installed which > had already associated itself with *.exe files, and after installing the > package it didn't change the default app to open by double clicking to > wine. Instead I had to use the "Open with" option by right clicking on > the .exe. If I remember correctly OS X saves the first App, which installs an "Open With" handler for a file extension / mime type, as the default handler. If you have multiple applications installed, you have to set Wine as the default application, but there is nothing I could change in the installer. > Does that depend on the location of the executable or the executable > itself? If it's the latter, can you give any example apps which have > such executables? Basically all non portable applications on Windows, which ship additional files, rely on the current working directory being set correctly. However, many applications need to be installed into the wineprefix first and their installer is often self contained, so it should work for the usual case that you downloaded some installer file. As an Improvement I could also set the working directory to the directory containing the file, which should be correct in 95% of the cases, even if you double click on a file inside of a wineprefix. Regards, Michael

Jan. 1, 2016

Re: [PATCH] ieframe: Don't write icon file path and index to storage if not specified in shortcut (Valgrind)

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - U(pv[1]).iVal = iconIndex; > + U(pv[1]).lVal = iconIndex; This change is wrong and doesn't match the code below it in the patch. -- Dmitry.

Jan. 1, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 5).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-12-27 um 10:23 schrieb Aaryaman Vasishta: > + if (info_header.biWidth % 4 != 0) > + expected = (info_header.biWidth & ~0x03) + 4; > + else > + expected = info_header.biWidth; This is more complicated than it needs to be: expected = (info_header.biWidth + 3) & ~3 should work as well. > + k++; > + /* Take into account padded bytes after every row for odd widths */ > + if ((w % 2 == 1) && (j == w - 1)) > + k = (k & ~0x03) + 4; Wouldn't this also apply for e.g. a width of 10 that is a multiple of 2, but not a multiple of 4? The canonical way is to advance bytes_per_line bytes every line, e.g. buffer1[i * bytes_per_line + j] Or do k += bytes_per_line in the outer loop and then just do buffer1[k + j] to avoid re-doing the multiplication every time. I'd expect the compiler to optimize it anyway though. Other than that the patch looks good :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWhnqDAAoJEN0/YqbEcdMwiLYP/1eERxdjpnqfm2CX3dPF4wmx 3BQjdvH8LLxlS9HNG9PcGXs6gnyhPtsXL3DTSJtsl6UnHn7Ws9EWrjNFrnLEkoDB K7JwHNCPBvuOGb4YHDo4+9NeIXn3Kg6r3yorPGEu0NvWO98FcbhTJWbfhPq4y0uD WvQSCUcqufusFRUFUlOAks5zUXEmEVimxtMgaAYMqul3rsD22pT9CIOPd7Pxp+tc 6AzROoxTA0OoyMpH33APRKCLSwXET6KsMsrV7V83DblE5T9GrIz1ufRYQ155yUpe 3sBG9cGtPJ9KgjEdwp2Gy4hSFOSNVZJauNG3NhYf55cpngnYGU2W7Om9hkGQ6lOF IkjlBDWdKTX6WpC3Yiitw8DfNtRy7S1syEfhkqscYEiDRKYKILHB/njrbdj8q3so SRGAO/g8WSltCfUzlPHU3Jjmb/QjHl6JUV7JkqmJkrmqtd5mrOqPO+YFlDVCwtKl 79DWf5gbF7MbDBQQ82pBy30dy7+a4W9/cmls8x6EeZVr9zBvojfnxbR9xgy7tAVp EWaSUvUJWIoTTxMh4KEbVrH2LxJcEKGocHdXL22h5pMvpk02oCoj8nx1hUtHqMTW mvfYJDGV/DKiaYoSxUjuLqiB1wtNzg4BQcDNCzojRWQD4xS/yHC22rV9/4jG/+b4 F11LmyZfBxp83t+SpGjk =BnPO -----END PGP SIGNATURE-----

Jan. 1, 2016