September 2017 - Wine-Devel

Re: [2/2] ntdll: Implement RtlUnwind for ARM64
by Stefan Dösinger Sept. 5, 2017

Sept. 5, 2017

Am 2017-09-04 um 20:46 schrieb André Hentschel: > + frame = NtCurrentTeb()->Tib.ExceptionList; > + while ((frame != (EXCEPTION_REGISTRATION_RECORD*)~0UL) && (frame != endframe)) Unless I am blind this handles only x86-style stack handlers, and not the function tables similar to amd64 that are likely to be present as well on arm64. Though I guess because of the lack of arm64 compilers, documentation and binaries from Microsoft we don't really know how Windows (will) handle arm64 exceptions.

1 0

Testing reading and writing of WMF files
by Jefferson Carpenter Sept. 4, 2017

Sept. 4, 2017

I'm trying to imagine what would be a good way to test for the successful processing (reading or writing) of a Windows Media Format file. The WMReader interface has to parse the file correctly. I believe it would be impossible to test for this, without having a natural WMF (.wma, .wmv, or .asf) file to read. There are two ways of getting one: include one in the test suite, or create one as part of the test. The first option has certain disadvantages, such as A) the file size and B) inability to tweak the contents, or easily make a variety of similar files, should the need arise. Also, the WMWriter has to write the file correctly. I see only two ways of testing this: compare the output byte-for-byte with a file generated on a Windows PC, or attempt to read the generated file with a known good wmf implementation. The first way would assume the output is always the same byte-for-byte, which it may not be. For the second, we would need a conforming implementation to use. It seems to me, libav would be quite useful, as it can already decode and encode many if not most of the WMF formats. Do you think it's a valid assumption to make, that libav's codecs are a conforming implementation of the WMF formats? Jefferson Carpenter

1 0

Re: Re: [v5 PATCH] wmvcore/tests: add tests for WMReader methods
by Marvin Sept. 4, 2017

Sept. 4, 2017

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=32942 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: PATCH] user32: Allow activating desktop only when clicked directly
by Fabian Maurer Sept. 2, 2017

Sept. 2, 2017

Hello, just noticed this patch being marked as 'Superseded', but I don't see any new patch addressing this issue. Am I missing something here? Regards, Fabian Maurer

2 2

comctl v6
by Fabian Maurer Sept. 2, 2017

Sept. 2, 2017

Hello wine-devel, While investigating Bug 43643, I learned that comboboxes behave differently when comctl32 v6 is requested by the program. Basically, when v6 is used, all comboboxes display 30 items maximum, regardless of height. This behavior is unimplemented by wine, so affected programs doesn't show any drop down list at all. This would be the correct behavior when not using v6, but it's wrong in this case. We probably need a second combobox class with different behavior (or one class for both behaviors). I don't know too much on how windows implements comboboxes, in wine the comboboxes are implemented in user32, but we probably need to split them between comctl32 v6 and lower. Do you already have plans on how to do that? Especially, how would we do the separation on the source level but still reuse as much code as possible? Is there something that could be done as a start to bring this into the right direction? Regards, Fabian Maurer

1 0

Re: [PATCH] winecfg: Remove processorArchitecture from manifest
by Fabian Maurer Sept. 1, 2017

Sept. 1, 2017

It works with that patch, but maybe we want > processorArchitecture="*" instead? Regards, Fabian Maurer

1 0

Re: [v3 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.
by Marvin Sept. 1, 2017

Sept. 1, 2017

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=32937 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [v3 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.
by Paul Gofman Sept. 1, 2017

Sept. 1, 2017

Please ignore this patch for now (along with the previous version). I have discovered that there is still the case when object_id can be nonzero, but the object is never created (not initialized array of shaders). So we should keep the creation_failed flag probably. I will send the test for null shaders and the new patch version in the next series. On 09/01/2017 01:56 PM, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v3: > - use object_id != 0 as the indication of non-null shader. > --- > dlls/d3dx9_36/effect.c | 45 +++++++++++++++++++++++++++++++++++++++++--- > dlls/d3dx9_36/tests/effect.c | 3 --- > 2 files changed, 42 insertions(+), 6 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 2cd0c22f64..ef772d99b5 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -3941,11 +3941,50 @@ static D3DXHANDLE WINAPI ID3DXEffectImpl_GetCurrentTechnique(ID3DXEffect *iface) > > static HRESULT WINAPI ID3DXEffectImpl_ValidateTechnique(ID3DXEffect* iface, D3DXHANDLE technique) > { > - struct ID3DXEffectImpl *This = impl_from_ID3DXEffect(iface); > + struct ID3DXEffectImpl *effect = impl_from_ID3DXEffect(iface); > + struct d3dx9_base_effect *base = &effect->base_effect; > + struct d3dx_technique *tech = get_valid_technique(base, technique); > + HRESULT ret = D3D_OK; > + unsigned int i, j; > > - FIXME("(%p)->(%p): stub\n", This, technique); > + FIXME("iface %p, technique %p semi-stub.\n", iface, technique); > > - return D3D_OK; > + if (!tech) > + { > + ret = D3DERR_INVALIDCALL; > + goto done; > + } > + for (i = 0; i < tech->pass_count; ++i) > + { > + struct d3dx_pass *pass = &tech->passes[i]; > + > + for (j = 0; j < pass->state_count; ++j) > + { > + struct d3dx_state *state = &pass->states[j]; > + > + if (state_table[state->operation].class == SC_VERTEXSHADER > + || state_table[state->operation].class == SC_PIXELSHADER) > + { > + struct d3dx_parameter *param; > + void *param_value; > + BOOL param_dirty; > + HRESULT hr; > + > + if (FAILED(hr = d3dx9_get_param_value_ptr(pass, &pass->states[j], &param_value, &param, > + FALSE, &param_dirty))) > + return hr; > + > + if (param->object_id && !*(void **)param->data) > + { > + ret = E_FAIL; > + goto done; > + } > + } > + } > + } > +done: > + TRACE("Returning %#x.\n", ret); > + return ret; > } > > static HRESULT WINAPI ID3DXEffectImpl_FindNextValidTechnique(ID3DXEffect* iface, D3DXHANDLE technique, D3DXHANDLE* next_technique) > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index bb26fe4e51..7260411c39 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -7090,10 +7090,8 @@ static void test_effect_unsupported_shader(void) > ok(hr == D3D_OK, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->ValidateTechnique(effect, "missing_technique"); > - todo_wine > ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > hr = effect->lpVtbl->ValidateTechnique(effect, "tech0"); > - todo_wine > ok(hr == E_FAIL, "Got result %#x.\n", hr); > > hr = effect->lpVtbl->ValidateTechnique(effect, "tech1"); > @@ -7101,7 +7099,6 @@ static void test_effect_unsupported_shader(void) > effect->lpVtbl->SetInt(effect, "i", 1); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > hr = effect->lpVtbl->ValidateTechnique(effect, "tech1"); > - todo_wine > ok(hr == E_FAIL, "Got result %#x.\n", hr); > effect->lpVtbl->SetInt(effect, "i", 0); > hr = effect->lpVtbl->ValidateTechnique(effect, "tech1");

1 0

Re: [v2 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.
by Matteo Bruni Sept. 1, 2017

Sept. 1, 2017

2017-08-31 20:56 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + if (!param->object_id || base->objects[param->object_id].creation_failed) It should be possible to replace this with a check for !*(void **)param->data. Unless you mean to use the flag for something else later on?

2 1

Re: [PATCH] d2d1: Partially implement StrokeContainsPoint() for rectangle geometry
by Henri Verbeet Sept. 1, 2017

Sept. 1, 2017

On 31 August 2017 at 14:00, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - if (transform) > - { > - if (!d2d_matrix_invert(&g_i, transform)) > - return D2DERR_UNSUPPORTED_OPERATION; > - d2d_point_transform(&point, &g_i, point.x, point.y); > - } > + if (FAILED(hr = geometry_inv_transform_point(transform, &point))) > + return hr; That's fine in principle, but please do it in a separate commit, and please follow the existing conventions. E.g.: if (transform && FAILED(hr = d2d_point_transform_inverse(&point, transform, point.x, point.y))) return hr; > + stroke_width /= 2.0f; > + > + rect = geometry->u.rectangle.rect; > + rect.left -= stroke_width; > + rect.right += stroke_width; > + rect.top -= stroke_width; > + rect.bottom += stroke_width; > + > + dx = max(fabsf((rect.right + rect.left) / 2.0f - point.x) - (rect.right - rect.left) / 2.0f, 0.0f); > + dy = max(fabsf((rect.bottom + rect.top) / 2.0f - point.y) - (rect.bottom - rect.top) / 2.0f, 0.0f); > + > + if ((*contains = tolerance * tolerance > (dx * dx + dy * dy))) > + { > + rect = geometry->u.rectangle.rect; > + stroke_width += tolerance; > + rect.left += stroke_width; > + rect.right -= stroke_width; > + rect.top += stroke_width; > + rect.bottom -= stroke_width; > + > + *contains = rect.left >= point.x || rect.right <= point.x || rect.top >= point.y || rect.bottom <= point.y; > + } I think that looks a little more complicated than it needs to be. How about: D2D1_POINT_2F d, s; ... s.x = rect.right - rect.left; s.y = rect.bottom - rect.top; d.x = fabsf((rect.right + rect.left) * 0.5f - point.x); d.y = fabsf((rect.bottom + rect.top) * 0.5f - point.y); if (d.x < (s.x - stroke_width) * 0.5f - tolerance && d.y < (s.y - stroke_width) * 0.5f - tolerance) { *contains = FALSE; return S_OK; } d.x = max(d.x - (s.x + stroke_width) * 0.5f, 0.0f); d.y = max(d.y - (s.y + stroke_width) * 0.5f, 0.0f); *contains = (d.x * d.x + d.y * d.y) < tolerance * tolerance; I notice you don't have any tests with transformations, is that intentional? I think you'd need to transform the stroke width with the transformation matrix.

2 1