wine-devel October 2014

wine-devel@winehq.org

52 participants
183 discussions

Re: [PATCH 1/2] kernel32/tests: Add test for FormatMessage with HRESULT
by Sebastian Lackner 20 Oct '14

20 Oct '14

On 20.10.2014 19:05, Catalin Patulea wrote: > > + /* Test HRESULT. It's not documented but in practice _com_error::ErrorMessage relies on this. */ > + ret = FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_FROM_HMODULE, h, 0x80070005 /* E_ACCESSDENIED */, > + MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL), out, sizeof(out)/sizeof(CHAR), NULL); > + ok(ret != 0, "FormatMessageA returned 0\n"); > + As this test is failing on Wine you should mark it with "todo_wine", to avoid introducing test failures. Patch 2 which fixes the issue should remove the "todo_wine" again.

1 0

Re: secur32/test: Switch requested protocol from SSL3 to TLS1.
by Marvin 20 Oct '14

20 Oct '14

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=9643 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] vbscript: Implemented String
by Piotr Caban 20 Oct '14

20 Oct '14

On 10/19/14 17:44, Shuai Meng wrote: > + newstr = SysAllocStringLen(NULL, 1023); You need to allocate correct length string. First argument should be used here. You're also leaking the string in error-handling paths. > + > + switch(V_VT(arg + 1)) { > + case VT_NULL: > + return MAKE_VBSERROR(VBSE_ILLEGAL_NULL_USE); > + case VT_BSTR: > + str = V_BSTR(arg + 1); > + break; > + case VT_ARRAY|VT_BYREF|VT_VARIANT: > + return DISP_E_TYPEMISMATCH; > + default: > + hres = to_short(arg + 1, &tmp); > + if(FAILED(hres)) > + return hres; > + str[0] = (char)tmp; Please add a test with second argument larger then 256. It would be also interesting to see a test with second argument being BSTR with first character out of ASCII range. Please also check what happens if V_BSTR(arg+1)==NULL. > + hres = to_short(arg, &len); > + if(FAILED(hres)) > + return hres; > + if(len < 0) > + return MAKE_VBSERROR(VBSE_ILLEGAL_FUNC_CALL); > + else if(len == 0) > + newstr = '\0'; > + else if(len > 1023) > + len = 1023; I guess that first argument is probably an integer. The length of produced string is probably also not limited to 1023 characters. Thanks, Piotr

2 1

Re: [v5 03/12] reg.exe: Add REG_MULTI_SZ tests for reg add
by Stefan Dösinger 20 Oct '14

20 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-17 20:38, schrieb Jonathan Vollebregt: > + /* REG_MULTI_SZ */ > + run_reg_exe("reg add HKCU\\" KEY_BASE " /v multi0 /t REG_MULTI_SZ /d \"three\\0little\\0strings\" /f", &r); > + ok(r == REG_EXIT_SUCCESS, "got exit code %d, expected 0\n", r); > + memcpy(buffer, "three", 6); > + memcpy(buffer+6, "little", 7); > + memcpy(buffer+6+7, "strings", 8); > + buffer[21] = 0; > + verify_reg(hkey, "multi0", REG_MULTI_SZ, buffer, 22, TODO_REG_SIZE); I think this shoudl work as well: const char buffer[] = "three\0little\0strings\0"; verify_reg(hkey, "multi0", REG_MULTI_SZ, buffer, sizeof(buffer), TODO_REG_SIZE); Notice the [] to declare an array so sizeof returns the proper value. strlen will not work. > + run_reg_exe("reg add HKCU\\" KEY_BASE " /t REG_MULTI_SZ /v multi4 /s \"#randomgibberish\" /d \"three#little#strings\" /f", &r); > + todo_wine ok(r == REG_EXIT_FAILURE, "got exit code %d, expected 1\n", r); > + run_reg_exe("reg add HKCU\\" KEY_BASE " /t REG_MULTI_SZ /v multi4 /s \"\" /d \"three#little#strings\" /f", &r); > + todo_wine ok(r == REG_EXIT_FAILURE, "got exit code %d, expected 1\n", r); > + run_reg_exe("reg add HKCU\\" KEY_BASE " /t REG_MULTI_SZ /v multi4 /s \"#\" /d \"##\" /f", &r); > + todo_wine ok(r == REG_EXIT_FAILURE, "got exit code %d, expected 1\n", r); > + run_reg_exe("reg add HKCU\\" KEY_BASE " /t REG_MULTI_SZ /v multi4 /s \"#\" /d \"two##strings\" /f", &r); > + todo_wine ok(r == REG_EXIT_FAILURE, "got exit code %d, expected 1\n", r); > + run_reg_exe("reg add HKCU\\" KEY_BASE " /t REG_MULTI_SZ /v multi4 /s \"#\" /d \"#a\" /f", &r); > + todo_wine ok(r == REG_EXIT_FAILURE, "got exit code %d, expected 1\n", r); What about the following cases? /s ABC /d threeABClittleABCstrings /s \\0 /d three\\0little\\0strings -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJURR9NAAoJEN0/YqbEcdMw/6UP/Rs7diy+TUkZDbJq2x3JyZYZ c+YK2Z9PoWNs3oTvwvVtaxrVqSX1y0fVnGEpNixGEMbo5fae7/rm9fN5WqvI+1FW RWG0ViCpJ4EduNVhORtHmMGzhqQAAGlfuEF0fthSshynaD8MirwPMW5LzBVTK/A8 zhI0wvveQElhscEoYtaZOkuI5WZzzKnjGpuGtserx31B41ClASEpR/MiU4XJD78p OvqaPotzlbQermrte9B+ZWcxjjVyrsM2fToVbXMNhtBDyDy17uG1Lpr8lQrXL85J uFYpVFiYoRf7CCHrhY2Gx8H7AsHwc8W0LDlnvlIKk6yRWnzyQuSzQJVbFNzBAy9u wBlQ6kZjMJzvaGCk9el5MXiwgN6Vs2bHa3j/8qvrzQyaGNebiZA7QLaXUXOqXpb6 De6/ev8iyTD1cyFwVootQBAsb40HKBk24ZwmP0sp+j3seJUlzR37ve/R71avexWL uheZ9Xj5xeBm0G3JJQ3C0cxUYo+f22t9gDLbKtOa+5BcRskjtmgHjEHEzZs33T8F BcXhGtAyL99XwXh73ILHg321pjkTu1sWzd9ILigVz6mYmOJzZp/L4Azy6E3W/U7j GHkT46Ag7/aUN4BTR5MieySdFtAQ9pbdYI1FRMBINie2Ny9AC71UrDYtFpNQuzaN C4BbMES4ZXNJQuGSHs33 =iJxu -----END PGP SIGNATURE-----

2 2

Re: [v5 01/12] reg.exe: Fix wrong error message in reg add DWORD test
by Stefan Dösinger 20 Oct '14

20 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-17 20:38, schrieb Jonathan Vollebregt: > run_reg_exe("reg add HKCU\\" KEY_BASE " /v dword1 /t REG_DWORD /f", &r); > todo_wine ok(r == REG_EXIT_FAILURE || broken(r == REG_EXIT_SUCCESS /* WinXP */), > - "got exit code %d, expected 0\n", r); > + "got exit code %d, expected 1\n", r); r is a DWORD, which is an unsigned value, so %u is the correct format to print it. There's not much point in printing the expected value. One can look it up by looking at the source file. Having the expected value twice only asks for inconsistencies like the one you're fixing here. If you want to print the expected value I'd prefer something like this: todo_wine ok(r == REG_EXIT_FAILURE || broken(r == REG_EXIT_SUCCESS /* WinXP */), "got exit code %u, expected %u\n", r, REG_EXIT_SUCCESS); or maybe todo_wine ok(r == REG_EXIT_FAILURE || broken(r == REG_EXIT_SUCCESS /* WinXP */), "got exit code %d, expected REG_EXIT_SUCCESS(%d)\n", r, REG_EXIT_SUCCESS); That way you don't hardcode the numerical value of REG_EXIT_SUCCESS. I recommend sending smaller patchsets, e.g. in your case send the tests, and once they are in, send the implementation changes. The tests make sense on their own, and that way you don't flood wine-patches too much. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJURSKoAAoJEN0/YqbEcdMwgVsP/0rEoBVYlB3zoP979b5q4Wbw U0Y+ilARyJ4vAoeVKlJtQ8xLxg2Mej6vYvCx5fve6cq6pokUbfrHBpEgBNsjx7gq AI88t8CSDYnpFBGpDYRVDdwq5enLP0cJKOZHb7pVIR5+1JIbDW/RxA3eLGmbvLsE EU8nGiSEzYuRwKMy4XfuMFCG1oPRIzg2WO+8ckneJ+P2ZYDmNVWv1sxcuitAm7Lr g6pq5CwN1Y1agzPHd45W10/hPTnD9ViqaSQgHIpXs47urElL6z1nRb3bgwKAVeBf 9KA9qm12F+zqNoEc9cTHPdnjjOHM7LgQFTmWJDNdZSiXDKMvqZAldRkuI2cAp4jX tRFYSeUlNk3KDLnJ5msINwRklatovSBbUizHY/D+YhCJVU1aRIKsebJ0zOFrVoUp 2UBbtfBembEOr917aXngNlpZzKPbwPGpm+wyBum7q8OU19CN5X8/WqXZVhms3QAU bchyP9EnX6SjnHiZn4XE0gC8ABj5LeS24/Zgtfm/T19FT7NL00U49pis+F8RMim8 kthoNp2YO+rpzcvQjaWvBMQlCtecpZx2f9b9x/lfAxd+fMVDGjsVxFcp5V7OipJG 1pdISvYtwOqrlgqiy1Bm4q9vX47y+qDmM1NnAvfBcDkkE/hk+QaCQo+MjAW1W/Bm 7DS30tdCw2E6+XWdk/Du =Xz8b -----END PGP SIGNATURE-----

1 0

Re: [v5 02/12] reg.exe: Add REG_EXPAND_SZ tests for reg add
by Stefan Dösinger 20 Oct '14

20 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-17 20:38, schrieb Jonathan Vollebregt: > + /* REG_EXPAND_SZ */ > + run_reg_exe("reg add HKCU\\" KEY_BASE " /v expand0 /t REG_EXpand_sz /d \"dead%PATH%beef\" /f", &r); > + ok(r == REG_EXIT_SUCCESS, "got exit code %d, expected 0\n", r); > + verify_reg(hkey, "expand0", REG_EXPAND_SZ, "dead%PATH%beef", 15, TODO_REG_SIZE); Is there really no observable difference between REG_SZ and REG_EXPAND_SZ? The MSDN description suggests that the behavior you observe here is correct, but I wonder what REG_EXPAND_SZ is good for in this case, other than just an elaborate way to set a flag that says "please call ExpandEnvironmentStrings". -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJURRrSAAoJEN0/YqbEcdMwsFMP/0KQ0ZQxOe5pwDcAX2h2B1tI peMiCJsmb8AwNru1qNjfwEZ/cU5Y7JvDmue3AQqkHKenkyyu5dYw1ItWmsTYW1z/ mRqK7R7/v6frRzPr1iMT4+8MKYVuiPxkgCPHQsMWQGfYBhLk3xVLq/ev64+paLw3 09GjgVWY5JS+vChI+4WX8T0+WS0mmmnbp/+QZb/z3jfNZvYEDXaNFmkITwROfaif ftuYS5VJL70UUxHvHcx6ctcexwnga0ka+voCVFRK/yALLesTB01+eYkn9bgVYVPl O4UC3INvMJsfdDd3KhFJSh/RZBHKn/4TyKQDu0DZDeMJMx/l8Q22TxsutsR5de+L BLQhrxzHVirrBkBrOwc5GCrpdBU0NpQX8mBW/E9kISzFlCHbtWa97F2gqCw6rnaA BU3430R+6aolQ3E47y4CdMZA5I7sIbTa5EdXJdkshExuMDS1V8xph2N/JCttzNPh QczIL7NAHekm+5W/DvuC4wx9jajmiQ/ol4Jr140h48SaEKL97/tWkoXTF/UmtqPi k7kaY3zqTNUyrLAQxarERVy3tZkicRMimvTCLbAFTZ4g86JgU9vjNYRbdbGS/fwr e0bsk8k3C1vtARYi+pYIbHQaQrzAE+/dR3caMVsXf08PTfituRQjlCqgb637Uf43 5iX8bhy6U/mdi9xIUn5W =7z6c -----END PGP SIGNATURE-----

1 0

Re: [PATCH 6/6] d3d8/tests: Use create_device in test_swvp_buffer.
by Marvin 20 Oct '14

20 Oct '14

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=9637 Your paranoid android. === w8 (32 bit device) === device.c:2438: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3142: Test failed: Expected wndproc 0x412ae0, got 0x412ae0.

1 0

Re: [PATCH 5/6] d3d8/tests: Use create_device for test_fpu_setup.
by Marvin 20 Oct '14

20 Oct '14

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=9636 Your paranoid android. === w8 (32 bit device) === device.c:2435: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3139: Test failed: Expected wndproc 0x412b30, got 0x412b30.

1 0

Re: [PATCH 4/6] d3d8/tests: Update create_device to match d3d9.
by Marvin 20 Oct '14

20 Oct '14

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=9635 Your paranoid android. === w8 (32 bit device) === device.c:2423: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3130: Test failed: Expected wndproc 0x412e30, got 0x412e30.

1 0

Re: comctl32: Use strcmpW instead of pointer comparison to ensure treeview updates correctly
by Nikolay Sivov 19 Oct '14

19 Oct '14

On 10/19/2014 20:01, Dan Bassi wrote: > Hi Nikolay. In uTorrent, the Treeview box on the left doesn't update > under Wine unless the box is clicked (whereas under Windows, it > updates automatically without clicking). > > I later traced the error to the "item_changed()" function in > comctl32/treeview.c, which was (incorrectly) detecting the text as > never having changed. This patch seems to fix that behaviour. > > Please let me know your thoughts. Many thanks. What I mean is that we need more tests in comctl32/tests/treeview.c to prove that patch is correct. The fact that it fixes some case with some application is not enough. > > On Sun, Oct 19, 2014 at 4:49 PM, Nikolay Sivov <bunglehead(a)gmail.com > <mailto:bunglehead@gmail.com>> wrote: > > On 10/19/2014 18:44, Dan Bassi wrote: > > + /* Old text is a null pointer due to HeapAlloc() failing, > therefore unable to perform strcmpW so assume text has changed */ > + if (!tiOld->pszText) > + return TRUE; > + > > I don't think you should necessary assume it's changed. > > /* Text has changed and it's not a callback */ > - if ((tvChange->mask & TVIF_TEXT) && (tiOld->pszText != > tiNew->pszText) && > + if ((tvChange->mask & TVIF_TEXT) && > (strcmpW(tiOld->pszText, tiNew->pszText) != 0) && > tiNew->pszText != LPSTR_TEXTCALLBACKW) > return TRUE; > > This is wrong, you can't compare if it's a special callback value. > > + originalItem.pszText = HeapAlloc(GetProcessHeap(), 0, > originalItem.cchTextMax * sizeof(WCHAR)); > > Normally comctl32 code uses Alloc()/Free() functions. > > This patch needs tests first, those tests should cover all > possible combinations regarding callback cases, different pointers > but same data, > same data but different pointers, maybe something else. > > >

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2014