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

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

by Ruslan Kabatsayev

Hi all, I've come across a problem, which may be simplest to see in the following workability diagram, tested on GTAVC on a i915 machine: _____________________________________________ Mesa_\_Wine_|__1.3.21__|__1.5.17__|__1.5.24+_| ____9.0_____|____OK____|____OK____|___slow___| ___~9.1-____|____OK____|___slow___|___slow___| ___~9.1+____|____OK____|_GL_error_|_GL_error_| Here ~9.1- and ~9.1+ are bisected commits between 9.0 and 9.1, with "-" earlier commit and "+" later one. "slow" means slide show instead of normal animation. "GL error" is a set of errors like "err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ device.c / 677". Wine version 1.5.24+ means any wine newer than 1.5.24 up to 1.7.11. All these things are related to wine trying to use GLSL as much as possible, and Mesa trying to make it seem that it supports OpenGL 2+, even on chips like i915, which don't support it. 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? 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? So, I'm not sure where I should report these regressions - to bugs.winehq.org or to bugs.freedesktop.org? I remember some similar bugs reported to wine being closed as UPSTREAM (e.g. bug 33964), and fixed (or worked around?) in Mesa. But on the other hand, wine 1.3 worked perfectly for all Mesa versions - is it really Mesa fault that newer versions of wine don't work? Could someone please explain how to handle such situations? Regards, Ruslan

Jan. 26, 2014

Re: [17/28] msxml3/tests: Use common wine_dbgstr_guid implementation from test.h (resend)

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=4440 Your paranoid android. === wxppro (32 bit domdoc) === domdoc.c:9845: Test failed: got 00244F94

Jan. 25, 2014

Re: [16/28] mshtml/tests: Use common wine_dbgstr_guid implementation from test.h (resend)

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=4439 Your paranoid android. === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found

Jan. 25, 2014

Re: [PATCH 5/5] wmp: Added WindowsMediaPlayer object stub implementation.

by Jacek Caban

On 01/25/14 18:35, Dmitry Timoshkov wrote: > Jacek Caban <jacek(a)codeweavers.com> wrote: > >> +struct WindowsMediaPlayer { >> + IOleObject IOleObject_iface; >> + LONG ref; >> +}; >> + >> +static inline WindowsMediaPlayer *impl_from_IOleObject(IOleObject *iface) >> +{ >> + return CONTAINING_RECORD(iface, WindowsMediaPlayer, IOleObject_iface); >> +} > Will this and below code which needs 'struct WindowsMediaPlayer' but instead > gets just 'WindowsMediaPlayer' compile without a typedef? A typedef is generated by widl from IDL file. Jacek

Jan. 25, 2014

Re: [PATCH 2/5] wmp: Added new DLL.

by Jacek Caban

On 01/25/14 18:33, Dmitry Timoshkov wrote: > Jacek Caban <jacek(a)codeweavers.com> wrote: > >> configure | 2 ++ >> configure.ac | 1 + >> dlls/atl90/Makefile.in | 4 +-- >> dlls/wininet/http.c | 17 ++++++++--- >> dlls/wmp/Makefile.in | 4 +++ >> dlls/wmp/wmp.spec | 4 +++ >> dlls/wmp/wmp_main.c | 82 > Looks like this patch contains some unrelated changes along with > autogenerated configure. Good catch, thanks. I will resend. Jacek

Jan. 25, 2014

Re: [PATCH 5/5] wmp: Added WindowsMediaPlayer object stub implementation.

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > +struct WindowsMediaPlayer { > + IOleObject IOleObject_iface; > + LONG ref; > +}; > + > +static inline WindowsMediaPlayer *impl_from_IOleObject(IOleObject *iface) > +{ > + return CONTAINING_RECORD(iface, WindowsMediaPlayer, IOleObject_iface); > +} Will this and below code which needs 'struct WindowsMediaPlayer' but instead gets just 'WindowsMediaPlayer' compile without a typedef? -- Dmitry.

Jan. 25, 2014

Re: [PATCH 2/5] wmp: Added new DLL.

by Dmitry Timoshkov

Jan. 25, 2014

Re: [2/2] bcrypt/tests: Added conformance test for BCryptGetFipsAlgorithmMode (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=4420 Your paranoid android. === wxppro (32 bit bcrypt) === Timeout

Jan. 24, 2014

Re: kernel32/tests: Add test for FindFirstFileA() (try 5)

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=4419 Your paranoid android. === wxppro (32 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737 === wvista (32 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737 === w2008s64 (32 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737 === w7pro64 (32 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737 === w2008s64 (64 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737 === w7pro64 (64 bit file) === file.c:2454: Test failed: FindFirstFile failed, Error number -559038737

Jan. 24, 2014

Re: [PATCH 2/2] bcrypt/tests: Added conformance test for BCryptGetFipsAlgorithmMode

by Kai Blaschke

Am 24.01.2014 01:20, schrieb Bruno Jesus: > Hi, Kai. > > If the value depends on a registry entry how can you be sure it will > always return 0? If the registry key is the only parameter required to > return in this function IMO you should read the registry here and > check against that instead of a fixed value. Best wishes, Bruno I thought about this - ideally, the test should test the function setting different values in the registry and checking the function's return value accordingly, but this value is a local security policy setting, which we cannot guarantee to be writeable for the user executing the test. I'll add some code which checks if one of the two possible keys exist and then use the actual value to check the result. Interestingly, the original implementation uses the same "wrong", but simple logic I used in the implementation, just returning the lower 8 bits of the DWORD value to determine the enable state. The only difference is that the Microsoft implementation only returns either 0 or 1. Setting the value to 0x100 or any multiple of that causes BCryptGetFipsAlgorithmMode to return 0 on a Windows machine. I'll send in new and hopefully final patches with these changes. -- Kai

Jan. 24, 2014