April 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] d3drm/tests: Replace test_Texture.

by Aaryaman Vasishta

On Sun, Apr 24, 2016 at 3:43 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-04-24 um 06:40 schrieb Aaryaman Vasishta: > > + size = 1; > > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > > + ok(hr == E_INVALIDARG, "GetClassName failed with %x\n", hr); > > + size = sizeof(cname); > > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > > + ok(SUCCEEDED(hr), "Cannot get classname (hr = %x)\n", hr); > > + ok(size == sizeof("Texture"), "wrong size: %u\n", size); > sizeof("Texture") is confusing IMHO. I had to look up the C rules on > string literals to make sure it does what you want :-) . Though I'm not > sure if its better than strlen("Texture") + 1, so it's your call. > > However, the current implementation in d3drm_texture3_GetClassName > confuses the two. I recommend adding a test for sizeof("Texture") - 1 > and an exactly matching size. > > I hadn't really paid attention to that since the plan was to just extend the existing tests to version 2 and 3. But I will add these tests as you want. By exactly matching size, did you mean sizeof("Texture") itself? Isn't that already there? I might have missed something here. Cheers, Aaryaman

April 24, 2016

Re: [PATCH 3/3] d3drm/tests: Add tests for IDirect3DRMTexture{2-3}_InitFromImage. (v2)

by Aaryaman Vasishta

On Sun, Apr 24, 2016 at 3:39 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I think it'd be a good idea to add some lines testing InitFromImage on > a texture that was created with CreateTexture and trying to call > InitFromImage twice (with the first call succeeding). > > Am 2016-04-24 um 06:46 schrieb Aaryaman Vasishta: > > + /* InitFromImage tests */ > > + d3drm_img = NULL; > > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMTexture, > NULL, &IID_IDirect3DRMTexture2, (void **)&texture2); > > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture2 interface (hr = > %x).\n", hr); > > + ref2 = get_refcount((IUnknown *)texture2); > Did you forget IDirect3DRM::CreateObject(Texture1), or is there a > reason why it is omitted? > InitFromImage only exists for versions 2 and 3, so the tests for that were added accordingly, there wasn't any need for a CreateObject(Texture1) in this case. > > > + hr = IDirect3DRMTexture2_InitFromImage(texture2, NULL); > > + todo_wine ok(hr == D3DRMERR_BADOBJECT, "Expected hr == > D3DRMERR_BADOBJECT, got %x.\n", hr); > > + ref3 = get_refcount((IUnknown *)texture2); > > + ok(ref3 == ref2, "expected ref3 == ref2, got ref2 = %u , ref3 = > %u.\n", ref2, ref3); > You're not testing the reference count of d3drm1/2/3. My guess is that > you plan to add this later since the InitFrom() increments it, and not > the create. Is my understanding of your plans correct? > No you're right, I should've added refcount tests for d3drm1/2/3 as well. Even though InitFrom* is not implemented at this point, it's still a good idea to keep them as todo's and removing them when I send the implementation for InitFromImage. What do you think? InitFrom* does increment the refcount, whereas CreateObject doesn't seem to. I think it was meant to be like that as every object creatable by CreateObject has a corresponding init method, which I guess increments the refcount when called. I will resend this patch with the changes. Cheers, Aaryaman

April 24, 2016

Re: [PATCH 2/3] d3drm/tests: Replace test_Texture.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-04-24 um 06:40 schrieb Aaryaman Vasishta: > + size = 1; > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > + ok(hr == E_INVALIDARG, "GetClassName failed with %x\n", hr); > + size = sizeof(cname); > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > + ok(SUCCEEDED(hr), "Cannot get classname (hr = %x)\n", hr); > + ok(size == sizeof("Texture"), "wrong size: %u\n", size); sizeof("Texture") is confusing IMHO. I had to look up the C rules on string literals to make sure it does what you want :-) . Though I'm not sure if its better than strlen("Texture") + 1, so it's your call. However, the current implementation in d3drm_texture3_GetClassName confuses the two. I recommend adding a test for sizeof("Texture") - 1 and an exactly matching size. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXHJxZAAoJEN0/YqbEcdMwMAkP/0JEXejefj/awhnJGh5zQlg9 07gvcDjH+KvsHYbJsWOA8GE3+JcUJrqpHA8nqO2Uxmy1mg26EECNtRFTjfWJ4oQM iHcVgVurTb6rx6UZpcLkoy/BQ4fvWQFtWxfL2J9ZDO2TVt+0oeGSurkv5ywylTmq 5RZa5lFhnaeMyWw6hbtXNwsPXMhi+tDdHZTYVakJGRa72deO23ZrWuzbHzMfnlDx /SnGnSnFF9JcWLkLQMqeiQ+Q2Ztn+PHo15EjAye3hk1gvVYKx5xx7+Hef9l4/1dG Cqc2I+4GwE86FmrBkqT1noF6HDo4+6evHi+JrW6d0WFH7I/k3D+5SUtaqtBRtraC AuS4Kwsqri4wpVeqz6zsX8BsneQHQzkB87EXEC81d7W6fTPAYT1YoQp2zDPxP32G lIwd3bxtdyYA91dNTCGx8arKEpBXhuKqh0ahI8FrRBiuZ20JVIvosiVBxpWHYsiV 9X3smnaiYrL6sZTPtbcHbcs5shbuycpzm05EB5noSbc+P6ur5/q4Q9nSH86OYAIr mJBZWg6pE9N1zcko6KTmB//z7NGYms8knxVQYGVgtRgZaNk8+mVaeedgdbnrIMFj xsdTX8UGtOAs7mJ6E496xq4P7bMxK5B0BSoChtaJV3ZeS9wLD/JId/1Z7l/DvVwn 0EDb2DPmwv7EbEWz7cAH =MI19 -----END PGP SIGNATURE-----

April 24, 2016

Re: [PATCH 3/3] d3drm/tests: Add tests for IDirect3DRMTexture{2-3}_InitFromImage. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I think it'd be a good idea to add some lines testing InitFromImage on a texture that was created with CreateTexture and trying to call InitFromImage twice (with the first call succeeding). Am 2016-04-24 um 06:46 schrieb Aaryaman Vasishta: > + /* InitFromImage tests */ > + d3drm_img = NULL; > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture2, (void **)&texture2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture2 interface (hr = %x).\n", hr); > + ref2 = get_refcount((IUnknown *)texture2); Did you forget IDirect3DRM::CreateObject(Texture1), or is there a reason why it is omitted? > + hr = IDirect3DRMTexture2_InitFromImage(texture2, NULL); > + todo_wine ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %x.\n", hr); > + ref3 = get_refcount((IUnknown *)texture2); > + ok(ref3 == ref2, "expected ref3 == ref2, got ref2 = %u , ref3 = %u.\n", ref2, ref3); You're not testing the reference count of d3drm1/2/3. My guess is that you plan to add this later since the InitFrom() increments it, and not the create. Is my understanding of your plans correct? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXHJtCAAoJEN0/YqbEcdMwAhgQAJXR10NMu88OEslWcX2iUSSg rUXk7WcCaQVHHlGFwQwddtFLrX245idLScYxm8N9CvG3kyHxx91tQ3UH6wT+QHAv No6IuMc0menrh1g2mP08/Ci44sd7Hy01HS7K8A9+/rdwUnIhb3pYiAxB8673/7he ruXnPpYY/Mhi+8I1BAQA17qy5rArUFQWHGoth+18PnPdI9VELKlkZg0Y8R/ITqdu jgLkw1zKsKZS17qvwTyz+lyxmhC2mAjIMQu/WD/lVZOwXPTFUmSqPfUke6nyTFfA ffJL16e9C5CpyD+dCT+Rc3AUoboBo+JrQz4Qif4xOW+LhNY7fZeqt4f1Pd7+Zxqe X3sr7jVDTJY3d//bWy7eW1Ow7zixawhsWXa0cj6Z6TuIV4ruMvOK6QpZ2qb1IvmS BCTGoRI6DYF6bRDZLCirbz4nOB8CNTtO+erLhh5uHCP8wtN1eYC3/5rSjGjJACrT IBQ7g/l45/oiCkmVLug5kxUqgXXX0GoVbrod0MiBd0snDMwmev1T+xNHFdsfR9La 8AKBVF6eH3FqRo0Co6PGIvgKkk0ItuAUBPFkrvaREnzTwQO5XrSbCA54FeM8YFn3 FZH9ePNGENyWJD98SI1Laluw/9GiAusQynkJALSen9Aqm1pfhfH2OSuxaFqg0IfW vl8vPREqFJGtCGx9fQU/ =FjQh -----END PGP SIGNATURE-----

April 24, 2016

Re: Experimental 64 bit OS X packages ready for testing

by Diego Vicioso

Any updates if it will be included into normal wine or future wine staging packages? Sent from my mac

April 23, 2016

Re: shell32/tests: Tests for broken apps that check GetLastError() after SHFileOperation()

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=22483 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 shlfileop.c:2455: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2464: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2468: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2471: Test failed: does not end with .lnk shlfileop.c:83: Test failed: Failure to open file shlfileop.c:2477: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2481: Test failed: Y does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2484: Test failed: Y does not end with .lnk === wvistau64 (64 bit shlfileop) === shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 shlfileop.c:2455: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2464: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2468: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2471: Test failed: does not end with .lnk shlfileop.c:83: Test failed: Failure to open file shlfileop.c:2477: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2481: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2484: Test failed: does not end with .lnk shlfileop.c:2486: Test failed: and are the same

April 23, 2016

Re: Wine inside Xephyr on OSX

by Bruno Jesus

On Sat, Apr 23, 2016 at 1:17 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Apr 23, 2016, at 4:59 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> It could also be a library path issue. The easiest way to work around >> it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should >> be actual OS X users on this list with more experience there. > > Yes, but it's potentially complicated. > > First, are you using XQuartz or another build of X.org (for example, from MacPorts)? You'd presumably want to point the library path to the libraries of the one you're using. > > I generally use XQuartz, so I do: > > export DYLD_FALLBACK_LIBRARY_PATH=/opt/X11/lib:/usr/lib > > The next question is whether you're running OS X 10.11 (El Capitan). If so, its System Integrity Protection feature will make a nuisance of itself. For security, it strips all DYLD_* variables from the environment when you run a "protected" executable. All system executables are protected, including the shell interpreters. If you are invoking a shell script such as the "wine" script for running Wine from the build tree, then that variable will be stripped. For that particular case, you can put the export command into a .winewrapper file to have it sourced by the shell, which will work. For other cases, you may need to edit your script. Thanks you both, using the export worked as expected, and yes this is XQuartz (installed from brew I guess, the computer is not mine). It is running Yosemite so it was not a problem.

April 23, 2016

Re: Fix a heap corruption when printing specific REG_MULTI_SZ values.

by Sebastian Lackner

On 23.04.2016 11:56, Hugh McMaster wrote: > On Saturday, 23 April 2016 3:35 AM, Sebastian Lackner wrote: > >> The current calculation does not take the terminating \0 into account. > >> -buffer = HeapAlloc(GetProcessHeap(), 0, tmp_size * 2); >> +buffer = HeapAlloc(GetProcessHeap(), 0, tmp_size * 2 + sizeof(WCHAR)); > > Which particular cases cause the heap corruption? > > -- > Hugh McMaster > It happens for example with a string like L"\0\0\0\0". After stripping off the last two "\0" the allocated memory will have a size of 4 characters, but the code below writes 5 characters. You can also test with warn+heap after creating such a registry key.

April 23, 2016

Re: Wine inside Xephyr on OSX

by Ken Thomases

On Apr 23, 2016, at 4:59 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > On 23 April 2016 at 11:51, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> err:x11drv:process_attach failed to load libX11.6.dylib: >> dlopen(libX11.6.dylib, 266): image not found >> err:winediag:nulldrv_CreateWindow Application tried to create a >> window, but no driver could be loaded. >> err:winediag:nulldrv_CreateWindow Make sure that your X server is >> running and that $DISPLAY is set correctly. >> >> This is without setting DISPLAY. Clearly it is a missing dependency >> that I have to install, but the main issue was this x11/winemac >> difference, thanks. > It could also be a library path issue. The easiest way to work around > it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should > be actual OS X users on this list with more experience there. Yes, but it's potentially complicated. First, are you using XQuartz or another build of X.org (for example, from MacPorts)? You'd presumably want to point the library path to the libraries of the one you're using. I generally use XQuartz, so I do: export DYLD_FALLBACK_LIBRARY_PATH=/opt/X11/lib:/usr/lib The next question is whether you're running OS X 10.11 (El Capitan). If so, its System Integrity Protection feature will make a nuisance of itself. For security, it strips all DYLD_* variables from the environment when you run a "protected" executable. All system executables are protected, including the shell interpreters. If you are invoking a shell script such as the "wine" script for running Wine from the build tree, then that variable will be stripped. For that particular case, you can put the export command into a .winewrapper file to have it sourced by the shell, which will work. For other cases, you may need to edit your script. -Ken

April 23, 2016

Re: Wine inside Xephyr on OSX

by Henri Verbeet

On 23 April 2016 at 11:51, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > err:x11drv:process_attach failed to load libX11.6.dylib: > dlopen(libX11.6.dylib, 266): image not found > err:winediag:nulldrv_CreateWindow Application tried to create a > window, but no driver could be loaded. > err:winediag:nulldrv_CreateWindow Make sure that your X server is > running and that $DISPLAY is set correctly. > > This is without setting DISPLAY. Clearly it is a missing dependency > that I have to install, but the main issue was this x11/winemac > difference, thanks. It could also be a library path issue. The easiest way to work around it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should be actual OS X users on this list with more experience there.

April 23, 2016