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

Re: [PATCH 1/8] wined3d: Introduce wined3d_rendertarget_view_clear().
by Henri Verbeet 14 Mar '16

14 Mar '16

On 14 March 2016 at 00:03, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/wined3d/device.c | 18 +----------------- > dlls/wined3d/surface.c | 22 ++-------------------- > dlls/wined3d/view.c | 40 ++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 3 +++ > 4 files changed, 46 insertions(+), 37 deletions(-) > I'm not sure how I feel about this change. There doesn't seem to be a particularly compelling reason to change this, although I suppose there's no strong reason not to either. I guess it depends on where you're going with this.

2 2

Re: [PATCH 2/2] ole32: Fix refcounting of IObjContext per-thread instance
by Huw Davies 14 Mar '16

14 Mar '16

On Mon, Mar 14, 2016 at 08:10:00AM +0300, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/ole32/compobj.c | 57 +++++++++++++++++++--------------------------- > dlls/ole32/tests/compobj.c | 46 ++++++++++++++++++++++--------------- > 2 files changed, 51 insertions(+), 52 deletions(-) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index b095aeb..1081f98 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -4683,10 +4683,13 @@ static ULONG Context_AddRef(Context *This) > > static ULONG Context_Release(Context *This) > { > - ULONG refs = InterlockedDecrement(&This->refs); > - if (!refs) > + if (!This->refs) > + { Since this is non-standard it needs a comment. Probably just referring to the constructor below. > HeapFree(GetProcessHeap(), 0, This); > - return refs; > + return 0; > + } > + > + return InterlockedDecrement(&This->refs); > } > > static HRESULT WINAPI Context_CTI_QueryInterface(IComThreadingInfo *iface, REFIID riid, LPVOID *ppv) > @@ -4924,39 +4927,19 @@ static const IObjContextVtbl Context_Object_Vtbl = > */ > HRESULT WINAPI CoGetObjectContext(REFIID riid, void **ppv) > { > - APARTMENT *apt = COM_CurrentApt(); > - Context *context; > + IObjContext *context; > HRESULT hr; > > TRACE("(%s, %p)\n", debugstr_guid(riid), ppv); > > *ppv = NULL; > - if (!apt) > - { > - if (!(apt = apartment_find_multi_threaded())) > - { > - ERR("apartment not initialised\n"); > - return CO_E_NOTINITIALIZED; > - } > - apartment_release(apt); > - } > - > - context = HeapAlloc(GetProcessHeap(), 0, sizeof(*context)); > - if (!context) > - return E_OUTOFMEMORY; > - > - context->IComThreadingInfo_iface.lpVtbl = &Context_Threading_Vtbl; > - context->IContextCallback_iface.lpVtbl = &Context_Callback_Vtbl; > - context->IObjContext_iface.lpVtbl = &Context_Object_Vtbl; > - context->refs = 1; > - > - hr = IComThreadingInfo_QueryInterface(&context->IComThreadingInfo_iface, riid, ppv); > - IComThreadingInfo_Release(&context->IComThreadingInfo_iface); > + hr = CoGetContextToken((ULONG_PTR*)&context); > + if (FAILED(hr)) > + return hr; > > - return hr; > + return IObjContext_QueryInterface(context, riid, ppv); > } > > - > /*********************************************************************** > * CoGetContextToken [OLE32.@] > */ > @@ -4985,16 +4968,22 @@ HRESULT WINAPI CoGetContextToken( ULONG_PTR *token ) > > if (!info->context_token) > { > - HRESULT hr; > - IObjContext *ctx; > + Context *context; > + > + context = HeapAlloc(GetProcessHeap(), 0, sizeof(*context)); > + if (!context) > + return E_OUTOFMEMORY; > + > + context->IComThreadingInfo_iface.lpVtbl = &Context_Threading_Vtbl; > + context->IContextCallback_iface.lpVtbl = &Context_Callback_Vtbl; > + context->IObjContext_iface.lpVtbl = &Context_Object_Vtbl; Add a comment here stating that context_token does not take a ref. > + context->refs = 0; > > - hr = CoGetObjectContext(&IID_IObjContext, (void **)&ctx); > - if (FAILED(hr)) return hr; > - info->context_token = ctx; > + info->context_token = &context->IObjContext_iface; > } > > *token = (ULONG_PTR)info->context_token; > - TRACE("apt->context_token=%p\n", info->context_token); > + TRACE("context_token=%p\n", info->context_token); > > return S_OK; > } I'm wondering whether this patch could be split since it's doing rather more than fixing a ref counting issue. Could you move the constructor to CoGetContextToken first and then fix the refs, or would that mess up the tests? Huw.

2 2

Re: [PATCH 6/8] d3d10core/tests: Add test for ClearDepthStencilView().
by Henri Verbeet 14 Mar '16

14 Mar '16

On 14 March 2016 at 00:03, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static float get_readback_float(struct texture_readback *rb, unsigned int x, unsigned int y) > +{ > + return rb->texture > + ? ((float *)rb->mapped_texture.pData)[rb->mapped_texture.RowPitch * y / sizeof(float) + x] : NAN; > +} Can the texture ever legitimately be NULL?

2 1

Re: [PATCH 2/8] wined3d: Implement depth clear in wined3d_device_clear_rendertarget_view().
by Henri Verbeet 14 Mar '16

14 Mar '16

On 14 March 2016 at 00:03, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -4100,7 +4110,13 @@ HRESULT CDECL wined3d_device_clear_rendertarget_view(struct wined3d_device *devi > rect = &r; > } > > - return wined3d_rendertarget_view_clear(view, rect, WINED3DCLEAR_TARGET, color, 0.0f, 0); > + if (!(flags & WINED3DCLEAR_TARGET) == !(flags & (WINED3DCLEAR_ZBUFFER | WINED3DCLEAR_STENCIL))) > + { > + ERR("Color and depth/stencil clears are mutually exclusive.\n"); > + return WINED3DERR_INVALIDCALL; > + } You may not need this. The documentation suggests depth/stencil views can only be created on depth formats, and I'd be inclined to believe it. IIRC it doesn't say much about creating rendertarget views on depth/stencil formats, but I wouldn't be all that surprised if that's not allowed either. In that case you'd just need to check the flags against the format capabilities. > +const char *debug_color(const struct wined3d_color *color) > +{ > + if (!color) > + return "(null)"; > + return wine_dbg_sprintf("{%.8e, %.8e, %.8e, %.8e}", > + color->r, color->g, color->b, color->a); > +} This is fine, but might as well be a separate change. There are a couple of other places where we trace wined3d_color values as well, the easiest way to find them is probably to look for the format string.

2 1

Re: d3drm: Use debugstr_a to print a string that can be NULL.
by Henri Verbeet 14 Mar '16

14 Mar '16

On 14 March 2016 at 10:36, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > - TRACE("Mesh name is '%s'\n", This->name ? This->name : ""); > + TRACE("Mesh name is '%s'\n", debugstr_a(This->name)); You should remove the quotes, since debugstr_a() also adds quotes. Note that just being external data is enough reason to use debugstr_a(), it doesn't matter much if it can be NULL or not in that regard.

2 1

Re: [PATCH] Read operation's type explicitly as QStringList
by Nikolay Sivov 14 Mar '16

14 Mar '16

On 13.03.2016 19:12, Łukasz Wojniłowicz wrote: > Fixes bug #360129 > --- > kmymoney/plugins/csvimport/investprocessing.cpp | 22 ++++++++-------------- > 1 file changed, 8 insertions(+), 14 deletions(-) > Hi, Łukasz. Just pointing out so this patch is not lost by accident - wrong mailing list. You aimed for https://mail.kde.org/pipermail/kmymoney-devel/ probably or some list next to it.

1 0

Re: [PATCH] kernel32/tests: Skip ResolveDelayLoadedAPI tests on Win10+
by Nikolay Sivov 13 Mar '16

13 Mar '16

On 13.03.2016 19:42, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/kernel32/tests/loader.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/dlls/kernel32/tests/loader.c b/dlls/kernel32/tests/loader.c > index c35cf25..30cc2e4 100644 > --- a/dlls/kernel32/tests/loader.c > +++ b/dlls/kernel32/tests/loader.c > @@ -2728,6 +2728,11 @@ static void test_ResolveDelayLoadedAPI(void) > > cb_count = 0; > ret = pResolveDelayLoadedAPI(hlib, delaydir, failuredllhook, NULL, &itda[i], 0); > + if (!ret && td[i].succeeds) > + { > + win_skip("Skipping broken ResolveDelayLoadedAPI implementation\n"); > + goto cleanup; > + } > if (td[i].succeeds) > { > ok(ret != NULL, "Test %u: ResolveDelayLoadedAPI failed\n", i); > @@ -2745,6 +2750,7 @@ static void test_ResolveDelayLoadedAPI(void) > delaydir++; > } > > +cleanup: > FreeLibrary(hlib); > trace("deleting %s\n", dll_name); > DeleteFileA(dll_name); > So what's exactly wrong with it on Win10? Silencing failures does not seem useful if actual issue was not investigated.

1 0

Re: [PATCH] d3d9/tests Accept Windows 10 result
by Stefan Dösinger 13 Mar '16

13 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-03-13 um 17:04 schrieb Detlef Riekenberg: > Windows 10 is returning D3D_OK, so the recent behavior seems to be > better as before. That's why I used D3D_OK as expected result, > marked the old S_PRESENT_MODE_CHANGED as broken and removed the > wine_todo I think the new behavior is more broken than the old one. "It needs a present call to pick up a mode change" - If my memory serves me right the issue was that CheckDeviceState would incorrectly return D3D_OK instead of S_PRESENT_MODE_CHANGED when the mode was changed. Now it's always wrong, even with a preceding Present call. Of course in light of the Windows 10 results we may have to redefine "wrong". -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW5aMEAAoJEN0/YqbEcdMweH8P/2OQymbb9EhNw4YqaXw0lcVN ozmH/7MYrxM4V1zzk+1+7XBR7nlIwDFRBGYw6LaZCiCmJYDfb1CTpYbSoVokHzQo UW2aCJCVRNWnZ5L72aZ12AoFq5sIuUX0FCAWhnpT4rNU7/bv35T/Zz0h439vn4RN +USZIHayRpmsJbhSbSn9VejSyin7GhBZ3VD7Qcd+7MqBxqOATX5p62cgFg+KUPkN Wi1HelDEHNsybHE4U60zYcZ2uxZxh7alfP6FjOtffOOxYilmG5eGEpGQX/dRIIv7 wxAfkjy/lgZqV9T4kEVyVO4tiwf9Vj1ccijkBNOttP7cFNGA4IM5W/urSWxL0uPd QEzP3QUv03NPN9Mtgq7K+DOyZmMUeedU+dHcCTwPJj/GTuXGxs2KHpLURXiAWXjD they7Iog2TEBFWuDskx58RHJyevbzKfWqfeM6/nJew5ter19W62Y1Sn01hfI0Ym0 aaTdzj+/tnf5pdc5Mgu6AtSRbApziwtYdfn4xGyEImw7J4pu7BnSmzHk8FMowtHm Dy2+GKE0FlmpAExwo0FAY2z6fCvMtIQMYzinU95LYaWvIggjsUo3wII3PxLtjKY0 8gXqBk+6WUUeDrAKqRqdkMCdzLBsVrlmxlj37KhfmPNCvG9gAlnMRegNW9eZkE2F aqvHGFSUrJzmk9CPtwtt =+25F -----END PGP SIGNATURE-----

1 0

Re: [PATCH] kernel32/tests: Skip ResolveDelayLoadedAPI tests on Win10+
by Marvin 13 Mar '16

13 Mar '16

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=21399 Your paranoid android. === w864 (32 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w1064 (32 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w864 (64 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w1064 (64 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195

1 0

Builtin DLL View
by Keno Fischer 12 Mar '16

12 Mar '16

Hello everyone, out of curiosity, I was tracking down why a piece of code in julia [1] threw an assertion when running under wine, but not on windows proper. The problem in this piece of code turned out to be that VirtualQuery is claiming a region of memory is free, when it is actually occupied by part of one of the builtin dlls. If I understand correctly what's happening here is that builtin dlls are regular shared objects on the host system, and get loaded as such, but contain the respective windows dll inside of them (modulo header, which gets created in `map_dll` by mapping over a couple of pages in the middle). Later, after going through the load callback, `virtual_create_builtin_view` records the appropriate information in the view map. However, it only records what it knows about the inner dll, not the shared object wrapper around it. I was thinking of preparing a patch, but I am not sure how to go about it. Options I could see: - Expand the mapping in `virtual_create_builtin_view`. This seems most straightforward, but I don't quite know what the proper way to pass this information through to here is. Or maybe we can parse the wrapper's header right in the function, if we assume that it's base will always be 64K before the PE header base? - Unmap the parts of the shared library that do not constitute the inner dll. I would imagine that at some point wine stops relying on the native dynamic linker, at which point it would probably be safe to just unmap the extra pages such that view agrees with what is actually mapped. I'd be happy to put together a patch, but I'll need some guidance on how best to do this, since I haven't looked at the Wine codebase before today. [1] https://github.com/JuliaLang/julia/blob/01dd5ec0b25fc5fa8cf1fbae6bb00ef5874…

1 0