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

Re: [PATCH 3/7] d3d8/tests: Test that Direct3D8 doesn't modify the pixel format of the window it targets.

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=4890 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x4100c0, got 0x4100c0.

Feb. 13, 2014

Re: [PATCH 5/5] ddraw/tests: Port test_private_data to ddraw4.

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=4886 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001.

Feb. 13, 2014

Re: [PATCH 4/5] d3d8/tests: Add a test for sub resource private data.

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=4885 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x410530, got 0x410530.

Feb. 13, 2014

Re: dpnet: Use registry for lookup in IDirectPlay8Peer (try 2)

by Bruno Jesus

On Thu, Feb 13, 2014 at 1:23 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Corrected pointer arithmetic. > Corrected assign memory for RegGetValueW calls. > > Changelog: > dpnet: Use registry for lookup in IDirectPlay8Peer > > > Best Regards > Alistair Leslie-Hughes > > > Hi, here are my thoughts about this patch, as I told you before I'm really looking forward for your dpnet work =) I'm not used to review patches so if I do something wrong I ask for sorry in advance. + if(!pcReturned || !pcbEnumData) + return E_POINTER; This checks together with the error tests could be in a different patch as they are not related to the main subject of the patch. + while(nextKeyNameResult == ERROR_SUCCESS) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, NULL, &size); + if(res == ERROR_SUCCESS) + { + WCHAR *buf = HeapAlloc(GetProcessHeap(), 0, size); + if(buf) + { + res = RegGetValueW( key, provider, friendly, RRF_RT_REG_SZ, NULL, buf, &size); + if(res == ERROR_SUCCESS) + { + TRACE("%s=%s\n", debugstr_w(provider), debugstr_w(buf)); + + req_size += sizeof(DPN_SERVICE_PROVIDER_INFO) + (size * sizeof(WCHAR)); + + (*pcReturned)++; + } You are only reading the key value in the first loop to trace it, maybe you could simplify this loop with a single RegGetValueW call and no memory allocation just to get the size required and in the next loop where you really copy the data you could trace it. + char *infoend = ((char *)pSPInfoBuffer + (sizeof(DPN_SERVICE_PROVIDER_INFO) * (*pcReturned))); Since you are copying WCHAR data infoend should be a WCHAR pointer and it could be done like this AFAICS: WCHAR *infoend = (WCHAR *)(pSPInfoBuffer + *pcReturned); + while(nextKeyNameResult == ERROR_SUCCESS) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, NULL, &size); + + if(res == ERROR_SUCCESS) + { + WCHAR *buf = HeapAlloc(GetProcessHeap(), 0, size); + if(buf) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, buf, &size); + if(res == ERROR_SUCCESS) + { + pSPInfoBuffer[count].guid = CLSID_DP8SP_TCPIP; + pSPInfoBuffer[count].pwszName = (LPWSTR)(infoend + offset); + lstrcpyW(pSPInfoBuffer[count].pwszName, buf); + What if you read data directly over infoend buffer? This would eliminate the need for buf memory allocation and the strcpy. You would only have to set the pwszName. + offset += size-1; If you do a -1 here the next string will overwrite the NULL terminator from the previous string, won't it? If you decide to copy directly over the infoend buffer you could also get rid from the offset variable since you could do infoend += size instead. Best regards, Bruno

Feb. 13, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

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=4882 Your paranoid android. === w8 (32 bit visual) === visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 2/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 2/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 1/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 1/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 1/1, expected 0x000b8b00, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 2/1, expected 0x00b6ffa3, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 1/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 2/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 1/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 2/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 1/1, expected 0x006dff45, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 2/1, expected 0x0000d500, format D3DFMT_YUY2.

Feb. 13, 2014

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 15:49, schrieb Stefan Dösinger: > Looks good, thanks! > > Wrt the testbot failures: It looks like > CheckDeviceFormatConversion is in fact the right way to check this > - I missed a sentence in the msdn page. I'll send a patch to handle > this in this test and yuv_color_test. Real Windows drivers seem to > agree with our interpretation of CheckDeviceFormatConversion. I've sent a patch (id 102467) that should take care of the testbot failures on the Windows 8 machine. The fix should conceptually work for your test as well. I'm not entirely sure why Henri didn't ack your patches, but my guess it's because of the testbot failure or he was just waiting a day for the dust to settle. If not I'm sure he'll voice his concerns. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/U4sAAoJEN0/YqbEcdMwjqkQAJJWOztWX1qVURmKdH8Kzve8 COnAyRN4sDdexdEL3m7GzeGq269+tLPriGcePnqkqpERUYI5tRE+rixOQeojG4Ee F6o4CxoG/MOxaxTNt7ZAx5k7ZGq3Of35I8cO1pM4ENJR0VSaot1KCGjfQj7dkoU+ 1f55VHNp8JGY8Mi7bsKkKe5IZf0I3cJHtVQ9l/SKGaaee62eT5QJKBRvLpdkLxTk Eb7OlJi5zs3YWetKxEZmQS7+lvXSmZt7JsWl2BjxKKCYr3X3L54cSwjngv8TwKF8 EY0i2F9L+aPMXYqmtF5DeMlVgEVmAwSG1qTfGULaocLLu5AaR2HFiRUisRrxpkRq dq6BIFBqE9sGY4gDrJaLk9JTRg8W4zTwbX7lonMTI/wu7i2NwmIF1zo3yuypozLH GUpvoUqgys4DF6Xq+yQKg9Hedx/Eu9KzBdtQtJ5lgq8TbZuzuDtarBUZr5V2Mus0 N+gHx57wTAAzeldQ676hueVOPTH8zz3hk5TihWMA2OISyoGojNnTaaPOuiIZ4a4Y 6HZCTaWHCdMDk8Uf2P3M0Bnrh+o9lJddwToNPim8dvhI17HLIzWiThsKMHjcwK4I U9Ov4IvSdRYySAgPBXb/5Tx4L3e4wzUOogIOw9f5uyctluq5vW9Cc0z0d4siOfOe 2yNNPm+SJVbR5nmoqDHx =uLek -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Sebastian Lackner

Am 13.02.2014 15:24, schrieb Stefan Dösinger: > Am 2014-02-13 14:57, schrieb Jacek Caban: > Martin, Michael or Sebastian: If you are reading this thread maybe you > can share your thoughts from the point of view of someone who isn't a > long-term contributor. > I have to agree with Stefan, for someone new trying to contribute to the project its really confusing. Often not even inside a single DLL a unique style is used, and especially tests are often even a bit worse. When someone wants to contribute, he might just think that there isn't any code style restriction at all. But even with the knowledge that there is one, its sometimes not very clear what the rules are exactly. Noone would start by creating statistics first, to figure out what the most commonly used style is. To sum it up, I would also support the idea to refactor the whole code base. Several methods (ordered from best to worst): * refactor the code globally, such that every component uses the same style. This would be the easiest method for people to check their own code, since they can just use a checktool on the whole wine source. * at least a single code style for each DLL/component individually, and someone who documents the used code style for every component if its not obvious (like a header field or as part of the spec file?). * as a last option, but very complicated, and most likely not worth the effort: instead of refactoring Wine could provide some git precommit hook / other check tool, to test patches if they match the rules for a specific component BTW: with "git blame -w" its not even necessary to run it twice ;) Regards, Sebastian

Feb. 13, 2014

Re: [PATCH 1/3] atl: Share atl_ax.c with atl100.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/atl/Makefile.in | 3 ++- > dlls/atl/atl.spec | 18 +++++++++--------- > dlls/atl/atl_main.c | 48 ------------------------------------------------ > dlls/atl100/atl_ax.c | 15 ++++++++++----- > 4 files changed, 21 insertions(+), 63 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M atl.dll -p atl_test.exe.so atl_ax && touch atl_ax.ok atl_ax.c:133: Test failed: wcex.style 00004008 make[1]: *** [atl_ax.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2014

Re: urlmon: Unregister window class on DLL unload.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -83,15 +83,50 @@ static LRESULT WINAPI notif_wnd_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM > return DefWindowProcW(hwnd, msg, wParam, lParam); > } > > +static const WCHAR wszURLMonikerNotificationWindow[] = > + {'U','R','L',' ','M','o','n','i','k','e','r',' ', > + 'N','o','t','i','f','i','c','a','t','i','o','n',' ','W','i','n','d','o','w',0}; > + > +static ATOM notif_wnd_class; > + > +static CRITICAL_SECTION notif_wnd_class_cs; > +static CRITICAL_SECTION_DEBUG notif_wnd_class_cs_dbg = { > + 0, 0, &notif_wnd_class_cs, > + { &notif_wnd_class_cs_dbg.ProcessLocksList, &notif_wnd_class_cs_dbg.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": notif_wnd_class") } > +}; > +static CRITICAL_SECTION notif_wnd_class_cs = { &notif_wnd_class_cs_dbg, -1, 0, 0, 0, 0 }; > + > +static BOOL ensure_notif_wnd_class(void) > +{ > + EnterCriticalSection(&notif_wnd_class_cs); > + > + if(!notif_wnd_class) { > + static WNDCLASSEXW wndclass = { > + sizeof(wndclass), 0, notif_wnd_proc, 0, 0, > + NULL, NULL, NULL, NULL, NULL, > + wszURLMonikerNotificationWindow, NULL > + }; > + > + wndclass.hInstance = hProxyDll; > + notif_wnd_class = RegisterClassExW(&wndclass); > + } > + > + LeaveCriticalSection(&notif_wnd_class_cs); > + > + return notif_wnd_class != 0; > +} You don't really need a whole new critical section for this. Just use InitOnce or interlocked functions. -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2014

Re: Converting source to unicode, bug 28189

by Akihiro Sagawa

On Thu, 13 Feb 2014 07:35:21 -0500, Hugh McMaster wrote: > I've put together a draft patch to address bug 28189, regsvr32: > No usage in wineconsole. > > I'm using resource strings and have converted all of the printf calls > to WriteConsoleW. > > I also converted the source to Unicode, but overall, there are few > coding points I'm not quite sure about. > > If someone could look over the changes and offer some feedback, > I'd certainly appreciate it. > > URL: http://bugs.winehq.org/show_bug.cgi?id=28189 Hello Hugh, Regarding your patch, attachment #47519, I roughly read the code and post comments at the following points: 1. Dead assignment: In output_write function, len and ret initial value will overwrite by function return value. You don't need to initialize them. 2. Memory leaking: if (!strA) is true, calling LocalFree(str) is necessary before return. 3. Usage indent: I'm not sure about STRING_USAGE and spaceSpaceW. Another command line tool, e.g. cmd.exe, doesn't do like this. Additionally, it might confuse po translators. 4. /I option handing: lstrcmpiW isn't compatible with strncasecmp. 5. Double quote handling: command_line is advanced when the code finds a double quote character. When it updates wsCommandLine? 6. Needless changes: `/**' -> `/*', pointer asterisk position, a space character after C-language keyword. Please follow surround coding style. 7. Silent handling: Many times, it refers Silent variable before calling output_write function. How about moving the check to the function? Hope these comments are helpful. Regards, Akihiro Sagawa

Feb. 13, 2014