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

Re: Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Henri Verbeet

What happens is that the renderer string is "GeForce 210/PCIe/SSE2", which now ends up getting matched against "GeForce", and the rest mostly just follows from there.

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Alexandre Julliard

Andrei Slavoiu <andrei.slavoiu(a)gmail.com> writes: > On Monday 14 July 2014 17:20:38 Alexandre Julliard wrote: >> Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes: >> >> It doesn't work here: >> >> ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p >> d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of >> adapter memory >> wine: Unhandled page fault on read access to 0x69766574 at address >> 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page >> fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register >> dump: > > Does that test pass without my changes? I'm asking because for me it crashes > with vanilla wine. I logged a bug for mesa about a month ago: > https://bugs.freedesktop.org/show_bug.cgi?id=79575 Yes, of course it passes on my box, otherwise it wouldn't have been committed ;-) -- Alexandre Julliard julliard(a)winehq.org

July 14, 2014

Re: Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Andrei Slavoiu

On Monday 14 July 2014 17:20:38 Alexandre Julliard wrote: > Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes: > > It doesn't work here: > > ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p > d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of > adapter memory > wine: Unhandled page fault on read access to 0x69766574 at address > 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page > fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register > dump: Does that test pass without my changes? I'm asking because for me it crashes with vanilla wine. I logged a bug for mesa about a month ago: https://bugs.freedesktop.org/show_bug.cgi?id=79575

July 14, 2014

Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)

by Alexandre Julliard

Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes: > --- > dlls/wined3d/directx.c | 568 +++++++++++++++++++++++-------------------------- > 1 file changed, 269 insertions(+), 299 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of adapter memory wine: Unhandled page fault on read access to 0x69766574 at address 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6862ab1c ESP:0032fa50 EBP:0032fb08 EFLAGS:00010202( R- -- I - - - ) EAX:68667f05 EBX:68678e50 ECX:00000000 EDX:69766564 ESI:68667f05 EDI:0032fab8 Stack dump: 0x0032fa50: 68667f05 00000000 00000000 0032fab8 0x0032fa60: 00000000 00000000 00000280 000001e0 0x0032fa70: 00000000 00000000 00000000 00000000 0x0032fa80: 00000000 00000000 00060048 68667229 0x0032fa90: 00139670 68668b04 00139688 0032fab8 0x0032faa0: 00000000 00132818 0032fad8 00134650 Backtrace: =>0 0x6862ab1c test_swapchain+0x28c() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:261] in d3d8_test (0x0032fb08) 1 0x68644593 func_device+0x832() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:6461] in d3d8_test (0x0032fd48) 2 0x6862a22f main+0x37e(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/d3d8/tests/../../../include/wine/test.h:584] in d3d8_test (0x0032fe18) 3 0x68667e20 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in d3d8_test (0x0032fe58) 4 0x7b85f65c call_process_entry+0xb() in kernel32 (0x0032fe78) 5 0x7b8606a3 start_process+0x62(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1097] in kernel32 (0x0032feb8) 6 0x7bc7fac0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 7 0x7bc82a6d call_thread_func+0x7c(entry=0x7b860640, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2630] in ntdll (0x0032ffa8) 8 0x7bc7fa9e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 9 0x7bc53f0e start_process+0x1d(kernel_start=0x7b860640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2856] in ntdll (0x0032ffe8) 10 0x680316dd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 11 0x6803179b wine_switch_to_stack+0x2a(func=0x7bc53ef0, arg=0x7b860640, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff81e868) 12 0x7bc59a09 LdrInitializeThunk+0x238(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2910] in ntdll (0xff81e8a8) 13 0x7b866ea3 __wine_kernel_init+0xa02() [/home/julliard/wine/wine/dlls/kernel32/process.c:1269] in kernel32 (0xff81f7a8) 14 0x7bc5a903 __wine_process_init+0x192() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3119] in ntdll (0xff81f838) 15 0x6802ede8 wine_init+0x2c7(argc=0x3, argv=0xff81fd74, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff81f898) 16 0x7bf00d6c main+0x7b(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff81fcd8) 17 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x6862ab1c test_swapchain+0x28c [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:261] in d3d8_test: call *0x10(%edx) 261 hr = IDirect3DSwapChain8_GetBackBuffer(swapchain3, 0, 0, &backbuffer); -- Alexandre Julliard julliard(a)winehq.org

July 14, 2014

Re: [4/9] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables (try3)

by Henri Verbeet

On 11 July 2014 20:44, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > +#ifndef NUMELMS > +#define NUMELMS(array) (sizeof(array)/sizeof((array)[0])) > +#endif If you really want this kind of thing it would be called ARRAY_SIZE, but I'd prefer just writing it out.

July 14, 2014

Re: [PATCH 3/4] vbscript: Implemented Abs(try 7)

by Piotr Caban

On 07/14/14 04:47, Shuai Meng wrote: > 2014-07-13 22:35 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com>>: > > On 07/13/14 15:49, Shuai Meng wrote: > > You're not handling res==NULL case correctly. E.g. Call > Abs("string") should fail. > > I have tested this case for many times, and I think Call > Abs("string") > is just OK https://testbot.winehq.org/__JobDetails.pl?Key=7967 > <https://testbot.winehq.org/JobDetails.pl?Key=7967> > and it's OK that write directly using vbscript on wiinxp and win7. > > Abs should behave in the same way no matter it's return value is > used or not. You have added following test: > Call Abs(-4) > it succeeds because -4 is a valid Abs argument. If you add this test: > Call Abs("string") > it will fail on windows. > > OK，I misunderstand you at first. So maybe I can just remove the two > lines when res == NULL, I tested it and the result is good. You can't pass NULL to VarAbs function.

July 14, 2014

Re: Are there automated tests that verify that Wine's drawing operations produce the same visual output as in Windows?

by Alexander Almaleh

I see that there is no call to Polygon() anywhere in the tests. I might try adding a test case for it. On Sun, Jul 13, 2014 at 9:20 PM, Alexander Almaleh <sashoalm(a)gmail.com> wrote: > Thanks, I'll look into it. > On Jul 13, 2014 8:09 PM, "Ken Thomases" <ken(a)codeweavers.com> wrote: > >> On Jul 13, 2014, at 11:39 AM, Alexander Almaleh <sashoalm(a)gmail.com> >> wrote: >> >> While testing the Polygon() function for my bug report - >> https://bugs.winehq.org/show_bug.cgi?id=36891, I used a test program >> that performs a Polygon() operation on a memory device context, and then >> saves it to a bitmap - i.e. a *.bmp file. >> >> I then compared the bitmaps produced under Windows and Wine using a >> program I wrote in Qt, that just compares width/height, and then makes a >> pixel-by-pixel comparison (and the Polygon() function did indeed produce a >> slightly different bitmap). >> >> Since this process can be easily automated, I'm wondering if such a >> framework is already being used? If not, I could probably make a sample >> test program and image comparison tool, if anyone is interested. >> >> It would be fairly easily to spot all kinds of bugs in the drawing >> functions using such a testing system. >> >> >> There are such tests. They were central to the development of the DIB >> engine. See dlls/gdi32/tests/dib.c. >> >> The tests run under Wine or on Windows, not both in concert. They can't >> directly take output from one and compare to the other. Also, one doesn't >> want to store a slew of bitmaps into the tests for pixel-wise comparison. >> So, the approach is to take a hash of the bitmap data and compare to a >> hash of a known-good bitmap. >> >> -Ken >> >>

July 14, 2014

Re: [1/2] kernel32: Implement GEO_PARENT for GetGeoInfo()

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=7970 Your paranoid android. === wxppro (32 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0 === wvistau64 (32 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0 === w2008s64 (32 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0 === w7u (32 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0 === wvistau64 (64 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0 === w2008s64 (64 bit locale) === locale.c:3904: Test failed: got 0 locale.c:3905: Test failed: got locale.c:3963: Test failed: got 0, count 0

July 14, 2014

Re: [PATCH 3/4] vbscript: Implemented Abs(try 7)

by Shuai Meng

2014-07-13 22:35 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 07/13/14 15:49, Shuai Meng wrote: > >> You're not handling res==NULL case correctly. E.g. Call >> Abs("string") should fail. >> >> I have tested this case for many times, and I think Call Abs("string") >> is just OK https://testbot.winehq.org/JobDetails.pl?Key=7967 >> and it's OK that write directly using vbscript on wiinxp and win7. >> > Abs should behave in the same way no matter it's return value is used or > not. You have added following test: > Call Abs(-4) > it succeeds because -4 is a valid Abs argument. If you add this test: > Call Abs("string") > it will fail on windows. > > OK，I misunderstand you at first. So maybe I can just remove the two lines when res == NULL, I tested it and the result is good.

July 14, 2014

Re: Are there automated tests that verify that Wine's drawing operations produce the same visual output as in Windows?

by Alexander Almaleh

Thanks, I'll look into it. On Jul 13, 2014 8:09 PM, "Ken Thomases" <ken(a)codeweavers.com> wrote: > On Jul 13, 2014, at 11:39 AM, Alexander Almaleh <sashoalm(a)gmail.com> > wrote: > > While testing the Polygon() function for my bug report - > https://bugs.winehq.org/show_bug.cgi?id=36891, I used a test program that > performs a Polygon() operation on a memory device context, and then saves > it to a bitmap - i.e. a *.bmp file. > > I then compared the bitmaps produced under Windows and Wine using a > program I wrote in Qt, that just compares width/height, and then makes a > pixel-by-pixel comparison (and the Polygon() function did indeed produce a > slightly different bitmap). > > Since this process can be easily automated, I'm wondering if such a > framework is already being used? If not, I could probably make a sample > test program and image comparison tool, if anyone is interested. > > It would be fairly easily to spot all kinds of bugs in the drawing > functions using such a testing system. > > > There are such tests. They were central to the development of the DIB > engine. See dlls/gdi32/tests/dib.c. > > The tests run under Wine or on Windows, not both in concert. They can't > directly take output from one and compare to the other. Also, one doesn't > want to store a slew of bitmaps into the tests for pixel-wise comparison. > So, the approach is to take a hash of the bitmap data and compare to a > hash of a known-good bitmap. > > -Ken > >

July 13, 2014