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

Re: d3d9/tests: Fix a typo in skip() message
by Henri Verbeet 09 May '16

09 May '16

On 1 May 2016 at 10:53, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > - skip("Failed to create a vetex shader\n"); > + skip("Failed to create a vertex shader\n"); The typo fix is fine of course, but if you're going to touch the line please fix the punctuation as well.

1 0

Re: [PATCH v2] d3d11/test: Test for ID3D11InfoQueue interface
by Józef Kucia 09 May '16

09 May '16

On Mon, May 9, 2016 at 11:04 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Added sign. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3d11/tests/d3d11.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c > index 03b6113..988c83b 100644 > --- a/dlls/d3d11/tests/d3d11.c > +++ b/dlls/d3d11/tests/d3d11.c > @@ -882,6 +882,11 @@ static void test_device_interfaces(void) > "Device should implement ID3D10Multithread interface, hr %#x.\n", hr); > if (SUCCEEDED(hr)) IUnknown_Release(iface); > > + hr = ID3D11Device_QueryInterface(device, &IID_ID3D11InfoQueue, (void **)&iface); > + ok(SUCCEEDED(hr) || broken(hr == E_NOINTERFACE) /* Not available on all Windows versions. */, > + "Device should implement ID3D11InfoQueue interface, hr %#x.\n", hr); > + if (SUCCEEDED(hr)) IUnknown_Release(iface); > + > hr = ID3D11Device_QueryInterface(device, &IID_ID3D10Device, (void **)&iface); > todo_wine ok(hr == E_NOINTERFACE, "Device should not implement ID3D10Device interface, hr %#x.\n", hr); > if (SUCCEEDED(hr)) IUnknown_Release(iface); I think this test is wrong. AFAIK ID3D11InfoQueue is only available when you have the debug layer enabled. You can enable the debug layer by creating a device with the D3D11_CREATE_DEVICE_DEBUG flag.

1 0

Re: msi: Do not return success on failure (spotted by clang)
by Hans Leidekker 09 May '16

09 May '16

On Sun, 2016-05-08 at 18:31 +0300, Kirill Smirnov wrote: > Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov(a)gmail.com> > --- > dlls/msi/where.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/msi/where.c b/dlls/msi/where.c > index e3bc9b7..ddd8c07 100644 > --- a/dlls/msi/where.c > +++ b/dlls/msi/where.c > @@ -593,7 +593,7 @@ static UINT WHERE_evaluate( MSIWHEREVIEW *wv, const > UINT rows[], > > default: > ERR("Invalid expression type\n"); > - break; > + return ERROR_FUNCTION_FAILED; > } > > return ERROR_SUCCESS; It doesn't apply here: $ patch -p1 --dry-run < 122148 checking file dlls/msi/where.c patch: **** malformed patch at line 16: UINT rows[], Looks like your mail client wrapped long lines.

1 0

Re: riched20: Properly clear all of a buffer of type WCHAR.
by Huw Davies 09 May '16

09 May '16

On Sun, May 08, 2016 at 10:15:49PM +0200, Gerald Pfeifer wrote: > buf is an array of WCHAR, so this memset falls short. > > If you prefer, I can submit a patch that rather uses sizeof(buf); > just let me know. Hi Gerald, Yes, please use sizeof(buf). Thanks, Huw.

1 0

Re: [Bug 40598] Warframe launcher connection timeout
by Linda Licari 09 May '16

09 May '16

yes here is a list of messages when run from the development version fixme:olepicture:OleLoadPictureEx (0x16d8524,3270,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32faa0), partially implemented. fixme:ieframe:OleControl_FreezeEvents (0x179240)->(1) fixme:ieframe:PersistStreamInit_Load (0x179240)->(0x16d8524) fixme:ieframe:ViewObject_SetAdvise aspects and/or flags not supported yet fixme:ieframe:WebBrowser_QueryInterface (0x179240)->({55980ba0-35aa-11cf-b671-00aa004cd6d8} 0x32fa4c) interface not supported fixme:nls:GetThreadPreferredUILanguages 00000034, 0x32ef14, 0x32ef84 0x32ef1c fixme:nls:get_dummy_preferred_ui_language (0x34 0x32ef14 0x32ef84 0x32ef1c) returning a dummy value (current locale) fixme:olepicture:OleLoadPictureEx (0x16d8524,4137,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32fa70), partially implemented. fixme:olepicture:OleLoadPictureEx (0x16d8524,359907,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32fa70), partially implemented. fixme:olepicture:OLEPictureImpl_SaveAsFile (0x16b270)->(0x148b48, 0, 0x0), hacked stub. fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393} fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4f92-6699-11cf-b70c-00aa0060d393} fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4f92-6699-11cf-b70c-00aa0060d393} fixme:ieframe:OleControl_FreezeEvents (0x179240)->(0) fixme:ieframe:OleControl_FreezeEvents (0x179240)->(1) fixme:ieframe:ViewObject_SetAdvise aspects and/or flags not supported yet Regards, Linda Licari On Sun, May 8, 2016 at 5:41 PM <wine-bugs(a)winehq.org> wrote: > https://bugs.winehq.org/show_bug.cgi?id=40598 > > Sebastian Lackner <sebastian(a)fds-team.de> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Component|-unknown |-unknown > Product|Wine-staging |Wine > > --- Comment #1 from Sebastian Lackner <sebastian(a)fds-team.de> --- > Thanks for the bug report. Could you please test if this issue also occurs > with > the development version of Wine? If it occurs in both versions, the "Wine" > product is more appropriate. > > -- > Do not reply to this email, post in Bugzilla using the > above URL to reply. > You are receiving this mail because: > You are watching all bug changes. > > > -- - Try and fail but don't fail to try.

1 0

Re: [PATCH 1/2] riched20: Don't call UpdateWindow after setting the background color.
by Bruno Jesus 09 May '16

09 May '16

On Fri, May 6, 2016 at 11:04 AM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > +static void test_background(void) > +{ > + HWND hwndRichEdit = new_richedit(NULL); > + RECT updateRect; > + > + /* set the background color to black */ > + ValidateRect(hwndRichEdit, NULL); > + SendMessageA(hwndRichEdit, EM_SETBKGNDCOLOR, FALSE, 0); > + GetUpdateRect(hwndRichEdit, &updateRect, FALSE); > + ok(!IsRectEmpty(&updateRect), "The update rect should not be empty\n"); > + > + DestroyWindow(hwndRichEdit); > +} I believe you should clear updateRect before calling GetUpdateRect, also according to msdn the return value of GetUpdateRect should also reflect if the rect was changed or not so it could be a double test. Best wishes, Bruno

2 1

[PATCH] po: Update Norwegian translation
by Beren Camlost 08 May '16

08 May '16

A couple of my own errors that slipped through the cracks. Signed-off-by: Kim Malmo <berencamlost(a)msn.com> --- po/nb_NO.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/po/nb_NO.po b/po/nb_NO.po index 5cc5229..848c720 100644 --- a/po/nb_NO.po +++ b/po/nb_NO.po @@ -5,7 +5,7 @@ msgstr "" "Project-Id-Version: Wine\n" "Report-Msgid-Bugs-To: http://bugs.winehq.org\n" "POT-Creation-Date: N/A\n" -"PO-Revision-Date: 2016-05-04 12:00+0200\n" +"PO-Revision-Date: 2016-05-08 20:00+0200\n" "Last-Translator: Kim Malmo <berencamlost(a)msn.com>\n" "Language-Team: Norwegian Bokmål <alexsornes(a)gmail.com>\n" "Language: nb_NO\n" @@ -11632,14 +11632,14 @@ msgid "" "occurred.\n" msgstr "" "reg: Kan ikke slette alle registerverdiene i \"%1\". Ett uventet " -"problemoppstod.\n" +"problem oppstod.\n" #: reg.rc:54 msgid "" "reg: Unable to complete the specified operation. An unexpected error " "occurred.\n" msgstr "" -"reg: Kan ikke fullføre den spesifiserte operasjonen. Ett uventetproblem " +"reg: Kan ikke fullføre den spesifiserte operasjonen. Ett uventet problem " "oppstod.\n" #: reg.rc:55 -- 1.9.1

1 1

Re: [PATCH 5/6] d3drm: Implement IDirect3DRMTexture*::InitFromFile.
by Stefan Dösinger 08 May '16

08 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-08 um 11:31 schrieb Aaryaman Vasishta: > + /* d3drm intentionally leaks a reference to IDirect3DRM here if texture has already been initialized. */ > + if (texture->d3drm) > + IDirect3DRM_AddRef(texture->d3drm); > + > + if (texture->image) > + return D3DRMERR_BADOBJECT; > + if (FAILED(hr = d3drm_texture_load(texture, filename, FALSE))) > + return hr; Does it also leak if the file fails to load? It's probably better to create the image and then pass it to InitFromImage instead of re-coding this part. Is there any situation where texture->d3drm would be NULL? The same question applies to the newly introduced check in d3drm_texture_destroy. > + /* Use an internal destroy callback to destroy image struct */ > + hr = IDirect3DRMObject_AddDestroyCallback(&texture->IDirect3DRMTexture3_iface, destroy_image_callback, texture); > + > +cleanup: > + UnmapViewOfFile(buffer); > + CloseHandle(hmapping); > + CloseHandle(hfile); > + > + return hr; You'll leak the image if AddDestroyCallback fails. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXL2hHAAoJEN0/YqbEcdMwezQP/0X9Ik1RbPNFRgvvFRxhrFQE VLstrghPD28bQQ2i7YoVsdNCZMCyIQa+7GVzI/3d5pakyldEr/7OVIvHHGyxa8j/ YP2O0JTNGxVVhNB0pUM6bEPpnUj7BOPm0uCkcPhU42QVevzKBL7jUnl5Jx/j+j0K Dld9+WDh3i2sSsrtFg2MLdsi4oG5ej3eOFuN2jibceK5hLR4UI1vwyyccCsD+Xd3 NmKnG6KMfiQsvVjxW7IoO5qDcmzZsKzdnMHFgL93KKkOkP2SBhODJckiWNNeswcr XFjd6r9NBIZsFGdIBM040ph4gd/cu7h3R/IWw2hG++oQ+qxX0NOH61GNoUasjyQh hKjyVqmjJa6MUPezzqoFv3XRPQGVnz4Q3l7GSp0QQYCJYtZR+8vey3ezkIuvfFNA GszecmBvvi3Bv4Ir6JriJSUjTC73EcluKhS6WmFk+UxABrn0TBGSgFWkMENdxP6F vE90h/a/JumNtdlCibpB/ctFP7NIWDs2Uz7RjrCQUPaXH86+hUtcs92farOi7JzV EuwzXW1a2qgb7O6ZHWSxdCTvmJZy9rjS1gP8aH0gqUWaxr1FjJsPiOvSWU1/P1QX qD/M/kENP4O0tmsI/dwnDRJ6lHf8FH71uNR0kRq2eWJa/clFdC+h5uMHRDx5w+iy jlZ0/xkcdFzzaOJV1Yw0 =cwCD -----END PGP SIGNATURE-----

2 1

Re: [PATCH 3/6] d3drm: Implement IDirect3DRM*_CreateTexture. (v3)
by Stefan Dösinger 08 May '16

08 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-08 um 11:31 schrieb Aaryaman Vasishta: > + if (!d3drm_validate_image(image)) > + return D3DRMERR_BADVALUE; Is this necessary? InitFromImage does it anyway I think. > > if (FAILED(hr = d3drm_texture_create(&object))) > return hr; You could call the public CreateObject method here, but I don't have a strong opinion on this. > + object->d3drm = &d3drm->IDirect3DRM_iface; Afaics InitFromImage does it anyway. It also causes problems when InitFromImage fails for some reason - you'll decref the d3drm object in the error path below. > + if (FAILED(hr = IDirect3DRMTexture3_InitFromImage(&object->IDirect3DRMTexture3_iface, image))) > + { > + d3drm_texture_destroy(object); > + return hr; > + } -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXL2HbAAoJEN0/YqbEcdMw9JcP/iXXJN5PuvyuLqki+eKgQHCv fdRtBfdm57foN7+hfOcG9hZGgVWpdPMj5YFZmNhCaWKlnNjcxKDJE/ZsjsRaYXmD pKPb6mLbNcZVBHyNeqbRcwlgJBiDLYIHM8BiT5DwssQK2lo8UmhVGJgmNZNPlGy8 sw/drdMg0lW11N6rOZR/fXcm5NY9F7oIAuI9945uElbOXg3byBvLAQdpPE95yJ5p 8rAQotCsbnqzGFEyRw3E1+0uKplBoaXd6ML+jhDrHK9Eqw0XWUtUsCuWiaYkTDGX 82XXWjhjsxQ84GkSKOweqtum6HjGDSnSZz12YTDMbspLywIpKzSMO5+O/dtxsolI a5scAHlpYQ/bLK3TCWOkwNEsMkXBRjM8+j+PX1I3SQICdl3GmNxVo/b4ZU+0Wqt5 GwzyerUB2an5Dyf/+l7jqH0SxWgcrIiwa/ZTCxttAafDSooFhERwj402WhNQcZLN BD9Jef52AYCJrduV3b3udvTyPuWCrPkkrm3NTSO6dbCIZG9EzMcujJZnA0D52y2E qwfpfsfNNUJ7hkS1322u48i7GaSCZNoK6ISlA9RqtjVoRCGZKG/nGTwQgznrclB1 mvR24DUvAmogeTV0Akm20wUN3/n5sIkz47b0vb9Z5Jjg1v+90nTQ43pcMT0GCJhP cN0YfnUAgpi7yD4yfA1E =JJ9X -----END PGP SIGNATURE-----

2 2

Re: [PATCH 2/6] d3drm: Implement IDirect3DRMTexture{2-3}_InitFromImage. (v3)
by Stefan Dösinger 08 May '16

08 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-08 um 11:31 schrieb Aaryaman Vasishta: > + hr = IDirect3DRMTexture2_InitFromImage(texture2, &initimg); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %x.\n", hr); > + /* Release leaked reference to d3drm1 */ > + IDirect3DRM_Release(d3drm1); I think it's a good idea to explicitly test the increased refcount after this failing call. > + if (!image > + || !image->rgb > + || !image->red_mask > + || !image->green_mask > + || !image->blue_mask > + || !image->buffer1) > + { > + return FALSE; > + } I guess that there's some way to pass palletized images, e.g. by setting rgb = 0, palette_size != 0 and palette != NULL. This shouldn't be part of this patch though and I am fine with this code as it is. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXL2SsAAoJEN0/YqbEcdMwkCQP/iPRJdsglD3on0uzy9v8iQo9 g0BexNDM4r1AtZASW9yp6dNRLY1oX15dTSM6GjdNlNFGp7jQRVJcJ6X71CJt4EEi oGWtq774F46ewtTjcufP/TOfOed6k6tv/qe6IKRn2rnI7CyusM124jIP4CYZfAlW dk48LOKp9G9kzF3loa6Cx4Eoxmy1jAfXJ5v/ERGqgU/wHwT8Vaim+5URIglfPq0H OUG++D6WTacsh1RWGZaeQqLAVq2zlc5YxNNsgJ7iJcd7DG1EYg6hOFFHebwp5FQP Jq6Dipy1GGB4q+Zt/ygb6HwWsv36taLMVn2erEL2RG6O88QxmM+P3VyxTBNdWKQc 65SHOcq0NjLhT6sO4SSfm5lEsWDBxftzbUuSg9NngrZjmLBa4pfreckYhA+N/p2Y Jd1GBtpvO7w5XTOLYoHWvco2rrRVCmJan/Q/XAensQyFBkkt7+S8Rjjo7KcT1avF Lv7WQqg+2HTHJbiiSp13BsoNZQaDZaDEaINsBv56B+LJjBKf3EwJLCZXpRRN3p0v ByLGPYr7QS3NrukltC9Zb3ZEf2FWBtB8mDBYjh5sHmquujAwlZx85HdaqFEi9ZCb tIzD3O8yO4k5rwM/+fClBLHmeTUEemnG1LrwxgvOR2pAq6/mK67clDmOZJ4CSBBt YjYtXXnjuSBzcnvnvp3J =KSDQ -----END PGP SIGNATURE-----

2 1