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

Re: [PATCH 2/5] shell32: Added FolderItemVerbs stub
by Marvin 10 May '15

10 May '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=13304 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CB87106 === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CAA259F === wvistau64 (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 75C4B510 === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7522B578 === w7u (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 76C263C4 === wvistau64 (64 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 000007FEFEA52BD9 === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 000007FEFE352A7D

1 0

Re: [PATCH 1/5] shell32: Implement ParseName()
by Marvin 10 May '15

10 May '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=13303 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra"

1 0

WineTest log size
by Francois Gouget 08 May '15

08 May '15

TL;DR: The todo below generates more than 90 KB of test report data. It would be really nice to fix it. storage32.c:3401: todo_wine ok(failed == expect_failed, "open with byte %x locked, mode %x %s but should %s\n", Some of my WineTest reports went over the 1.5MB limit again and while the issue was not what I initially thought, I wrote a script (see attachment) to slice and dice them to figure out who contributes what. Lines Bytes Category 1530 114848 9 traces generating >= 5120 bytes each 1842 106511 33 traces generating 2048 - 5119 bytes each 7020 358649 2221 traces generating < 2048 bytes each 2071 180266 9 todos generating >= 5120 bytes each 842 67746 20 todos generating 2048 - 5119 bytes each 4622 329705 2894 todos generating < 2048 bytes each 170 15372 Test failed 2787 144801 Others -------------------- 20884 1317898 Total Traces are easy to deal with so I've sent some patches. We'll see how it goes. The todos are much harder as they require fixing Wine. Still, if we manage to fix the top 9 we'll save around 180 KB. The next 66 KB require fixing 20 more todos, which is still somewhat plausible, but it gets hopeless after that. The 'Others' category corresponds to the report header with the dlls list, and to the per test summaries. So we're looking at minimum report size of 813 KB, but in practice we're unlikely to get below 1 MB. Here are the top 20 traces and todos: $ dupcount --traces *.report | head -n 20 Lines Chars Match 296 31777 font.c:3711: # Patch pending 339 20378 protocol.c:765: # Patch pending 143 14471 ddrawmodes.c:369: # Patch pending 171 9576 loader.c:1414: # Patch pending 226 9121 clipboard.c:154: # Patch pending 90 9050 ddrawmodes.c:340: # Patch pending 105 7875 istream.c:486: # Patch pending 82 7444 win.c:82: 78 5156 button.c:588: 85 5015 shlview.c:59: 145 4785 locale.c:3296: # Patch pending 131 4716 protocol.c:583: # Patch pending 54 4539 http.c:428: 56 4300 metafile.c:1736: 75 4050 locale.c:3215: # Patch pending 145 3936 locale.c:3190: # Patch pending 57 3846 msg.c:11475: 98 3626 clipboard.c:132: # Patch pending 48 3574 metafile.c:504: $ dupcount -e '^[^:]*:[0-9]*: Test marked todo*:' *.report | head -n 20 Lines Chars Match 902 93357 storage32.c:3401: Test marked todo: 296 21312 sock.c:2741: Test marked todo: 256 18176 virtual.c:3350: Test marked todo: 256 14592 ebrowser.c:1742: Test marked todo: 110 8405 shlexec.c:1472: Test marked todo: 22 6530 shlexec.c:1462: Test marked todo: 74 6395 font.c:3789: Test marked todo: 92 6074 propvariant.c:169: Test marked todo: 63 5425 font.c:3781: Test marked todo: 63 4788 file.c:4209: Test marked todo: 63 4714 file.c:4207: Test marked todo: 29 4569 dib.c:1322: Test marked todo: 64 4504 graphics.c:3686: Test marked todo: 64 4432 graphics.c:3657: Test marked todo: 64 4432 graphics.c:3674: Test marked todo: 54 4042 saxreader.c:2393: Test marked todo: 42 3982 qcap.c:337: Test marked todo: 38 3834 saxreader.c:2489: Test marked todo: 25 3764 batch.c:312: Test marked todo: -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

2 1

Re: gdi32/tests: Silence some font traces that generate too many lines.
by Marvin 08 May '15

08 May '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=13293 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Re: [PATCH] add the interfaces necessary to use the D3D11 video decoder
by Qian Hong 08 May '15

08 May '15

Hi Steve, On Fri, May 8, 2015 at 3:03 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: > Anyone has anything to say about this ? Thanks for your contribution, glad to see VLC people! I'm not the right person to ack your patch, but I can help to point out a few tiny formatting issues: - The patch title could be rename to "include: Add D3D11 video decoder interfaces" Here is an example of this stile of patch title: `git show e35f82665cfdb40231c2e0a8a41c81642273160d` - There are a couple of trailing spaces in the code which should be removed, for example: 94 + UINT NumEncryptedBytesAtBeginning;<spaces> 176 +typedef struct D3D11_VIDEO_PROCESSOR_CUSTOM_RATE<space> and about 90+ more lines with trailing spaces. Could you fix that and resubmit? Thanks! -- Regards, Qian Hong - http://www.winehq.org

1 0

[PATCH 1/2] cmd/tests: Add tests for console InsertMode
by Hugh McMaster 07 May '15

07 May '15

Alexandre, What changes to you want to see for my InsertMode tests to be committed? http://source.winehq.org/patches/data/111149 Thanks, Hugh -- Hugh McMaster

1 0

Re: winecfg: add all Windows versions and accompanying error message (try 5)
by Jason Overland 06 May '15

06 May '15

Is there anything I can do to improve this patch? Thanks, Jason On 04/30/2015 01:56 PM, Jason Overland wrote: > This supercedes winecfg: add all Windows versions and accompanying error message (try 4). > > Changes since try 4: > > Windows versions that are unavailable in 64 bit prefixes now have a different text in the combobox saying as such. They still display an error dialog if the user tries to select them.

1 0

Re: user32: After handling an internal message give a chance to real message to arrive.
by Alexandre Julliard 06 May '15

06 May '15

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > else > peek_message( msg, info.msg.hwnd, info.msg.message, > info.msg.message, flags | PM_REMOVE, changed_mask ); > - continue; > + > + /* give a chance to real message to arrive */ > + HeapFree( GetProcessHeap(), 0, buffer ); > + return FALSE; Why do you need to leave the function instead of checking for further messages? What is the issue you are seeing? -- Alexandre Julliard julliard(a)winehq.org

2 17

Wine Joysticks, seeking a plan
by Aric Stewart 06 May '15

06 May '15

Hi all, Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset. This was discussed back on 2005 and I know there was also recent discussion around BSD that also involves this. I also have an itch to start to poke at xinput, but I have no interest in poking at xinput with the current way joysticks are handled. When I was working on this driver thing Alexandre expressed he was pretty opposed to having a whole new set of platform specific wine drivers. (winejoystick_mac, winejoystick_linux, etc...) But if we at least did that we would reduce code duplication by not having the platform specific code duplicated in 2 (with xinput it would become 3) places and have it collected in one place. Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant. but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced. We of course need to make sure we come up with a plan that Alexandre will approve of. Would a replacement winejoystick.drv that holds all the platform specific code be acceptable? Is there a case where we would want that driver to be able to build multiple platform code? Maybe Linux and Linux Input? I will admit I am pretty ignorant of the Linux side of this whole situation. Ideas? Comments? thanks! -aric

7 9

Re: [PATCH 1/2] shell32: Implement Application property of IShellFolderViewDual
by Marvin 05 May '15

05 May '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=13252 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:389: Test failed: unexpected type guid {efd84b2d-4bcf-4298-be25-eb542a59fbda} === w2003std (32 bit shelldispatch) === shelldispatch.c:389: Test failed: unexpected type guid {efd84b2d-4bcf-4298-be25-eb542a59fbda}

1 0