March 2015 - Wine-devel - list.winehq.org

Re: [PATCH 2/4] ddraw/tests: The testbot applies color keying without a key.
by Marvin 22 Mar '15

22 Mar '15

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=12332 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6302: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6306: Test failed: Got unexpected color 0x00000080.

2 2

Re: [PATCH] wined3d: Don't use the builtin FFP uniform for the normal matrix.
by Matteo Bruni 21 Mar '15

21 Mar '15

2015-03-20 18:56 GMT+01:00 Matteo Bruni <mbruni(a)codeweavers.com>: > + memcpy(out, &temp, sizeof(temp)); Meh. Then there is the missing check for the singular matrix case as Sebastian spotted. I'll do some tests and resend, or send just a patch readding some calls to set GL_MODELVIEW if that takes too long.

1 0

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Stefan Dösinger 20 Mar '15

20 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Good work debugging this. My knowledge about advapi32 is limited, but I have a comment about the test: Am 2015-03-19 um 13:06 schrieb Bernhard Übelacker: > + pConfig->lpDescription = NULL; > + ret = pChangeServiceConfig2A(svc_handle, SERVICE_CONFIG_DESCRIPTION,buffer); > + ok(ret, "ChangeServiceConfig2A failed with null pointer\n"); > + if (!ret) { > + goto cleanup; > + } Adding the test like this may work, but I don't think it is the right way. This call may overwrite settings set by the previous ChangeServiceConfig2A call if it succeeds. If it fails (and doesn't crash) the test can continue just fine since the previous call set up the configuration. I think it would be better to move this into its own test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVDAHWAAoJEN0/YqbEcdMwNOgP/irtATTOHllTYLRxVI13UiNi muUvj+pkXYLHzmx6Fzrp90nlu6SCE5yqk4JkE+sHJO3xReQ0r5b7hnAKmgiAEsqk cVLjBXbyrP+gciLPfSJiYUHTwbfFOiEfKhcpcS4llGj2iHpU3XgEkvvTVrxzTfBz lAyp1shmD4zBLq9urW2/zc5YsXtzVOIRSKW2X+S8nyem+pikRi15F7Dm07hftquw Xv/krwZw/36/FKP6gkMk+5594OHmjHiknn+cQFkTZdLXiTdtSqzVWigTfn7IR4rT 0Y0eCeDQI16mcitAVnYgmaaOodIe/J8KmleBJb13VEQxQOIhPyU5ujHys6avoJks JeD/n2NUhzHtNqwxdiGLMnZJXPK3Jt9wSMF6EQu2hY0XURYwwPVEeWegjo/PfdO/ 9fwSRlTfBLVnYIM66fFbntR7M8S/aaYnXdRWNF49GRRgRLb7HMMC27yBnoGif1dC nhaFWS98jM4kByDSf3ib/OPqIdjPc9K/j6X2ilp/Tjx8ybiXxpB/GFojmyaP0j7p fZ4BH4edz85IrzS9Usq53ugpP1lViDeUWcoZrF6wBUrXgiP/EzqV+SNJTesDbFzX DjkhwhuQxsnmKS5hLQkX24uCmY0trs1CFm3eoN+eg2+tXVknLfrQ2M88AblPPxbS Wg5PW20xgEIZ1dbXShSZ =lLfe -----END PGP SIGNATURE-----

1 0

Re: mlang/tests: Use BSTR strings instead of plain WCHARs when API tells so
by Dmitry Timoshkov 20 Mar '15

20 Mar '15

The tests were written this way to ensure that mlang methods do not depend on BSTR layout (and yes, at least IE6 depends on this). -- Dmitry.

2 2

Re: user32/tests: Test return value of EnumDesktopsA (PVS-Studio)
by Marvin 19 Mar '15

19 Mar '15

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=12320 Your paranoid android. === w2000pro (32 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === wvistau64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === w2008s64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed!

1 0

Compiling with GCC 5.0
by Michael Cronenworth 19 Mar '15

19 Mar '15

Has anyone given GCC 5.0 a shot? It breaks x86_64 for me and other Fedora 22+ users (22 and up use 5.0). Running wine as pure 32-bit does not exhibit issues. We're using 1.7.36 with wine-staging applied. In 64-bit mode it will not create a valid wine-prefix so I cannot run winedbg and nothing eventful happens with gdb attached to wine. Any ideas on how to debug this further? Here is the terminal output when a fresh prefix is attempted to be made: http://fpaste.org/187377/25868142/ Regards, Michael

3 9

Re: mstask: Added IEnumWorkItems stub
by Marvin 19 Mar '15

19 Mar '15

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=12318 Your paranoid android. === w2000pro (32 bit task_scheduler) === task_scheduler: unhandled exception c0000005 at 6AC2AEEF

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Sebastian Lackner 19 Mar '15

19 Mar '15

On 19.03.2015 16:22, Andrew Eikum wrote: > --- > dlls/kernel32/kernel32.spec | 4 +- > dlls/kernel32/path.c | 97 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/kernel32/tests/file.c | 88 ++++++++++++++++++++++++++++++++++++++++ > include/winbase.h | 2 + > 4 files changed, 189 insertions(+), 2 deletions(-) > Why do you do the work twice? It would have been much easier if you would have just helped us to review and improve our Staging patchset which is there since about half a year ago, and supports a lot more flags. https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… Why does noone bother anymore to test those patches, the author Michael Müller asked for feedback there long time ago: https://bugs.winehq.org/show_bug.cgi?id=36073#c4 I'll submit the patches in a few minutes so that you can decide if its better/worse than the current approach. Regards, Sebastian

3 6

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Marvin 19 Mar '15

19 Mar '15

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=12304 Your paranoid android. === wvistau64 (32 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4060: Test failed: SetFileValidData failed 87 file.c:4063: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Dmitry Timoshkov 19 Mar '15

19 Mar '15

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + info->FileName[info->FileNameLength / sizeof(WCHAR)] = 0; > + if (!RtlDosPathNameToNtPathName_U( info->FileName, &nt_name, NULL, NULL )) > + { > + SetLastError( ERROR_PATH_NOT_FOUND ); > + return 0; > + } > + > + name_wchars = nt_name.Length / sizeof(WCHAR); > + if (name_wchars + 1 > len) > + { > + RtlFreeUnicodeString( &nt_name ); > + return name_wchars + 1; > + } > + > + memcpy( outstr, nt_name.Buffer, nt_name.Length ); > + outstr[name_wchars] = 0; Where did you get an idea that you should return an nt path from this API? There is no a single check in the tests for a returned file name, and this whole thing looks over complicated. -- Dmitry.

1 0