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

Re: shell32/tests: Add test for GetLastError in shlfileop

by Zhenbo Li

2014-01-28 Dmitry Timoshkov <dmitry(a)baikal.ru> > > > > There are many 'todo_wine' marks in shell32 test, and it really caused > > bugs(like 34324). > > According to the comments and the attached hack in the bug 34324 the problem > there is not related to the last error set but to the returned error value, > so you probably should add the tests for that particular behaviour. > > > > Maybe such test cases can contribute to further development? > > Adding the tests is good in general, but the tests should be added very > carefully, and check something that real applications could depend upon. > Adding blanket tests just for everything is a waste of time IMHO. Thanks for checking that. As MSDN[1] said, "Do not use GetLastError with the return values of this (SHFileOperation) function." I think wine's implement of SHFileOperation needs a big change. Before hacking it, I hope there could be sufficient testcases to help me understand that function. I had to admit that I'm lack of experience, and I don't know how to judge if a testcase is necessary. Thank you very much. [1]: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762164%28v=vs.85%… -- Have a nice day! Zhenbo Li

Jan. 28, 2014

Re: winhttp/test: Fix a test that fails on Windows.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4504 Your paranoid android. === wxppro (32 bit winhttp) === winhttp.c:324: Test failed: WinHttpSendRequest failed: 12029 winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:340: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:341: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:346: Test failed: WinHttpReceiveResponse failed: 12017. winhttp.c:350: Test failed: WinHttpReadData failed: 12019. winhttp.c:352: Test failed: Read 0 bytes instead of 14. winhttp.c:353: Test failed: Data read did not match. winhttp.c:936: Test failed: failed to send request 12029 winhttp.c:939: Test failed: failed to receive response 12017 winhttp.c:943: Test failed: failed unexpectedly 12019 winhttp.c:944: Test failed: request failed unexpectedly 4287119 === wvista (32 bit winhttp) === winhttp.c:936: Test failed: failed to send request 12029 winhttp.c:939: Test failed: failed to receive response 12017 winhttp.c:943: Test failed: failed unexpectedly 12019 winhttp.c:944: Test failed: request failed unexpectedly 4287119 winhttp.c:952: Test failed: failed to send request 12029 winhttp.c:955: Test failed: failed to receive response 12017 winhttp.c:962: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 12019 winhttp.c:966: Test failed: failed unexpectedly 12019 winhttp.c:967: Test failed: unexpected size 0 winhttp.c:972: Test failed: failed unexpectedly 12019 winhttp.c:973: Test failed: request failed unexpectedly 4287119 winhttp.c:1765: Test failed: failed to send request winhttp.c:2420: Test failed: got 80072efd === w7pro64 (32 bit winhttp) === winhttp.c:859: Test failed: failed to send request 12175 winhttp.c:939: Test failed: failed to receive response 12002 winhttp.c:943: Test failed: failed unexpectedly 12019 winhttp.c:944: Test failed: request failed unexpectedly 4287119 === w2008s64 (64 bit winhttp) === winhttp.c:936: Test failed: failed to send request 12029 winhttp.c:939: Test failed: failed to receive response 12017 winhttp.c:943: Test failed: failed unexpectedly 12019 winhttp.c:944: Test failed: request failed unexpectedly 0 winhttp.c:955: Test failed: failed to receive response 12029 winhttp.c:973: Test failed: request failed unexpectedly 0 === w7pro64 (64 bit winhttp) === winhttp.c:939: Test failed: failed to receive response 12002 winhttp.c:943: Test failed: failed unexpectedly 12019 winhttp.c:944: Test failed: request failed unexpectedly 0 winhttp.c:952: Test failed: failed to send request 12002 winhttp.c:955: Test failed: failed to receive response 12019 winhttp.c:962: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 12019 winhttp.c:966: Test failed: failed unexpectedly 12019 winhttp.c:967: Test failed: unexpected size 0 winhttp.c:972: Test failed: failed unexpectedly 12019 winhttp.c:973: Test failed: request failed unexpectedly 0

Jan. 28, 2014

Re: shell32: Use boolean return value in boolean function

by Michael Stefaniuc

On 01/28/2014 12:07 AM, André Hentschel wrote: > --- > dlls/shell32/shellstring.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/shell32/shellstring.c b/dlls/shell32/shellstring.c > index 6b511d2..9eb8536 100644 > --- a/dlls/shell32/shellstring.c > +++ b/dlls/shell32/shellstring.c > @@ -183,7 +183,7 @@ static BOOL StrToOleStrNW (LPWSTR lpWide, INT nWide, LPCWSTR lpStrW, INT nStr) > if (lstrcpynW (lpWide, lpStrW, nWide)) > { return lstrlenW (lpWide); > } > - return 0; > + return FALSE; This looks ugly. StrToOleStrNW() as well as StrToOleStrNA() return string length and not BOOL. What StrToOleStrN() (the sole user of about two functions) should return is not documented nor is there a Wine test for it. > } > > BOOL WINAPI StrToOleStrNAW (LPWSTR lpWide, INT nWide, LPCVOID lpStr, INT nStr) bye michael

Jan. 28, 2014

Re: [PATCH] widl: Uuid attribute is allowed for 'struct'

by Nikolay Sivov

On 1/28/2014 10:08, Marvin wrote: > ../../../../wine/dlls/oleaut32/tests/test_tlb.idl:47: error: inapplicable attribute uuid for struct > make: *** [test_tlb.tlb] Error 1 > make: *** Waiting for unfinished jobs.... > make: Leaving directory `/home/winetest/tools/testbot/var/build-mingw32/dlls/oleaut32/tests' The problem is that widl is not rebuilt by bot.

Jan. 28, 2014

Re: [PATCH] widl: Uuid attribute is allowed for 'struct'

by Marvin

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

Jan. 28, 2014

Re: shell32/tests: Add test for GetLastError in shlfileop

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > There are many 'todo_wine' marks in shell32 test, and it really caused > bugs(like 34324). According to the comments and the attached hack in the bug 34324 the problem there is not related to the last error set but to the returned error value, so you probably should add the tests for that particular behaviour. > Maybe such test cases can contribute to further development? Adding the tests is good in general, but the tests should be added very carefully, and check something that real applications could depend upon. Adding blanket tests just for everything is a waste of time IMHO. -- Dmitry.

Jan. 28, 2014

Re: shell32/tests: Add test for GetLastError in shlfileop

by Zhenbo Li

2014-01-28 Dmitry Timoshkov <dmitry(a)baikal.ru> > Zhenbo Li <litimetal(a)gmail.com> wrote: > > > ret = SHFileOperationA(&shfo); > > todo_wine > > ok(ret == 1026 || > > ret == ERROR_FILE_NOT_FOUND || /* Vista */ > > broken(ret == ERROR_SUCCESS), /* NT4 */ > > "Expected 1026 or ERROR_FILE_NOT_FOUND, got %d\n", ret); > > + todo_wine > > + ok(GetLastError() == 0 || > > + broken(GetLastError()==ERROR_FILE_NOT_FOUND), /* win 2000 */ > > + "gle = %d\n", GetLastError() ); > > Thank you for reviewing my patch. > 'ret == ERROR_SUCCESS (0)' case is marked as broken above, so using broken > for 'GetLastError() == 0' instead of ERROR_FILE_NOT_FOUND would match that > behaviour. Same comment applies for other added tests. > > I don't think so. I think we can divide windows versions to 2 group: a) 2000 or before b) xp or later For group a, they behave as > broken(ret == ERROR_SUCCESS) implied, but their GetLastError() were remained as ERROR_FILE_NOT_FOUND For group b, their 'ret' value isn't 0, but GetLastError() is set to 0. > In general I don't think that adding last error tests for SHFileOperation > is very useful because 1) this API returns error codes directly 2) > according > to the tests both returned error codes and set last error values differ in > almost every Windows version, so it's very unlikely that there is an app > that depends on this. > You're right. As wine's documents[1] said, > However, undocumented behavior should not be tested for unless there is an application that relies on this behavior, and in that case the test should mention that application, or unless one can strongly expect applications to rely on this behavior There are many 'todo_wine' marks in shell32 test, and it really caused bugs(like 34324). Maybe such test cases can contribute to further development? [1]: http://www.winehq.org/docs/winedev-guide/testing-what -- Have a nice day! Zhenbo Li

Jan. 28, 2014

Re: shell32/tests: Add test for GetLastError in shlfileop

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > ret = SHFileOperationA(&shfo); > todo_wine > ok(ret == 1026 || > ret == ERROR_FILE_NOT_FOUND || /* Vista */ > broken(ret == ERROR_SUCCESS), /* NT4 */ > "Expected 1026 or ERROR_FILE_NOT_FOUND, got %d\n", ret); > + todo_wine > + ok(GetLastError() == 0 || > + broken(GetLastError()==ERROR_FILE_NOT_FOUND), /* win 2000 */ > + "gle = %d\n", GetLastError() ); 'ret == ERROR_SUCCESS (0)' case is marked as broken above, so using broken for 'GetLastError() == 0' instead of ERROR_FILE_NOT_FOUND would match that behaviour. Same comment applies for other added tests. In general I don't think that adding last error tests for SHFileOperation is very useful because 1) this API returns error codes directly 2) according to the tests both returned error codes and set last error values differ in almost every Windows version, so it's very unlikely that there is an app that depends on this. -- Dmitry.

Jan. 28, 2014

Re: user32/tests: Avoid preprocessor check to ensure it compiles (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4477 Your paranoid android. === wxppro (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000800C4 fg 00030052 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === wvista (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000602B4 fg 00020222 in hook HCBT_ACTIVATE === w2008s64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000600F0 fg 0001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w7pro64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00060106 fg 00010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w2008s64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00000000000600F0 fg 000000000001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000 === w7pro64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0000000000060106 fg 0000000000010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000

Jan. 27, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Ruslan Kabatsayev

On Mon, Jan 27, 2014 at 11:48 PM, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > On Mon, Jan 27, 2014 at 5:53 PM, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-01-26 14:08, schrieb Ruslan Kabatsayev: >>> For end user this looks like failing software, and moreover, it's >>> not easy to understand which software does have bug. Wine >>> perspective: On the one hand, wine seems to use what Mesa exposes. >>> On the other, why use shaders for games which don't need them? >> There are some corner cases in the d3d fixed function pipeline which >> we can't handle properly without shaders. Unfortunately, once we >> detect such a corner case it's too late to turn on shaders. >> >> A possible workaround for the user is to set UseGLSL=disabled. It's >> not a good long-term fix though. >> >>> Mesa perspective: On the one hand, it wants to advertise more >>> support for latest OpenGL standards. On the other, why do it for >>> very old HW which doesn't support it? >> Does the "slow" mean that Wine hits a software rendering fallback and >> Mesa emulates vertex shaders with the CPU? I hated it when OSX >> advertised features the card didn't have, and I think it's a very bad >> idea for Mesa to do the same thing. > > Yes, a SW fallback. Vertex shaders are always on CPU on i915 by > design. It's fragment shaders which suffer from SW fallback when > something is used which is unsupported by the chip. > >> >> The GL errors should be fixed though. Can you try to find the commits >> in Wine and Mesa that started those errors? > Yeah, I've already bisected Mesa. Its commits (which appear next to > each other in history) are: > > 1) The one making wine 1.5.17 slow: > 97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit > commit 97217a40f97cdeae0304798b607f704deb0c3558 > Author: Eric Anholt <eric(a)anholt.net> > Date: Wed Apr 17 13:55:08 2013 -0700 > > i915: Always enable GL 2.0 support. > > There's no point in shipping a non-GL2 driver today. > > :040000 040000 d039f68bbc5a5e610adbeb3d310350a844911fea > efac289465401566fec6063b544c0a844e302559 M src > > 2) The one leading to GL_INVALID_FRAMEBUFFER_OPERATION: > 4df1b986d3e44dc035227054000a1d0e1846ef07 is the first bad commit > commit 4df1b986d3e44dc035227054000a1d0e1846ef07 > Author: Eric Anholt <eric(a)anholt.net> > Date: Wed Apr 17 19:10:29 2013 -0700 > > i915: Add support for GL_EXT_texture_sRGB and GL_EXT_texture_sRGB_decode. > > This brings the driver up to GL 2.1. > > :040000 040000 efac289465401566fec6063b544c0a844e302559 > 5bd49114ce64a359f4a0e3673ec27ca01590adbc M src > > > I'm bisecting wine now to find which commit starts > GL_INVALID_FRAMEBUFFER_OPERATION error. Bisection gives this (with Mesa $(git describe)=snb-magic-15798-g4df1b98): 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Jul 18 21:32:34 2012 +0200 wined3d: Enable "AlwaysOffscreen" by default. :040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJS5mTVAAoJEN0/YqbEcdMwViwP/3iPmbKEtH/5BBcNLg/IqxGJ >> sie+Qn2Yibp+LBf2iYPqshjDKAHBNXiaiMKqTKG8GWzGC235K/Nqc0QoV2sFRRJW >> EiroXisQlG6AupmWKqzqldSVYC93tehCQdp982Rk3XYENQmmsuE+OSwMwXAg32ji >> 8gKSrZ7EYwT2b4NYy79o7p/KiR5+nO/Mwm7m8wNYLoYPPjQ3yk95pxPxlNlsuAZw >> eEeDRNU7lXtIGrYsO+xpA4saCW93vZp2rUqXLlQjAMdOi2HU3F5R7jmsLn/pqvJV >> rIawm53PMP7bauUcB926StXYwW8yLeEHAbGtER4t2nJKf9tHNrNNKD0Q8CwrpE1F >> fKwMJDHx5YVkeftADm2OiX4PNKflvwfeKTeib9ChCP7ApXbulbRi3Qx/n7Al+ZWv >> 6THEBaSS9PlxvPQQ1zwSduATfAMKsMulxDz6I0SPclVTnFTmMcfLxcNtFIHsjkCR >> US7Q6hKGHfqLO/OQEdpiJ/4KlQmXrkQkWj0VOwnsBmWjBFv02Q/8Xoj4i50f7Qev >> 7KadSvgpgAg5Yu468jBbiVwxibxaxNQZNuJgFUnDfMyMdwBYXD613Ngnm1GriOUO >> F+MWvaCKpMK4zsAYIZg366GTjH7XqANVZ1vaCruoAdmB6r39A3/mMiS5kmPoPLP5 >> /6tpS/N9eJfBOVyzv9Au >> =q+e8 >> -----END PGP SIGNATURE-----

Jan. 27, 2014