August 2017 - Wine-Devel - list.winehq.org

Re: [v2 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.

by Matteo Bruni

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?

Aug. 31, 2017

Re: [PATCH] d2d1: Partially implement StrokeContainsPoint() for rectangle geometry

by Henri Verbeet

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.

Aug. 31, 2017

Re: [PATCH 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.

by Paul Gofman

On 08/31/2017 09:32 PM, Matteo Bruni wrote: > 2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > >> 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); > Do you know what else is missing for ValidateTechnique()? > Replying to myself: the return values mentioned in > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205835(v=vs.85).… > give some ideas (although E_FAIL is not in the list, figures...) > > I did not test it thoroughly, but also viewed a long list of possible specific return values in MSDN. And yes, ironically, it does not list any special return value for incompatible shader, and returns E_FAIL which is not listed, while I suppose it might be the most common case in practice when application can depend on ValidateTechnique().

Aug. 31, 2017

Re: [PATCH 1/3] d3dx9/tests: Add test for effect with unsupported shader.

by Matteo Bruni

2017-08-31 20:35 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 08/31/2017 09:25 PM, Matteo Bruni wrote: >> >> 2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >>> >>> + ok(!memcmp(byte_code, >>> + >>> &test_effect_unsupported_shader_blob[TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS], >>> + byte_code_size), "Incorrect shader selected.\n"); >> >> I was confused by this at first, I thought somehow the unsupported >> vs_3_sw shader was set. That's not the case, >> TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS is the position of the >> vs_3_0 shader, but the naming throw me off. >> Can you rename those defines to "BYTECODE_VS_3_0_POS" or something >> that makes it clear that it refers to the hardware shader in >> vs_arr[0]? >> >> > Yes, sure, I will rename that. I just spotted I have the bytecode with > 0x0300 version for unsupported shader (not 0x03ff as it should be for > vs_3_sw as in effect source in #if 0), sorry for that. I tested both ways, > the result is the same (either way it is not supported with hardware vertex > processing), but apparently I kept wrong source for effect. I will recompile > the code to match vs_3_sw (for easier spotting that shader in the blob). Ah, good to know. Actually I was about to test whether vs_3_sw really made no difference in the generated bytecode. Your d3d9 tests made it clear that the version (sw vs hw) doesn't really matter so this d3dx9 behavior isn't quite as surprising.

Aug. 31, 2017

Re: [PATCH 1/3] d3dx9/tests: Add test for effect with unsupported shader.

by Paul Gofman

On 08/31/2017 09:25 PM, Matteo Bruni wrote: > 2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> + ok(!memcmp(byte_code, >> + &test_effect_unsupported_shader_blob[TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS], >> + byte_code_size), "Incorrect shader selected.\n"); > I was confused by this at first, I thought somehow the unsupported > vs_3_sw shader was set. That's not the case, > TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS is the position of the > vs_3_0 shader, but the naming throw me off. > Can you rename those defines to "BYTECODE_VS_3_0_POS" or something > that makes it clear that it refers to the hardware shader in > vs_arr[0]? > > Yes, sure, I will rename that. I just spotted I have the bytecode with 0x0300 version for unsupported shader (not 0x03ff as it should be for vs_3_sw as in effect source in #if 0), sorry for that. I tested both ways, the result is the same (either way it is not supported with hardware vertex processing), but apparently I kept wrong source for effect. I will recompile the code to match vs_3_sw (for easier spotting that shader in the blob).

Aug. 31, 2017

Re: [PATCH 3/3] d3dx9: Return E_FAIL from ValidateTechnique() for techniques with unsupported shaders.

by Matteo Bruni

2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > 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); Do you know what else is missing for ValidateTechnique()? Replying to myself: the return values mentioned in https://msdn.microsoft.com/en-us/library/windows/desktop/bb205835(v=vs.85).… give some ideas (although E_FAIL is not in the list, figures...)

Aug. 31, 2017

Re: [PATCH 1/3] d3dx9/tests: Add test for effect with unsupported shader.

by Matteo Bruni

2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 185 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 185 insertions(+) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 9658d2dc82..3e8df11d24 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -6981,6 +6981,190 @@ static void test_effect_skip_constants(IDirect3DDevice9 *device) > effect->lpVtbl->Release(effect); > } > > +#if 0 > +vertexshader vs_arr[2] = > +{ > + asm > + { > + vs_3_0 > + def c0, 1, 1, 1, 1 > + dcl_position o0 > + mov o0, c0 > + }, > + > + asm > + { > + vs_3_sw > + def c256, 1, 1, 1, 1 > + dcl_position o0 > + mov o0, c256 > + }, > +}; > + > +int i; > + > +technique tech0 > +{ > + pass p0 > + { > + VertexShader = vs_arr[1]; > + } > +} > +technique tech1 > +{ > + pass p0 > + { > + VertexShader = vs_arr[i]; > + } > +} > +#endif > +static const DWORD test_effect_unsupported_shader_blob[] = > +{ > + 0xfeff0901, 0x000000ac, 0x00000000, 0x00000010, 0x00000004, 0x00000020, 0x00000000, 0x00000002, > + 0x00000001, 0x00000002, 0x00000007, 0x615f7376, 0x00007272, 0x00000002, 0x00000000, 0x0000004c, > + 0x00000000, 0x00000000, 0x00000001, 0x00000001, 0x00000000, 0x00000002, 0x00000069, 0x00000003, > + 0x00000010, 0x00000004, 0x00000000, 0x00000000, 0x00000000, 0x00000003, 0x00003070, 0x00000006, > + 0x68636574, 0x00000030, 0x00000004, 0x00000010, 0x00000004, 0x00000000, 0x00000000, 0x00000000, > + 0x00000003, 0x00003070, 0x00000006, 0x68636574, 0x00000031, 0x00000002, 0x00000002, 0x00000006, > + 0x00000005, 0x00000004, 0x00000018, 0x00000000, 0x00000000, 0x0000002c, 0x00000048, 0x00000000, > + 0x00000000, 0x00000074, 0x00000000, 0x00000001, 0x0000006c, 0x00000000, 0x00000001, 0x00000092, > + 0x00000000, 0x00000058, 0x00000054, 0x000000a0, 0x00000000, 0x00000001, 0x00000098, 0x00000000, > + 0x00000001, 0x00000092, 0x00000000, 0x00000084, 0x00000080, 0x00000002, 0x00000002, 0x00000001, > + 0x00000038, 0xfffe0300, 0x05000051, 0xa00f0000, 0x3f800000, 0x3f800000, 0x3f800000, 0x3f800000, > + 0x0200001f, 0x80000000, 0xe00f0000, 0x02000001, 0xe00f0000, 0xa0e40000, 0x0000ffff, 0x00000002, > + 0x00000038, 0xfffe0300, 0x05000051, 0xa00f0100, 0x3f800000, 0x3f800000, 0x3f800000, 0x3f800000, > + 0x0200001f, 0x80000000, 0xe00f0000, 0x02000001, 0xe00f0000, 0xa0e40100, 0x0000ffff, 0x00000001, > + 0x00000000, 0xffffffff, 0x00000000, 0x00000002, 0x000000e4, 0x00000008, 0x615f7376, 0x00007272, > + 0x46580200, 0x0023fffe, 0x42415443, 0x0000001c, 0x00000057, 0x46580200, 0x00000001, 0x0000001c, > + 0x00000100, 0x00000054, 0x00000030, 0x00000002, 0x00000001, 0x00000034, 0x00000044, 0xabab0069, > + 0x00020000, 0x00010001, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, > + 0x4d007874, 0x6f726369, 0x74666f73, 0x29522820, 0x534c4820, 0x6853204c, 0x72656461, 0x6d6f4320, > + 0x656c6970, 0x2e392072, 0x392e3932, 0x332e3235, 0x00313131, 0x0002fffe, 0x54494c43, 0x00000000, > + 0x000cfffe, 0x434c5846, 0x00000001, 0x10000001, 0x00000001, 0x00000000, 0x00000002, 0x00000000, > + 0x00000000, 0x00000004, 0x00000000, 0xf0f0f0f0, 0x0f0f0f0f, 0x0000ffff, 0x00000000, 0x00000000, > + 0xffffffff, 0x00000000, 0x00000001, 0x0000000a, 0x615f7376, 0x315b7272, 0x0000005d, > +}; > + > +#define TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS 81 > +#define TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_LEN 14 > + > +static void test_effect_unsupported_shader(void) > +{ > + D3DPRESENT_PARAMETERS present_parameters = {0}; > + IDirect3DVertexShader9 *vshader; > + unsigned int passes_count; > + IDirect3DDevice9 *device; > + UINT byte_code_size; > + ID3DXEffect *effect; > + IDirect3D9 *d3d; > + void *byte_code; > + ULONG refcount; > + HWND window; > + HRESULT hr; > + > + if (!(window = CreateWindowA("static", "d3dx9_test", WS_OVERLAPPEDWINDOW, 0, 0, > + 640, 480, NULL, NULL, NULL, NULL))) > + { > + skip("Couldn't create application window\n"); > + return; > + } > + if (!(d3d = Direct3DCreate9(D3D_SDK_VERSION))) > + { > + skip("Couldn't create IDirect3D9 object\n"); > + DestroyWindow(window); > + return; > + } > + present_parameters.Windowed = TRUE; > + present_parameters.SwapEffect = D3DSWAPEFFECT_DISCARD; > + hr = IDirect3D9_CreateDevice(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, window, > + D3DCREATE_HARDWARE_VERTEXPROCESSING, &present_parameters, &device); > + if (FAILED(hr)) { > + skip("Failed to create IDirect3DDevice9 object, hr %#x\n", hr); > + IDirect3D9_Release(d3d); > + DestroyWindow(window); > + return; > + } > + > + hr = D3DXCreateEffectEx(device, test_effect_unsupported_shader_blob, sizeof(test_effect_unsupported_shader_blob), > + NULL, NULL, NULL, 0, NULL, &effect, NULL); > + todo_wine > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + if (FAILED(hr)) > + { > + skip("Failed to create effect, skipping test.\n"); > + goto cleanup; > + } > + > + hr = effect->lpVtbl->ValidateTechnique(effect, "missing_technique"); > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->ValidateTechnique(effect, "tech0"); > + ok(hr == E_FAIL, "Got result %#x.\n", hr); > + > + hr = effect->lpVtbl->ValidateTechnique(effect, "tech1"); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + effect->lpVtbl->SetInt(effect, "i", 1); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->ValidateTechnique(effect, "tech1"); > + ok(hr == E_FAIL, "Got result %#x.\n", hr); > + effect->lpVtbl->SetInt(effect, "i", 0); > + hr = effect->lpVtbl->ValidateTechnique(effect, "tech1"); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = effect->lpVtbl->SetTechnique(effect, "tech0"); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->Begin(effect, &passes_count, 0); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->BeginPass(effect, 0); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = IDirect3DDevice9_GetVertexShader(device, &vshader); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > + ok(!vshader, "Got non NULL vshader.\n"); > + > + hr = effect->lpVtbl->EndPass(effect); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->End(effect); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = effect->lpVtbl->SetTechnique(effect, "tech1"); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->Begin(effect, &passes_count, 0); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = effect->lpVtbl->BeginPass(effect, 0); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = IDirect3DDevice9_GetVertexShader(device, &vshader); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > + ok(!!vshader, "Got NULL vshader.\n"); > + hr = IDirect3DVertexShader9_GetFunction(vshader, NULL, &byte_code_size); > + ok(hr == D3D_OK, "Got result %x.\n", hr); > + byte_code = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, byte_code_size); > + hr = IDirect3DVertexShader9_GetFunction(vshader, byte_code, &byte_code_size); > + ok(hr == D3D_OK, "Got result %x.\n", hr); > + ok(byte_code_size == TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_LEN * sizeof(DWORD), > + "Got unexpected byte code size %u.\n", byte_code_size); > + ok(!memcmp(byte_code, > + &test_effect_unsupported_shader_blob[TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS], > + byte_code_size), "Incorrect shader selected.\n"); I was confused by this at first, I thought somehow the unsupported vs_3_sw shader was set. That's not the case, TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS is the position of the vs_3_0 shader, but the naming throw me off. Can you rename those defines to "BYTECODE_VS_3_0_POS" or something that makes it clear that it refers to the hardware shader in vs_arr[0]?

Aug. 31, 2017

Wine packaged as appImage?

by Mikhail V.

Hello, following Bob Wya's suggestion in this forum post: https://forum.winehq.org/viewtopic.php?f=8&t=28708 I would like to ask: are there any plans to package Wine as appImage? if this question was already asked (and answered) in this mailing list then it would be nice to make such answer public (fin aforementioned forum topic maybe?) so that people like me would not pollute this mailing list by asking it again :) Thanks, Mikhail

Aug. 31, 2017

Re: [PATCH v2 10/11] progman: Use proper size for combobox controls

by Fabian Maurer

> > -COMBOBOX PM_TO_GROUP, 5, 38, 140, > > 50, WS_TABSTOP | CBS_DROPDOWNLIST +COMBOBOX > > PM_TO_GROUP, 5, 38, 140, 60, WS_TABSTOP | CBS_DROPDOWNLIST > That kind of change doesn't seem necessary. We don't need all comboboxes > to have the exact same height, only something reasonable. Well, my intention was to keep the size the same as it was before my patch. Wine used to make comboboxes at least 5 items in height, that was the broken behavior, and since I didn't want to cause a change in look I decided to set it to a height of 60, which equals 5 items in height again. I'm fine with the height being different of course, just give me your ok and I'll provide an updated patchset. Need to know what the minimal size you deem ok is though, to me 5 items in the drop down list looks fine, but only 2 or 3 is a bit small in my opinion... Regards, Fabian Maurer

Aug. 31, 2017

Re: [PATCH v2 10/11] progman: Use proper size for combobox controls

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > programs/progman/progman.rc | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/programs/progman/progman.rc b/programs/progman/progman.rc > index 4804330aed..9f451a736b 100644 > --- a/programs/progman/progman.rc > +++ b/programs/progman/progman.rc > @@ -119,7 +119,7 @@ LTEXT "", PM_PROGRAM, 95, 5, 90, 15 > LTEXT "From group:", -1, 5, 13, 90, 15 > LTEXT "", PM_FROM_GROUP, 95, 13, 90, 15 > LTEXT "&To group:", PM_TO_GROUP_TXT, 5, 28, 140, 15 > -COMBOBOX PM_TO_GROUP, 5, 38, 140, 50, WS_TABSTOP | CBS_DROPDOWNLIST > +COMBOBOX PM_TO_GROUP, 5, 38, 140, 60, WS_TABSTOP | CBS_DROPDOWNLIST That kind of change doesn't seem necessary. We don't need all comboboxes to have the exact same height, only something reasonable. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2017

Re: Wine fails to compile in kernel32

by Fabian Maurer

> Since commit e99811aee2dff88c41d6e2875401810a85325839 wine fails to build Thanks you, it's fixed as of 3b399bbbf894b894f8ee753465ad90d7bfb7841d. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> Interesting thing to test I think is to verify if current cross-built > winecfg shows the same issue on Windows, before changing them all. Well, I already added a testcase to show this behavior, but it can't hurt, I guess. I needed to remove the link to "wine_get_unix_file_name" in theme.c, and remove the manifest from the exe, then it starts up on windows. For some reason, it started itself a few hundred times, but then the GUI showed up. The issue is the same on windows, the combobox doesn't work properly the way it currently is, with the patch I submitted it works fine. Actually, windows does show a listbox without the patch, but it's merely 2 pixels in height. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: >> > There are resources in other modules that look like they would have the >> > same problem, a grep over the codebase would probably be useful. >> >> Indeed, I'll look into it. > > There are 10 other components affected. Two questions: > > 1) Should I only look in *.rc files or are there others to look out for? That's probably good enough. > 2) Should I make one big patch or for each component one? One per component please. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Nikolay Sivov

On 29.08.2017 20:06, Fabian Maurer wrote: > Fixes Bug 43632. > winecfg used the broken behavior that was fixed > in f7f7b89e2e9117811c91269643868c6d063db5e9, > so we need to adjust it. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > programs/winecfg/winecfg.rc | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > Interesting thing to test I think is to verify if current cross-built winecfg shows the same issue on Windows, before changing them all.

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> > There are resources in other modules that look like they would have the > > same problem, a grep over the codebase would probably be useful. > > Indeed, I'll look into it. There are 10 other components affected. Two questions: 1) Should I only look in *.rc files or are there others to look out for? 2) Should I make one big patch or for each component one? Regards, Fabian Maurer

Aug. 30, 2017

WINED3DFMT_RESZ in wined3d.

by lorenzo Skotos

Hi. I was investigating a regression that cause the CheckDeviceFormat function to return WINED3DERR_NOTAVAILABLE when quering for RESZ surfaces. (WINED3DFMT_RESZ). This is causing OblivionReloaded (that worked properly until wine 2.5) to not work properly (it detect an incompatible hardware in wine or NVIDIA in wine-staging). I tacked the regression to this commit : https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979… [https://camo.githubusercontent.com/db3db2bf09d082a1f4244859890e83954d8410ab…]<https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979…> wined3d: Allow all formats with "glInternal" set in CheckSurfaceCapab… · wine-mirror/wine(a)8c98be4<https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979…> github.com …ility(). Rendertarget, depth/stencil and texturing restrictions are applied later in wined3d_check_device_format(), so to the extent this make a difference it mostly affects off-screen plain surf... I tried to fix this issue. The last patch I made in my local branch is adding a wined3d_format_texture_info in the format_texture_info array: + {WINED3DFMT_RESZ, GL_DEPTH24_STENCIL8, GL_DEPTH24_STENCIL8, 0, + GL_DEPTH_STENCIL, GL_UNSIGNED_INT, 0, + WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL | WINED3DFMT_FLAG_RENDERTARGET | WINED3DFMT_FLAG_FBO_ATTACHABLE, + ARB_FRAMEBUFFER_OBJECT, NULL}, However I know almost nothing about the internal work of wined3d and opengl and don't know if this kind of addition is correct. OblivionReloaded works and can properly use the RESZ depth texture. I based this patch on the INTZ and RAWZ surfaces that are somewhat reported to be similar in scope in some docs. Also I don't know if the flags are correct or even meaningful in this scope. I could not find any documentation about the internal meaning of these flags. As the good Jon Snow I know nothing. Note I never did a patch in wine before (except adding some debug message). So please tell me if I'm in a completly wrong direction. Also note that I didn't run the test suite. Using make test is failing hard on an advapi32 test even without this patch applied. I attached the full patch file.

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> There are resources in other modules that look like they would have the > same problem, a grep over the codebase would probably be useful. Indeed, I'll look into it. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH 1/2] comctl32/taskdialog: Initial support for callback procedure

by Fabian Maurer

Hello, thanks for the quick response. > I have no problem with that, except for maybe initializing > size/callback/user data in run_test still. Yes, since that's always the same that makes sense. It's a minor issue really, we could pull it out later, too, but we too could just define it outside from the beginning. > Ok, this is easy to add. If this is so, don't mind this. I just didn't know whether we could fit that into the message structure, too. > What do you mean by last message arrival? Currently all messages to > control are posted, so we don't wait for anything but rely on callback > to be called eventually. Do you mean that you want to specify message to > be sent to control for every callback individually, like for example in > mes_cancel_esc_callback1 - WM_KEYDOWN is sent in response to TDN_CREATED > and TDM_CLICK_BUTTON in response to TDN_BUTTON_CLICKED? Basically yes. Right now all messages are posted at once, and that's where we run into problems. When running my patch on a win7 machine, mes_cancel_esc_callback1 succeeds while mes_cancel_esc_callback2 fails. For some reason the "M_KEYDOWN, VK_ESCAPE" message is completely ignored, and we get IDOK. E.g., modify it like ------ static const struct message_info mes_cancel_esc_callback2[] = { { TDN_CREATED, 0, 0, S_OK, { { WM_KEYDOWN, VK_ESCAPE, 0 }, { TDM_CLICK_BUTTON, IDOK, 0 }, { 0 }}}, { TDN_BUTTON_CLICKED, IDOK, 0, S_OK }, { 0 } }; ------ and it works fine again. As you see, this is something that shouldn't happen. Honestly, I have no idea why that happens, maybe you know more. Could be that I'm just doing something really wrong, but this is the reason I switched to the new strategy - sending the new messages after the old were processed. I just found it to be way more reliable. I'm fine with a different strategy of course, it's just that this was the only way I managed to solve this particular issue. On a site note, the second test fail with ------ taskdialog.c:213: Failed sequence Cancellation: stopped by callback 2: taskdialog.c:213: 0: expected: nothing - actual: 8000 wp 00000000 lp 00000000 taskdialog.c:213: 1: expected: nothing - actual: 8000 wp 00000000 lp 00000000 taskdialog.c:213: 2: expected: nothing - actual: 8000 wp 00000001 lp 00000000 taskdialog.c:213: 3: expected: nothing - actual: 8000 wp 00000000 lp 00000000 ------ and that's obviously wrong. Attached a quick hack, I assume this is a bug in the msg.h implementation. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] user32: In GetMinMaxInfo, use the default X pos even if the Y pos changes

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This fixes maximizing to the wrong monitor on a Mac with multiple > monitors. Maximizing with multiple monitors continues to work correctly > on Linux for me. > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > dlls/user32/winpos.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) I'm not sure it makes sense to use only one coordinate of the monitor rectangle. What are the coordinate values that trigger this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > Fixes Bug 43632. > winecfg used the broken behavior that was fixed > in f7f7b89e2e9117811c91269643868c6d063db5e9, > so we need to adjust it. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > programs/winecfg/winecfg.rc | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) There are resources in other modules that look like they would have the same problem, a grep over the codebase would probably be useful. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017

Re: [PATCH 1/2] comctl32/taskdialog: Initial support for callback procedure

by Nikolay Sivov

On 30.08.2017 2:06, Fabian Maurer wrote: > Hi, > > Sorry, but there's a bunch of issues I need to point out. Of course we could > address them later, but it'll mean rewriting a bunch of code, and I'd like to > have it correct from the beginning. In general, I think this implementation > limits us too much. No, you're right, if it means large changes later it should be done differently. > > For example, I don't think it's a good idea to have the TASKDIALOGCONFIG > structure being filled in run_test_, we need to be able to control it easily. I have no problem with that, except for maybe initializing size/callback/user data in run_test still. > > Second, we also need to be able to return different values in the callback, > the current approach doesn't account for that. Ok, this is easy to add. > > And the most important part, the separation from messages to send and received > messages to test against. It's better to send the next message only when the > last message arrived, to make sure we process them in the correct order. > I attached a patch to show the problem (apply on top of my in-review patch). > When sending all messages together, the first message is skipped, and we don't > want that to happen. What do you mean by last message arrival? Currently all messages to control are posted, so we don't wait for anything but rely on callback to be called eventually. Do you mean that you want to specify message to be sent to control for every callback individually, like for example in mes_cancel_esc_callback1 - WM_KEYDOWN is sent in response to TDN_CREATED and TDM_CLICK_BUTTON in response to TDN_BUTTON_CLICKED? I'll look into that. > > Please reconsider my approach, I can try to simplify it if you want, but I > think the complexity is justified to solve a complicated problem. Yes, I will, thanks for your comments. > > Regards, > Fabian Maurer > > > >

Aug. 30, 2017

Re: [PATCH 1/2] comctl32/taskdialog: Initial support for callback procedure

by Fabian Maurer

Hi, Sorry, but there's a bunch of issues I need to point out. Of course we could address them later, but it'll mean rewriting a bunch of code, and I'd like to have it correct from the beginning. In general, I think this implementation limits us too much. For example, I don't think it's a good idea to have the TASKDIALOGCONFIG structure being filled in run_test_, we need to be able to control it easily. Second, we also need to be able to return different values in the callback, the current approach doesn't account for that. And the most important part, the separation from messages to send and received messages to test against. It's better to send the next message only when the last message arrived, to make sure we process them in the correct order. I attached a patch to show the problem (apply on top of my in-review patch). When sending all messages together, the first message is skipped, and we don't want that to happen. Please reconsider my approach, I can try to simplify it if you want, but I think the complexity is justified to solve a complicated problem. Regards, Fabian Maurer

Aug. 29, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Matteo Bruni

2017-08-29 17:08 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 08/29/2017 05:35 PM, Matteo Bruni wrote: >> >> Right, I think checking that during parsing is a good idea regardless >> of everything else. >> >> I'd argue that either the expression above is too generic (allowing / >> handling register_count > 1) or the other register_count expression >> (the merge one I brought up earlier) is too naive, not expecting the >> same. As it is it just doesn't look right. > > I updated the expression in 'merge' phase by now to do the check, more > exactly, added a check for the case under discussion inside the 'if'. > > To block the situation when register components exceed register size, I > actually should check not just component count but offset also. Perhaps this > should also be done not just for output but for input registers only. This > can't be done cleanly for input registers though for all the cases, as there > might be a relative offset which can still effectively make a multicomponent > operation cross register boundary. Not sure if we should add runtime checks > for that. Native implementation seems to allow all this and does not refuse > to parse preshaders which crossses a register boundary in instruction even > without relative addressing. It does allow some things we already deny now, > so I think I should improve the checks for components during parsing and > block them early when possible, and after that consider preshader > instruction output to affect just one register always in this part. Native may allow that but there is some good chance that it computes incorrect outputs / sets incorrect device states in those cases (i.e. I imagine instructions straddling multiple registers to be unexpected for native too). It's probably not relevant in practice. Anyway, sure, I'm okay with adding those checks in our implementation if you want (mostly to print some WARNs if the unexpected happens) but simply assuming / enforcing a single output register per instruction, along the lines of my last email, seems enough to me.

Aug. 29, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Paul Gofman

On 08/29/2017 05:35 PM, Matteo Bruni wrote: > > Right, I think checking that during parsing is a good idea regardless > of everything else. > > I'd argue that either the expression above is too generic (allowing / > handling register_count > 1) or the other register_count expression > (the merge one I brought up earlier) is too naive, not expecting the > same. As it is it just doesn't look right. I updated the expression in 'merge' phase by now to do the check, more exactly, added a check for the case under discussion inside the 'if'. To block the situation when register components exceed register size, I actually should check not just component count but offset also. Perhaps this should also be done not just for output but for input registers only. This can't be done cleanly for input registers though for all the cases, as there might be a relative offset which can still effectively make a multicomponent operation cross register boundary. Not sure if we should add runtime checks for that. Native implementation seems to allow all this and does not refuse to parse preshaders which crossses a register boundary in instruction even without relative addressing. It does allow some things we already deny now, so I think I should improve the checks for components during parsing and block them early when possible, and after that consider preshader instruction output to affect just one register always in this part. > If you ensure during parsing that, for each preshader instruction, 0 < > component_count <= components_per_register then you can just always > set the initial register_count to 1. Actually you could avoid setting > it at all at that point (more on that below). > >> So maybe I will add an assert for the overlapping registers in this >> 'if' under discussion just in case? > That may also be a good idea. Otherwise, if the "+ out->const_set[i + > 1].register_count" part is replaced with a "+ 1", the overlap case > would be handled trivially. That would make it possible to avoid the > previous register_count initialization entirely, assuming > register_count is set to 1 during merging in the NOT merging case. Yes, sure. > Both options are okay with me. Also, as usual, let me know if I'm > still missing something. > I added a check in this patch by now (as all the other code actually allows for multicomponent operation to cross register boundary by now, and thus register_count can potentially exceed 1 here).

Aug. 29, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Matteo Bruni

2017-08-29 1:16 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 08/29/2017 01:51 AM, Matteo Bruni wrote: >> >> 2017-08-28 23:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >>> >>> On 08/28/2017 09:00 PM, Matteo Bruni wrote: >>>> >>>> >>>>> @@ -971,10 +946,30 @@ static HRESULT get_constants_desc(unsigned int >>>>> *byte_code, struct d3dx_const_tab >>>>> if (FAILED(hr = init_set_constants_param(out, ctab, hc, >>>>> inputs_param[index]))) >>>>> goto cleanup; >>>>> } >>>>> + if (pres) >>>>> + append_pres_const_set(out, pres); >>>>> if (out->const_set_count) >>>>> { >>>>> struct d3dx_const_param_eval_output *new_alloc; >>>>> >>>>> + qsort(out->const_set, out->const_set_count, >>>>> sizeof(*out->const_set), compare_const_set); >>>>> + for (i = 0; i < out->const_set_count - 1; ++i) >>>>> + { >>>>> + if (out->const_set[i].constant_class == D3DXPC_FORCE_DWORD >>>>> + && out->const_set[i + 1].constant_class == >>>>> D3DXPC_FORCE_DWORD >>>>> + && out->const_set[i].table == out->const_set[i + >>>>> 1].table >>>>> + && out->const_set[i].register_index + >>>>> out->const_set[i].register_count >>>>> + >= out->const_set[i + 1].register_index) >>>>> + { >>>>> + out->const_set[i].register_count = out->const_set[i + >>>>> 1].register_index >>>>> + + out->const_set[i + 1].register_count - >>>>> out->const_set[i].register_index; >>>> >>>> I think this might lose account of some registers. E.g. consider the >>>> case where const_set[i] has register_index == 0 and register_count == >>>> 4 while const_set[i + 1] has register_index == 1 and register_count == >>>> 1. This would seem to lose track of the last two components. >>>> >>>> I know that preshaders found in the wild seem not to overwrite already >>>> written output registers but I wouldn't feel safe with (silently) >>>> depending on it. >>> >>> This 'if' selects just preshader output constants. The entries for >>> const_set >>> handled (merged) in this 'if' are those provided preshader instructions >>> which output anything to shader constants. They can potentially overlap >>> (that's why '>=' in the last 'if' check). I am not sure what can be >>> wrong >>> with that? We track preshader output as a single "commit", the same does >>> native implementation according to our tests. >> >> I don't have any issues with the if condition. It's the >> const_set[i].register_count assignment which looks troublesome since >> it doesn't consider the old count. In the (artificial, even forced if >> you want) example I gave const_set[i].register_count would go from 4 >> to 2 which doesn't seem right. >> > Here is how this register_count is currently evaluated: > > ---- snip ---- > > const_set.register_count = max(get_reg_offset(reg->table, > pres_op_info[ins->op].func_all_comps ? 1 : > ins->component_count), 1); > > ---- snip ---- > > This expression is written for some generic case of component_count and > components per register, but unless I am missing something this expression > should not evaluate to anything but 1 for the real cases. We do not check > that component count in instruction does not exceed component count per > register during preshader parse though (just checking if it is between 1 and > 4). Right, I think checking that during parsing is a good idea regardless of everything else. I'd argue that either the expression above is too generic (allowing / handling register_count > 1) or the other register_count expression (the merge one I brought up earlier) is too naive, not expecting the same. As it is it just doesn't look right. If you ensure during parsing that, for each preshader instruction, 0 < component_count <= components_per_register then you can just always set the initial register_count to 1. Actually you could avoid setting it at all at that point (more on that below). > So maybe I will add an assert for the overlapping registers in this > 'if' under discussion just in case? That may also be a good idea. Otherwise, if the "+ out->const_set[i + 1].register_count" part is replaced with a "+ 1", the overlap case would be handled trivially. That would make it possible to avoid the previous register_count initialization entirely, assuming register_count is set to 1 during merging in the NOT merging case. Both options are okay with me. Also, as usual, let me know if I'm still missing something.

Aug. 29, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Paul Gofman

On 08/29/2017 01:51 AM, Matteo Bruni wrote: > 2017-08-28 23:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> On 08/28/2017 09:00 PM, Matteo Bruni wrote: >>> >>>> @@ -971,10 +946,30 @@ static HRESULT get_constants_desc(unsigned int >>>> *byte_code, struct d3dx_const_tab >>>> if (FAILED(hr = init_set_constants_param(out, ctab, hc, >>>> inputs_param[index]))) >>>> goto cleanup; >>>> } >>>> + if (pres) >>>> + append_pres_const_set(out, pres); >>>> if (out->const_set_count) >>>> { >>>> struct d3dx_const_param_eval_output *new_alloc; >>>> >>>> + qsort(out->const_set, out->const_set_count, >>>> sizeof(*out->const_set), compare_const_set); >>>> + for (i = 0; i < out->const_set_count - 1; ++i) >>>> + { >>>> + if (out->const_set[i].constant_class == D3DXPC_FORCE_DWORD >>>> + && out->const_set[i + 1].constant_class == >>>> D3DXPC_FORCE_DWORD >>>> + && out->const_set[i].table == out->const_set[i + >>>> 1].table >>>> + && out->const_set[i].register_index + >>>> out->const_set[i].register_count >>>> + >= out->const_set[i + 1].register_index) >>>> + { >>>> + out->const_set[i].register_count = out->const_set[i + >>>> 1].register_index >>>> + + out->const_set[i + 1].register_count - >>>> out->const_set[i].register_index; >>> I think this might lose account of some registers. E.g. consider the >>> case where const_set[i] has register_index == 0 and register_count == >>> 4 while const_set[i + 1] has register_index == 1 and register_count == >>> 1. This would seem to lose track of the last two components. >>> >>> I know that preshaders found in the wild seem not to overwrite already >>> written output registers but I wouldn't feel safe with (silently) >>> depending on it. >> This 'if' selects just preshader output constants. The entries for const_set >> handled (merged) in this 'if' are those provided preshader instructions >> which output anything to shader constants. They can potentially overlap >> (that's why '>=' in the last 'if' check). I am not sure what can be wrong >> with that? We track preshader output as a single "commit", the same does >> native implementation according to our tests. > I don't have any issues with the if condition. It's the > const_set[i].register_count assignment which looks troublesome since > it doesn't consider the old count. In the (artificial, even forced if > you want) example I gave const_set[i].register_count would go from 4 > to 2 which doesn't seem right. > Here is how this register_count is currently evaluated: ---- snip ---- const_set.register_count = max(get_reg_offset(reg->table, pres_op_info[ins->op].func_all_comps ? 1 : ins->component_count), 1); ---- snip ---- This expression is written for some generic case of component_count and components per register, but unless I am missing something this expression should not evaluate to anything but 1 for the real cases. We do not check that component count in instruction does not exceed component count per register during preshader parse though (just checking if it is between 1 and 4). So maybe I will add an assert for the overlapping registers in this 'if' under discussion just in case?

Aug. 28, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Matteo Bruni

2017-08-28 23:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 08/28/2017 09:00 PM, Matteo Bruni wrote: >> >> >>> @@ -971,10 +946,30 @@ static HRESULT get_constants_desc(unsigned int >>> *byte_code, struct d3dx_const_tab >>> if (FAILED(hr = init_set_constants_param(out, ctab, hc, >>> inputs_param[index]))) >>> goto cleanup; >>> } >>> + if (pres) >>> + append_pres_const_set(out, pres); >>> if (out->const_set_count) >>> { >>> struct d3dx_const_param_eval_output *new_alloc; >>> >>> + qsort(out->const_set, out->const_set_count, >>> sizeof(*out->const_set), compare_const_set); >>> + for (i = 0; i < out->const_set_count - 1; ++i) >>> + { >>> + if (out->const_set[i].constant_class == D3DXPC_FORCE_DWORD >>> + && out->const_set[i + 1].constant_class == >>> D3DXPC_FORCE_DWORD >>> + && out->const_set[i].table == out->const_set[i + >>> 1].table >>> + && out->const_set[i].register_index + >>> out->const_set[i].register_count >>> + >= out->const_set[i + 1].register_index) >>> + { >>> + out->const_set[i].register_count = out->const_set[i + >>> 1].register_index >>> + + out->const_set[i + 1].register_count - >>> out->const_set[i].register_index; >> >> I think this might lose account of some registers. E.g. consider the >> case where const_set[i] has register_index == 0 and register_count == >> 4 while const_set[i + 1] has register_index == 1 and register_count == >> 1. This would seem to lose track of the last two components. >> >> I know that preshaders found in the wild seem not to overwrite already >> written output registers but I wouldn't feel safe with (silently) >> depending on it. > > This 'if' selects just preshader output constants. The entries for const_set > handled (merged) in this 'if' are those provided preshader instructions > which output anything to shader constants. They can potentially overlap > (that's why '>=' in the last 'if' check). I am not sure what can be wrong > with that? We track preshader output as a single "commit", the same does > native implementation according to our tests. I don't have any issues with the if condition. It's the const_set[i].register_count assignment which looks troublesome since it doesn't consider the old count. In the (artificial, even forced if you want) example I gave const_set[i].register_count would go from 4 to 2 which doesn't seem right.

Aug. 28, 2017

Re: [PATCH] comctl32/taskdialog: Add callback and tests

by Fabian Maurer

Hello, sorry I thought I already sent this, but it apparently didn't work. > This looks suspicious, documentation is not strict on this, but it seems > TDN_CREATED corresponds for to WM_SHOWWINDOW stage. I'm not sure, I'll look into it. > > + /* Custom messages*/ > > What do you mean by "custom"? I meant taskdialog specific messages. Guess I'll change it to "Taskdialog messages" > > - if (verification_flag_checked) *verification_flag_checked = TRUE; > > + if (verification_flag_checked) *verification_flag_checked = FALSE; > > Why do you need this flag value change? Because that's what the tests told me windows behaves like. > > > return S_OK; > > > > } > > > > diff --git a/dlls/comctl32/tests/taskdialog.c > > b/dlls/comctl32/tests/taskdialog.c index c937127897..867361617c 100644 > > --- a/dlls/comctl32/tests/taskdialog.c > > +++ b/dlls/comctl32/tests/taskdialog.c > > @@ -24,13 +24,250 @@ > > > > #include "winuser.h" > > #include "commctrl.h" > > > > +#include "wine/list.h" > > > > #include "wine/test.h" > > #include "v6util.h" > > > > +#include "msg.h" > > + > > +#define WM_TD_CALLBACK (WM_APP) /* Custom dummy message to wrap callback > > notifications */ + > > +#define NUM_MSG_SEQUENCES 1 > > +#define TASKDIALOG_SEQ_INDEX 0 > > + > > +#define TEST_NUM_BUTTONS 20 /* Number of custom buttons to test with */ > > + > > +#define ID_START 20 /* Lower IDs might be used by the system */ > > +#define ID_START_BUTTON (ID_START + 0) > > > > static HRESULT (WINAPI *pTaskDialogIndirect)(const TASKDIALOGCONFIG *, > > int *, int *, BOOL *); static HRESULT (WINAPI *pTaskDialog)(HWND, > > HINSTANCE, const WCHAR *, const WCHAR *, const WCHAR *,> > > TASKDIALOG_COMMON_BUTTON_FLAGS, const WCHAR *, int *); > > > > +static struct msg_sequence *sequences[NUM_MSG_SEQUENCES]; > > + > > +/* Message lists to test against */ > > + > > +struct message_send_info > > +{ > > + UINT send_message; > > + WPARAM send_wparam; > > + LPARAM send_lparam; > > + > > + BOOL post; /* post instead of send */ > > + const CHAR *title_target; /* control text, 0 means it's send to the > > dialog form instead */ +}; > > + > > +struct message_info > > +{ > > + UINT recv_message; /* Message the callback receives */ > > + WPARAM recv_wparam; > > + LPARAM recv_lparam; > > + > > + HRESULT ret; /* Value the callback should return */ > > + > > + struct message_send_info send[9]; /* Message to send to trigger the > > next callback message */ +}; > > + > > +static const struct message_info *current_message_info; > > + > > +static const struct message_info mes_return_press_ok[] = { > > + { TDN_CREATED, 0, 0, S_OK, { > > + { WM_KEYDOWN, VK_RETURN, 0, TRUE }, > > + { 0 }}}, > > + { TDN_BUTTON_CLICKED, IDOK, 0, S_OK, {{ 0 }}}, > > + { 0 } > > +}; > > + > > +static const struct message_info mes_cancel_button_press[] = { > > + { TDN_CREATED, 0, 0, S_OK, { > > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > > + { 0 }}}, > > + { TDN_BUTTON_CLICKED, IDOK, 0, S_FALSE, {{ 0 }}}, > > + { TDN_BUTTON_CLICKED, IDOK, 0, 0xFF, {{ 0 }}}, /* Random return value > > tested here */ + { TDN_BUTTON_CLICKED, IDOK, 0, S_OK, {{ 0 }}}, > > + { 0 } > > +}; > > + > > +static const struct message_info mes_send_button_directly[] = { > > + { TDN_CREATED, 0, 0, S_OK, { > > + { WM_LBUTTONDOWN, MK_LBUTTON, 0, TRUE, "02" }, > > + { WM_LBUTTONUP, 0, 0, TRUE, "02" }, > > + { 0 }}}, > > + { TDN_BUTTON_CLICKED, ID_START + 2, 0, S_OK, {{ 0 }}}, > > + { 0 } > > +}; > > This looks too complicated, I'd just check notifications callback > received, using 'struct message' data, same way WM_NOTIFY tests work. I have more tests currently available, like cancelling tests. They're not part of this patch, but I figured I'll do it right from the beginning. > > +static HWND get_child_from_title(HWND hwnd_parent, const CHAR *title) > > +{ > > + taskdialog_child = NULL; > > + EnumChildWindows(hwnd_parent, enum_taskdialog_children_proc, > > (LPARAM)title); + return taskdialog_child; > > +} > > I don't think we need to get that deep. Are you sure? I figured it would make sense to actually test for simulated mouse clicks instead of just sending the taskdialog specific click messages. > I think for first iteration test should simply check > creation/destruction notifications and callback user data value. I'll take care of the issues and resend the patch as simplified version. Regards Fabian Maurer

Aug. 28, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Paul Gofman

On 08/28/2017 09:00 PM, Matteo Bruni wrote: > >> @@ -971,10 +946,30 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab >> if (FAILED(hr = init_set_constants_param(out, ctab, hc, inputs_param[index]))) >> goto cleanup; >> } >> + if (pres) >> + append_pres_const_set(out, pres); >> if (out->const_set_count) >> { >> struct d3dx_const_param_eval_output *new_alloc; >> >> + qsort(out->const_set, out->const_set_count, sizeof(*out->const_set), compare_const_set); >> + for (i = 0; i < out->const_set_count - 1; ++i) >> + { >> + if (out->const_set[i].constant_class == D3DXPC_FORCE_DWORD >> + && out->const_set[i + 1].constant_class == D3DXPC_FORCE_DWORD >> + && out->const_set[i].table == out->const_set[i + 1].table >> + && out->const_set[i].register_index + out->const_set[i].register_count >> + >= out->const_set[i + 1].register_index) >> + { >> + out->const_set[i].register_count = out->const_set[i + 1].register_index >> + + out->const_set[i + 1].register_count - out->const_set[i].register_index; > I think this might lose account of some registers. E.g. consider the > case where const_set[i] has register_index == 0 and register_count == > 4 while const_set[i + 1] has register_index == 1 and register_count == > 1. This would seem to lose track of the last two components. > > I know that preshaders found in the wild seem not to overwrite already > written output registers but I wouldn't feel safe with (silently) > depending on it. This 'if' selects just preshader output constants. The entries for const_set handled (merged) in this 'if' are those provided preshader instructions which output anything to shader constants. They can potentially overlap (that's why '>=' in the last 'if' check). I am not sure what can be wrong with that? We track preshader output as a single "commit", the same does native implementation according to our tests.

Aug. 28, 2017

Wine fails to compile in kernel32

by Fabian Maurer

Hello wine-devel, I'm running ArchLinux with gcc 7.2.0. Since commit e99811aee2dff88c41d6e2875401810a85325839 wine fails to build with > ../../../wine-git/dlls/kernel32/module.c: In function ‘load_library’: > ../../../wine-git/dlls/kernel32/module.c:987:44: error: initializer element is not constant > static const DWORD unsupported_flags = load_library_search_flags | Minimal test-program to show the error, just use something like "gcc main.c" to compile. ---------- static const int load_library_search_flags = 0; int main() { static const int unsupported_flags = load_library_search_flags; return 0; } ---------- Looks like an compiler error, but I'm not sure. Mind looking into that? Regards, Fabian Maurer

Aug. 28, 2017

Re: [PATCH 2/2] d3dx9: Get rid of constants modification bitmasks.

by Matteo Bruni

2017-08-10 12:02 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> The patch is fine overall, I only have a few questions / nitpicks. I'll skip the part about the delay with the review because it's old news by now... :/ > --- > dlls/d3dx9_36/d3dx9_private.h | 3 +- > dlls/d3dx9_36/preshader.c | 312 ++++++++++++++++++------------------------ > 2 files changed, 135 insertions(+), 180 deletions(-) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index 2727463a18..5ac5e63aeb 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -230,7 +230,7 @@ enum pres_reg_tables > struct d3dx_const_param_eval_output > { > struct d3dx_parameter *param; > - unsigned int table; > + enum pres_reg_tables table; The change is good but (unrelated to this patch) the enum type should really use the singular form. > static void dump_bytecode(void *data, unsigned int size) > @@ -674,6 +614,40 @@ static HRESULT append_const_set(struct d3dx_const_tab *const_tab, struct d3dx_co > return D3D_OK; > } > > +static void append_pres_const_set(struct d3dx_const_tab *const_tab, struct d3dx_preshader *pres) Nitpick: this function appends all the struct d3dx_const_param_eval_output from the preshader so calling it "append_pres_const_sets" (or even something more explicit to that effect, e.g. clarifying that you're appending entries about the preshader outputs, which are shader inputs) would be preferable. > +{ > + unsigned int i; > + struct d3dx_const_param_eval_output const_set; > + > + memset(&const_set, 0, sizeof(const_set)); You could initialize const_set in the definition instead, like: struct d3dx_const_param_eval_output const_set = {NULL}; which looks slightly better to me. It doesn't matter much of course. > @@ -971,10 +946,30 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > if (FAILED(hr = init_set_constants_param(out, ctab, hc, inputs_param[index]))) > goto cleanup; > } > + if (pres) > + append_pres_const_set(out, pres); > if (out->const_set_count) > { > struct d3dx_const_param_eval_output *new_alloc; > > + qsort(out->const_set, out->const_set_count, sizeof(*out->const_set), compare_const_set); > + for (i = 0; i < out->const_set_count - 1; ++i) > + { > + if (out->const_set[i].constant_class == D3DXPC_FORCE_DWORD > + && out->const_set[i + 1].constant_class == D3DXPC_FORCE_DWORD > + && out->const_set[i].table == out->const_set[i + 1].table > + && out->const_set[i].register_index + out->const_set[i].register_count > + >= out->const_set[i + 1].register_index) > + { > + out->const_set[i].register_count = out->const_set[i + 1].register_index > + + out->const_set[i + 1].register_count - out->const_set[i].register_index; I think this might lose account of some registers. E.g. consider the case where const_set[i] has register_index == 0 and register_count == 4 while const_set[i + 1] has register_index == 1 and register_count == 1. This would seem to lose track of the last two components. I know that preshaders found in the wild seem not to overwrite already written output registers but I wouldn't feel safe with (silently) depending on it. > + memmove(&out->const_set[i + 1], &out->const_set[i + 2], sizeof(out->const_set[i]) > + * (out->const_set_count - i - 2)); > + --out->const_set_count; > + --i; Mostly matter of personal preference but rather than decrementing the for counter in the if when coalescing I'd write this as a while and increment "i" only in the (currently absent) else case. > @@ -1529,22 +1534,56 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > data += param->rows * param->columns; > } > start_offset = get_offset_reg(table, const_set->register_index); > - if (table_info[table].type == param_type) > - regstore_set_modified(rs, table, start_offset, > - get_offset_reg(table, const_set->register_count) * const_set->element_count); > - else > + if (table_info[table].type != param_type) > regstore_set_data(rs, table, start_offset, (unsigned int *)rs->tables[table] + start_offset, > get_offset_reg(table, const_set->register_count) * const_set->element_count, param_type); > } > + > + > const_tab->update_version = new_update_version; One blank line too many. > -} > + if (!update_device) > + return D3D_OK; > > + for (const_idx = 0; const_idx < const_tab->const_set_count; ++const_idx) > + { > + struct d3dx_const_param_eval_output *const_set = &const_tab->const_set[const_idx]; > + > + if (device_update_all || (const_set->param > + ? is_param_dirty(const_set->param, update_version) : pres_dirty)) > + { > + enum pres_reg_tables table = const_set->table; > + > + if (table == device_table && device_start + device_count == const_set->register_index) Again nitpicking: are there better names for those variables? Maybe use the "current_" prefix instead? It's pretty clear what's going on either way, so up to you.

Aug. 28, 2017

Re: [PATCH] ws2_32: Also check the FQDN when injecting the local IP.

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -6576,6 +6592,8 @@ int WINAPI WS_getaddrinfo(LPCSTR nodename, LPCSTR servname, const struct WS_addr > > hostname = get_hostname(); > if (!hostname) return WSA_NOT_ENOUGH_MEMORY; > + fqdn = get_fqdn(); > + if (!fqdn) return WSA_NOT_ENOUGH_MEMORY; It seems to me that you shouldn't need to retrieve both separately, the FQDN contains the hostname already. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2017

Re: Issue with suspended process

by Alexandre Julliard

Jonathan Doron <jond(a)wizery.com> writes: > Sure what type of tests would you like to see? Basically you'd create a suspended process and then poke around and test what has or hasn't been initialized yet. You can use the various things that the Wine loader does during init as a guide to what to test. Then you can also try changing things, resume the process and check that it has the expected effect. -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2017

Re: [PATCH resend] msxml3: Remove CRs in domtext_put_data and add them in domtext_get_xml.

by Alex Henrie

2017-08-17 13:34 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: > On 03.08.2017 18:17, Alex Henrie wrote: >> Fixes https://bugs.winehq.org/show_bug.cgi?id=42468 >> >> To be clear, I am not trying to fix all whitespace processing issues. I >> am only trying to prevent "" from being erroneously inserted into >> the output. >> >> Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> >> --- >> dlls/msxml3/tests/domdoc.c | 106 +++++++++++++++++++++++++++++++++++++-------- >> dlls/msxml3/text.c | 42 +++++++++++++++--- >> 2 files changed, 122 insertions(+), 26 deletions(-) >> >> diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > > I think it needs more tests, for xml:space and put_preserveWhiteSpace(). Okay, I've added tests for xml:space="preserve" and preserveWhiteSpace. >> diff --git a/dlls/msxml3/text.c b/dlls/msxml3/text.c >> index 3a12d4bf62..6814c1f817 100644 >> --- a/dlls/msxml3/text.c >> +++ b/dlls/msxml3/text.c >> @@ -519,10 +519,15 @@ static HRESULT WINAPI domtext_get_xml( >> BSTR* p) >> { >> domtext *This = impl_from_IXMLDOMText( iface ); >> + HRESULT hr; >> >> TRACE("(%p)->(%p)\n", This, p); >> >> - return node_get_xml(&This->node, FALSE, p); >> + hr = node_get_xml(&This->node, FALSE, p); >> + if (hr == S_OK) >> + *p = EnsureCorrectEOL(*p); >> + >> + return hr; > > Will node_get_xml(..., TRUE, ...) work? Yes, thanks for the suggestion! >> } >> >> static HRESULT WINAPI domtext_transformNode( >> @@ -616,15 +621,38 @@ static HRESULT WINAPI domtext_put_data( >> BSTR data) >> { >> domtext *This = impl_from_IXMLDOMText( iface ); >> - static const WCHAR rnW[] = {'\r','\n',0}; >> + BSTR normalized_data = NULL; >> + HRESULT hr; >> + int i, j; >> >> TRACE("(%p)->(%s)\n", This, debugstr_w(data)); >> >> - if (data && !strcmpW(rnW, data)) >> - This->node.node->name = xmlStringTextNoenc; >> - else >> - domtext_reset_noenc(This); >> - return node_set_content(&This->node, data); >> + if (data) >> + { >> + /* normalize line endings */ >> + normalized_data = SysAllocStringLen(NULL, SysStringLen(data)); >> + if (!normalized_data) return E_OUTOFMEMORY; >> + for (i = 0, j = 0; data[i]; i++) >> + { >> + if (data[i] == '\r') >> + { >> + if (data[i + 1] == '\n') >> + continue; /* change \r\n to just \n */ >> + else >> + normalized_data[j] = '\n'; /* change \r by itself to \n */ >> + } >> + else >> + normalized_data[j] = data[i]; >> + j++; >> + } >> + normalized_data[j] = 0; > > The only purpose for that is to inhibit libxml2 escaping, right? Could > this be done the way it is now, but with something more elaborate than > comparing to "\r\n"? No, because we only want to inhibit the escaping of "\r" to "". We don't want to inhibit the escaping of other characters such as "&" and "<". -Alex

Aug. 25, 2017

Re: Issue with suspended process

by Jonathan Doron

Sure what type of tests would you like to see? One thing to note is the application I'm referring to Tracker which is part of MS toolchain is a Microsoft application, so no hacks or anything that copy protection software did that sometimes was not fully compatible with all the loaders changes MS did through out the years. On Fri, Aug 25, 2017 at 4:41 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Jon Doron <arilou(a)gmail.com> writes: > > > The interesting thing is that in the past Wine behavior was correct > > and the change that basically broke it is commit: > > > > commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 > > Author: Alexandre Julliard <julliard(a)winehq.org> > > Date: Mon Nov 19 14:27:07 2007 +0100 > > > > ntdll: Unblock signals in process init only after the dlls have > > been imported. > > > > > > Unfortunately though there I could not find any reason why the change > > was made or if there is any bug that it fixed back then (2007) . > > There were apps (usually copy protection) that expected to find some > dlls already loaded in order to patch them. Still, it's very possible > that the initialization order isn't quite correct yet. The first step > would be to write some test cases. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Aug. 25, 2017

Re: Issue with suspended process

by Alexandre Julliard

Jon Doron <arilou(a)gmail.com> writes: > The interesting thing is that in the past Wine behavior was correct > and the change that basically broke it is commit: > > commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Nov 19 14:27:07 2007 +0100 > > ntdll: Unblock signals in process init only after the dlls have > been imported. > > > Unfortunately though there I could not find any reason why the change > was made or if there is any bug that it fixed back then (2007) . There were apps (usually copy protection) that expected to find some dlls already loaded in order to patch them. Still, it's very possible that the initialization order isn't quite correct yet. The first step would be to write some test cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2017

Re: [v2] d3d9/tests: Add test for SW shader in MVP mode.

by Paul Gofman

This is a pre-existing failure. On 08/25/2017 12:58 PM, Marvin wrote: > 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=32837 > > Your paranoid android. > > > === w8 (32 bit visual) === > visual.c:7952: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 >

Aug. 25, 2017

Re: [v2] d3d9/tests: Add test for SW shader in MVP mode.

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=32837 Your paranoid android. === w8 (32 bit visual) === visual.c:7952: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080

Aug. 25, 2017

Re: Issue with suspended process

by Stefan Dösinger

Hi, On 24/08/17 16:41, Jonathan Doron wrote: > The next thing that happens is LdrInitializeThunk continues and fixing > up the EXE module imports, this is not the same behavior as Windows in > which the Ldr only starts running after the thread has > resumed. Depending on what you want to do in the end you may be able to work around the issue by adding a LoadLibraryA("Whatever_injected.dll") somewhere in the init code. That might allow you to use your tool. It helped when I was trying to use pixwin from the DX SDK a while ago. > commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 > Author: Alexandre Julliard <julliard(a)winehq.org > <mailto:julliard(a)winehq.org>> > Date: Mon Nov 19 14:27:07 2007 +0100 > > ntdll: Unblock signals in process init only after the dlls have > been imported. Alexandre is on vacation at the moment as far as I know. He might reply later if he notices the mail in his return inbox flood :-) . bugs.winehq.org tracks which commit fixed a bug, but unfortunately that system was not in place in 2007. Stefan

Aug. 25, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Henri Verbeet

On 24 August 2017 at 17:27, Paul Gofman <gofmanp(a)gmail.com> wrote: > On 08/24/2017 04:39 PM, Henri Verbeet wrote: >> On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote: >>> + /* wined3d does not guarantee 0 for out of bounds constant access by >>> default. */ >> >> IIRC neither does Windows, in general. Matteo may have a better >> recollection of the details, but IIRC while it mostly works out in >> practice on current NVIDIA hardware, it doesn't necessarily everywhere >> else, and is essentially hardware/driver specific behaviour. >> > So should I maybe change the test not to check for exact value but rather > for not matching constant c256? > It might still match by chance. Perhaps it's best to just not test the result of the draw and instead document why.

Aug. 24, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Paul Gofman

On 08/24/2017 04:39 PM, Henri Verbeet wrote: > On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote: >> -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed) >> +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window, >> + BOOL windowed, DWORD behavior_flags) > It's perhaps a bit of an uncomfortable change to make due to the > number of tests in visual.c, but ideally this would match the version > of create_device() in device.c. Lacking that, there are a few tests in > visual.c that just call IDirect3D9_CreateDevice() directly. In either > case, we'd like device.c and visual.c to converge instead of diverge. So I will create the device without this helper function then. >> + hr = IDirect3DDevice9_SetVertexShader(device, NULL); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); >> + hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > Is resetting the shader to NULL really needed here? I will check once again, but I think I saw the second call to DrawPrimitiveUP succeeds for the next scene also if already failed once for previous scene. So it can be removed along with the first call returning invalid value below. > >> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); >> + todo_wine >> + ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); >> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > Odd. It looks like pretty consistent behaviour between drivers, at least it worked the same way for me on Intel & Nvidia (WIndows 7) and test bot. I suppose directx "frontend" part resets the shader internally after returning an error on first call, and then falls back to fixed function vertex processing on the next call. Even if the shader is reset though calling GetVertexShader still returns that invalid one previously set. > >> + /* wined3d does not guarantee 0 for out of bounds constant access by default. */ > IIRC neither does Windows, in general. Matteo may have a better > recollection of the details, but IIRC while it mostly works out in > practice on current NVIDIA hardware, it doesn't necessarily everywhere > else, and is essentially hardware/driver specific behaviour. > So should I maybe change the test not to check for exact value but rather for not matching constant c256?

Aug. 24, 2017

Issue with suspended process

by Jonathan Doron

Hi all, I have an application that is creating a process suspended and then using detours modifies the imports of the new process prior to resuming it (the application is called Tracker.exe and is part of MS toolchain, it can be retrieved in MS EWDK package) The application does not work as it should on Wine, as the DLL its trying to inject to the new process is not getting loaded, I tracked down the problem here are the technical details: When a new process is created, after all the other set-ups its running the function: dlls/ntdll/server.c!server_init_process_done This function sets up the handlers for the different signals (signal_init_process) and makes a wine_server_call init_process_done. In the wine server function server/process.c!init_process_done a check is made to see if the thread of the process needs to be suspended (stop_thread_if_suspended) and indeed when a process is created with the CREATE_SUSPENDED flag, thread->suspend == 1, process->suspend == 0, and the process state is done at this point). This makes the wine_server call to stop_thread which will send a SIGUSR1 signal to the new process. The new process however still have the signals in a block state, thus not processing the signal and putting it into a pending state. The next thing that happens is LdrInitializeThunk continues and fixing up the EXE module imports, this is not the same behavior as Windows in which the Ldr only starts running after the thread has resumed. Only later signals are being unblocked and then the thread enters a suspended state, the function which unblocks the signals today is attach_process_dlls The interesting thing is that in the past Wine behavior was correct and the change that basically broke it is commit: commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Nov 19 14:27:07 2007 +0100 ntdll: Unblock signals in process init only after the dlls have been imported. Unfortunately though there I could not find any reason why the change was made or if there is any bug that it fixed back then (2007) . I was thinking that perhaps in order to resolve the problem and be closer in the behavior to Windows would be to unblock the signals just before server_init_process_done returns. Please let me know if you have any other questions, will be happy to resolve this now that we have all the information laid out. Thanks, -- Jon.

Aug. 24, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Henri Verbeet

On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote: > -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed) > +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window, > + BOOL windowed, DWORD behavior_flags) It's perhaps a bit of an uncomfortable change to make due to the number of tests in visual.c, but ideally this would match the version of create_device() in device.c. Lacking that, there are a few tests in visual.c that just call IDirect3D9_CreateDevice() directly. In either case, we'd like device.c and visual.c to converge instead of diverge. > + hr = IDirect3DDevice9_SetVertexShader(device, NULL); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); Is resetting the shader to NULL really needed here? > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); Odd. > + /* wined3d does not guarantee 0 for out of bounds constant access by default. */ IIRC neither does Windows, in general. Matteo may have a better recollection of the details, but IIRC while it mostly works out in practice on current NVIDIA hardware, it doesn't necessarily everywhere else, and is essentially hardware/driver specific behaviour.

Aug. 24, 2017

Re: [PATCH 2/2] mshtml: Properly expose IHTMLDocument6 interface to scripts.

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=32807 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

Aug. 24, 2017

Issue with suspended process

by Jonathan Doron

Hi all, I have an application that is creating a process suspended and then using detours modifies the imports of the new process prior to resuming it (the application is called Tracker.exe and is part of MS toolchain, it can be retrieved in MS EWDK package) The application does not work as it should on Wine, as the DLL its trying to inject to the new process is not getting loaded, I tracked down the problem here are the technical details: When a new process is created, after all the other set-ups its running the function: dlls/ntdll/server.c!server_init_process_done This function sets up the handlers for the different signals (signal_init_process) and makes a wine_server_call init_process_done. In the wine server function server/process.c!init_process_done a check is made to see if the thread of the process needs to be suspended (stop_thread_if_suspended) and indeed when a process is created with the CREATE_SUSPENDED flag, thread->suspend == 1, process->suspend == 0, and the process state is done at this point). This makes the wine_server call to stop_thread which will send a SIGUSR1 signal to the new process. The new process however still have the signals in a block state, thus not processing the signal and putting it into a pending state. The next thing that happens is LdrInitializeThunk continues and fixing up the EXE module imports, this is not the same behavior as Windows in which the Ldr only starts running after the thread has resumed. Only later signals are being unblocked and then the thread enters a suspended state, the function which unblocks the signals today is attach_process_dlls The interesting thing is that in the past Wine behavior was correct and the change that basically broke it is commit: commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Nov 19 14:27:07 2007 +0100 ntdll: Unblock signals in process init only after the dlls have been imported. Unfortunately though there I could not find any reason why the change was made or if there is any bug that it fixed back then (2007) . I was thinking that perhaps in order to resolve the problem and be closer in the behavior to Windows would be to unblock the signals just before server_init_process_done returns. Please let me know if you have any other questions, will be happy to resolve this now that we have all the information laid out. Thanks, -- Jon.

Aug. 24, 2017

Re: Filling in ARM64 ABI structs

by Martin Storsjö

Hi André, On Wed, 23 Aug 2017, André Hentschel wrote: > Am 22.08.2017 um 15:48 schrieb Martin Storsjö: >> Hi, >> >> I've noticed that some of the ABI specific structs for ARM64 are incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h (not yet available) and _CONTEXT (not missing but only has got made-up content so far) and associated CONTEXT_* defines, and structs like RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h. >> >> As far as I know, these structs should be available in the win10 sdk. (MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT struct at least). In order not to accidentally make myself uneligible for contributing code on these matters, I've tried to not look at the sdk. >> >> Can someone help out with completeing these data structures according to whatever clean-room guidelines are required? When looking at existing code with git blame, they mostly appear as such without any further explanation on how they were derived, so I'm taking the more cautious route here. >> >> // Martin >> >> > > Hi, > > IANAL, but you should be fine as long as you only study the headers and > don't copy&paste... Thanks - if someone else can confirm this I can proceed in this way myself. > Sadly I have no idea anymore how I implemented JUMP_BUFFER for ARM, but > it's a good thing to have an application which needs it, as it seems we > only have tests for amd64 Since I've got a pretty much working compiler for this, I can create whatever calling code I want to test it. I can't know for sure that it's correct with what the so far non-public MSVC/arm64 would do, but I doubt it'd differ too much. > What is also strongly needed is that distributions stop using x18, have > you done something in this regard? Not really. In all the code I've tested so far, I haven't struck any concrete issues with only wine but not the rest of the distro built with -ffixed-x18. But then again, the apps I've built myself don't use the TEB at all, so I won't notice either - I've mostly tested uuidgen.exe and midl.exe from the win10 sdk, for generic compatibility and compatibility with the va_args. // Martin

Aug. 23, 2017

Re: Filling in ARM64 ABI structs

by André Hentschel

Am 22.08.2017 um 15:48 schrieb Martin Storsjö: > Hi, > > I've noticed that some of the ABI specific structs for ARM64 are incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h (not yet available) and _CONTEXT (not missing but only has got made-up content so far) and associated CONTEXT_* defines, and structs like RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h. > > As far as I know, these structs should be available in the win10 sdk. (MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT struct at least). In order not to accidentally make myself uneligible for contributing code on these matters, I've tried to not look at the sdk. > > Can someone help out with completeing these data structures according to whatever clean-room guidelines are required? When looking at existing code with git blame, they mostly appear as such without any further explanation on how they were derived, so I'm taking the more cautious route here. > > // Martin > > Hi, IANAL, but you should be fine as long as you only study the headers and don't copy&paste... Sadly I have no idea anymore how I implemented JUMP_BUFFER for ARM, but it's a good thing to have an application which needs it, as it seems we only have tests for amd64 What is also strongly needed is that distributions stop using x18, have you done something in this regard?

Aug. 23, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Paul Gofman

Test failure (https://source.winehq.org/patches/data/136654.testfail) is unrelated to this patch. It fails in a different test run before the newly added one. Besides, I tested with a dummy patch (adding just a newline in visual.c), similar failure is there: https://testbot.winehq.org/JobDetails.pl?Key=32779. On 08/23/2017 05:33 PM, Marvin wrote: > 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=32778 > > Your paranoid android. > > > === w8 (32 bit visual) === > visual.c:7975: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 > > === w1064 (64 bit visual) === > visual.c:8023: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). >

Aug. 23, 2017

Re: JACK driver for WINE

by Andrew Eikum

On Fri, Aug 18, 2017 at 02:07:29PM -0600, Jeremy Banks wrote: > I noticed those .spec files in the driver sources. I've been trying to put > together a mental model of how the drivers in Wine work. I noticed the first > function on each line wasn't in the driver source file, but often the 2nd > function was (though the ones in the MMDevAPI section do have nigh-identical > names). Do I correctly understand that for a line in the .spec file, the > first function listed is the function that will be called by MMDevAPi or the > application, and the second one is the function that the former will be > translated to? Do I correctly understand that the driver files thus contain > the translated function calls, plus any additional necessary support > functions and data structure needed for getting data to and from the audio > system in question? > Right. Our mmdevapi loads functions from the drivers and calls them to do stuff like determine which driver to use, and to create the IMMDevice and IAudioClient objects. > It occurs to me that since Wine interfaces with Windows applications, I > might want to study the documentation for the Windows sound and driver APIs. > Is this a correct assumption, or is this not particularly necessary in this > case? > Yes, you'll need to understand the APIs that you will be implementing. You don't need to dig into Windows DDK stuff, our drivers operate at a higher level than that. MSDN's mmdevapi docs are pretty good, and you can always reference the other Wine drivers to see how they implement the functions. Andrew

Aug. 23, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

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=32778 Your paranoid android. === w8 (32 bit visual) === visual.c:7975: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 === w1064 (64 bit visual) === visual.c:8023: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

Aug. 23, 2017

Issue with suspended process

by Jon Doron

Hi all, I have an application that is creating a process suspended and then using detours modifies the imports of the new process prior to resuming it (the application is called Tracker.exe and is part of MS toolchain, it can be retrieved in MS EWDK package) The application does not work as it should on Wine, as the DLL its trying to inject to the new process is not getting loaded, I tracked down the problem here are the technical details: When a new process is created, after all the other set-ups its running the function: dlls/ntdll/server.c!server_init_process_done This function sets up the handlers for the different signals (signal_init_process) and makes a wine_server_call init_process_done. In the wine server function server/process.c!init_process_done a check is made to see if the thread of the process needs to be suspended (stop_thread_if_suspended) and indeed when a process is created with the CREATE_SUSPENDED flag, thread->suspend == 1, process->suspend == 0, and the process state is done at this point). This makes the wine_server call to stop_thread which will send a SIGUSR1 signal to the new process. The new process however still have the signals in a block state, thus not processing the signal and putting it into a pending state. The next thing that happens is LdrInitializeThunk continues and fixing up the EXE module imports, this is not the same behavior as Windows in which the Ldr only starts running after the thread has resumed. Only later signals are being unblocked and then the thread enters a suspended state, the function which unblocks the signals today is attach_process_dlls The interesting thing is that in the past Wine behavior was correct and the change that basically broke it is commit: commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Nov 19 14:27:07 2007 +0100 ntdll: Unblock signals in process init only after the dlls have been imported. Unfortunately though there I could not find any reason why the change was made or if there is any bug that it fixed back then (2007) . I was thinking that perhaps in order to resolve the problem and be closer in the behavior to Windows would be to unblock the signals just before server_init_process_done returns. Please let me know if you have any other questions, will be happy to resolve this now that we have all the information laid out. Thanks, -- Jon.

Aug. 23, 2017

Re: Killing https://www.winehq.org/docs/wineusr-guide

by Austin English

Thanks Newman! On Tue, Aug 22, 2017 at 10:23 AM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > Removed now. A redirect is in place to force to the new location. > > > On 08/20/2017 07:00 AM, Rosanne DiMesio wrote: >> >> On Sat, 19 Aug 2017 22:16:41 -0500 >> Austin English <austinenglish(a)gmail.com> wrote: >> >>> >>> I saw on https://bugs.winehq.org/show_bug.cgi?id=43525 that wineusr-guide >>> is deprecated (which I realized), but I didn't realize it was still up. >>> Would you (or anyone else) be opposed to completely removing it? IMO it's >>> doing more harm than good, especially without a deprecated notice on it. >>> >> It should be removed. >> > > -- -Austin GPG: 14FB D7EA A041 937B

Aug. 22, 2017

Re: Killing https://www.winehq.org/docs/wineusr-guide

by Jeremy Newman

Removed now. A redirect is in place to force to the new location. On 08/20/2017 07:00 AM, Rosanne DiMesio wrote: > On Sat, 19 Aug 2017 22:16:41 -0500 > Austin English <austinenglish(a)gmail.com> wrote: > >> >> I saw on https://bugs.winehq.org/show_bug.cgi?id=43525 that wineusr-guide >> is deprecated (which I realized), but I didn't realize it was still up. >> Would you (or anyone else) be opposed to completely removing it? IMO it's >> doing more harm than good, especially without a deprecated notice on it. >> > It should be removed. >

Aug. 22, 2017

Filling in ARM64 ABI structs

by Martin Storsjö

Hi, I've noticed that some of the ABI specific structs for ARM64 are incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h (not yet available) and _CONTEXT (not missing but only has got made-up content so far) and associated CONTEXT_* defines, and structs like RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h. As far as I know, these structs should be available in the win10 sdk. (MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT struct at least). In order not to accidentally make myself uneligible for contributing code on these matters, I've tried to not look at the sdk. Can someone help out with completeing these data structures according to whatever clean-room guidelines are required? When looking at existing code with git blame, they mostly appear as such without any further explanation on how they were derived, so I'm taking the more cautious route here. // Martin

Aug. 22, 2017

Re: [PATCH 4/4] mshtml: Added delayed DispatchEx init support and use it to expose IHTMLDOMNode3 from document node.

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=32755 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

Aug. 21, 2017

Re: Killing https://www.winehq.org/docs/wineusr-guide

by Rosanne DiMesio

On Sat, 19 Aug 2017 22:16:41 -0500 Austin English <austinenglish(a)gmail.com> wrote: > > I saw on https://bugs.winehq.org/show_bug.cgi?id=43525 that wineusr-guide > is deprecated (which I realized), but I didn't realize it was still up. > Would you (or anyone else) be opposed to completely removing it? IMO it's > doing more harm than good, especially without a deprecated notice on it. > It should be removed. -- Rosanne DiMesio dimesio(a)earthlink.net

Aug. 20, 2017

Killing https://www.winehq.org/docs/wineusr-guide

by Austin English

Hi Rosanne, I saw on https://bugs.winehq.org/show_bug.cgi?id=43525 that wineusr-guide is deprecated (which I realized), but I didn't realize it was still up. Would you (or anyone else) be opposed to completely removing it? IMO it's doing more harm than good, especially without a deprecated notice on it. -- -Austin GPG: 14FB D7EA A041 937B

Aug. 20, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Fabian Maurer

Hi Alistair, > >You mean for example the DirectShow interfaces like > >"IAMCertifiedOutputProtection" "IMediaEventSink" and so on? > > No, QI will also need to check for the following interfaces > IMediaFilter, IPersist. > > e.g. > IBaseFilter -> IMediaFilter-> IPersist -> IUnknown Right, I overlooked that, will add a check for those. Thanks for explaining. On a sitenote, MSDN states that EnhancedVideoRenderer exposes a lot more interfaces than just IBaseFilter. It's a similar issue with VideoMixingRenderer in quartz/vmr9.c: > static const IUnknownVtbl IInner_VTable = > { > VMR9Inner_QueryInterface, > VMR9Inner_AddRef, > VMR9Inner_Release > }; Maybe I should rework it like that? Having one unknown interface that is only used to query all the other interfaces. Regards, Fabian Maurer

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Alistair Leslie-Hughes

Hi Fabian, >You mean for example the DirectShow interfaces like >"IAMCertifiedOutputProtection" "IMediaEventSink" and so on? No, QI will also need to check for the following interfaces IMediaFilter, IPersist. e.g. IBaseFilter -> IMediaFilter-> IPersist -> IUnknown Best Regards Alistair.

Aug. 18, 2017

Re: JACK driver for WINE

by Jeremy Banks

On 08/18/2017 06:55 AM, Andrew Eikum wrote: > Hey Jeremy, thanks for your interest! Like Austin said, I do most of > the audio stuff in Wine these days, so you'll probably be working > mostly with me. Thank you for taking the time to reply. I noticed that a reply was going directly to you, instead of the mailing list, and so hit reply-all. If this was supposed to be an off-list conversation, I apologize, and will direct future replies directly to you. > First, I'd request that you try out the alternatives to implementing a > driver. I don't know what your requirements are, but there are > existing solutions for running PulseAudio on top of JACK. I'm not > super familiar with JACK, but I think you'll want to follow the > "Redirecting PulseAudio to JACK" section here[1], then make sure Wine > is using the winepulse driver. > > If that doesn't meet your requirements, you could also try redirecting > winealsa to JACK, see[2,3]. This may have lower latency than running > PA. My use case is recording videos of applications running under Wine, often alongside my running commentary. I initially did use the winepulse driver, as most applications on my computer use PA for general sound (some require it). JACK gets used when I'm wanting to capture audio from my external audio interface, capture multiple sources synchronously so to reduce the amount of manual aligning I have to do when editing and mixing, or during said editing and mixing. As I run both Pulse and Jack, I initially was using the PA -> JACK setup you linked below[1], as it seemed the simplest/easiest solution. However, I became displeased with that when I discovered that the PA -> JACK bridge was prone to random buffer under/over runs, even with relatively large buffer settings in JACK, and that it would drift out of sync over longer periods of time. I did take a look at the guides you linked at [3], but was left with the impression that doing so would bring even more complexity to the sound setup on my computer, leaving more opportunity for mis-configuration or breakage. It occurred to me that perhaps the Right Thing would be to have Wine talking to JACK natively. When I looked into this and found that Wine did have a JACK driver at one point previously, I thought, "It was done before. How hard could it be?" (Yes, I know that's a dangerous line of thinking :). ) > The reason we resist adding new drivers is it adds a lot of work for > the maintainers (i.e., me). I test each significant change to any part > of our audio code on all four of our existing drivers (ALSA, OSS, > PulseAudio, and macOS's CoreAudio), both by running the Wine unit > tests and by testing all of the many audio applications I have that > use the relevant APIs. On top of the testing itself, that means I have > to understand how to run and maintain all four of those audio systems > on my hardware. Further, any bug fixed or new feature added to one > driver has to be understood and replicated in all other drivers, if > applicable. > > So you can see why I'd request you try existing solutions before > jumping straight to a new audio driver. If you can convince me that > existing solutions don't work for your requirements, then we can talk > about adding a new driver to Wine. I'd at least like to be convinced > that you've already tried alternatives and understand why they are > unacceptable for your usecase. I understand why you'd be reluctant to add another driver and can sympathize about maintenance burden it would impose. I'd hoped that if I could implement such a driver correctly, it wouldn't impose an undue maintenance burden, and the ability to now talk natively to JACK would be worth it. If you ultimately decide you do not want a JACK driver, I'm tempted to try to implement one anyway, even if it stays my own private patch and never makes it upstream. After looking at the Wine source and the JACK documentation, my curiosity is thoroughly piqued. Even if nothing ever comes of it, odds are I'll learn something, which is seldom a bad thing. > Once you get over that hurdle, you'll need to implement a winejack.drv > similar to winealsa, winepulse, winecoreaudio, or wineoss. You'll want > to copy whichever is closest to JACK's API and then modify it to use > JACK. winealsa and wineoss operate in push mode (we maintain our own > timers to keep the audio buffer full). winepulse and winecoreaudio are > in pull mode (the audio system asks us to provide it with data). I > don't recall which type of API JACK is. I'll need to research this more to understand the distinction between the two. I know that JACK's API is implemented with callbacks, the main one being a process callback that JACK calls regularly when it wants a program to move data in or out of its buffers. > At a very high level, you'll need to implement all of the functions in > the .spec file. You can look into the existing drivers to understand > what those APIs do. The audio drivers export a few COM interfaces, > which are used directly by applications or by dsound, winmm, and some > other modules. The really important interfaces are IAudioClient, > IAudioRenderClient, IAudioCaptureClient, and IAudioClock, and there > are a few lesser-used interfaces besides. > > Once you've implemented those interfaces, they'll need to pass the > tests mentioned on the wiki page. I noticed those .spec files in the driver sources. I've been trying to put together a mental model of how the drivers in Wine work. I noticed the first function on each line wasn't in the driver source file, but often the 2nd function was (though the ones in the MMDevAPI section do have nigh-identical names). Do I correctly understand that for a line in the .spec file, the first function listed is the function that will be called by MMDevAPi or the application, and the second one is the function that the former will be translated to? Do I correctly understand that the driver files thus contain the translated function calls, plus any additional necessary support functions and data structure needed for getting data to and from the audio system in question? It occurs to me that since Wine interfaces with Windows applications, I might want to study the documentation for the Windows sound and driver APIs. Is this a correct assumption, or is this not particularly necessary in this case? > [1] https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Pul… > > [2] https://wiki.winehq.org/Sound#What_about_JACK.3F > > [3] http://jackaudio.org/faq/routing_alsa.html > > Andrew Regards, Jeremy

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Fabian Maurer

> >> Shouldn't it use strmbase? > > > > You mean the methods that for example quartz/nullrenderer.c uses in > > NullRenderer_Vtbl? > > I'm not sure, that's why I just stubbed them. > > I mean BaseFilter from strmbase. Ah you mean I shouldn't implement this interface by myself, but just return a BaseFilter object? I'm not sure how I would test against that to make sure it actually is a BaseFilter and not something different. > >> This needs at test for aggregation support. > > > > Sorry I don't know what you mean. Care to elaborate? > > I mean a test to show if it's supported or not. Currently you ignore > outer interface argument. Take a look at qcap for example. I see, I never heard of COM aggregation before, so I first need to read into it. > I mean if there's no reason, why should it be in a header. > Using just "%p" is enough for pointers, you don't need extra prefix. > I personally don't think d3dxof is a good place to look for examples. > But anyway copied parts should get some cleanup and not be taken for > granted. XF prefix for example could possibly be an acronym for > directXFile, and that does not apply to anything but d3dxof. Makes sense, I will rework that. Regards, Fabian Maurer

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Nikolay Sivov

On 18.08.2017 20:01, Fabian Maurer wrote: > Hi, thanks for your feedback. > >> Shouldn't it use strmbase? > > You mean the methods that for example quartz/nullrenderer.c uses in > NullRenderer_Vtbl? > I'm not sure, that's why I just stubbed them. I mean BaseFilter from strmbase. > >> This needs at test for aggregation support. > > Sorry I don't know what you mean. Care to elaborate? I mean a test to show if it's supported or not. Currently you ignore outer interface argument. Take a look at qcap for example. > >>> +typedef struct { >>> + IBaseFilter IBaseFilter_iface; >>> + LONG ref; >>> +} EnhancedVideoRendererImpl; >> >> Does this need to be exposed? > > You mean I shouldn't need to put that in a header? I just did it like in > d3dxof, and it's the same in uiribbon. But yes, I could change that. I mean if there's no reason, why should it be in a header. > >>> + TRACE("(0x%p, %d, %p)\n", instance, reason, reserved); >>> + >> Format looks wrong. > > Already used that in my uiribbon patch and it was fine though. What should I > change about it? Using just "%p" is enough for pointers, you don't need extra prefix. > >> What does XF prefix stand for? Also please use consistent type names and >> formatting. >> >> I personally don't think this export needs a documentation header. >> >> I think it's better to let QueryInterface handle this. > > I just copied that code from d3dxof, I figured it was ok since it was accepted > into my uiribbon patch. Should I change it? I personally don't think d3dxof is a good place to look for examples. But anyway copied parts should get some cleanup and not be taken for granted. XF prefix for example could possibly be an acronym for directXFile, and that does not apply to anything but d3dxof. > >>> + for (i=0; i < sizeof(object_creation)/sizeof(object_creation[0]); >>> i++) >>> + { >>> + if (IsEqualGUID(object_creation[i].clsid, rclsid)) >>> + break; >>> + } >>> + >>> + if (i == sizeof(object_creation)/sizeof(object_creation[0])) >>> + { >>> + FIXME("%s: no class found.\n", debugstr_guid(rclsid)); >>> + return CLASS_E_CLASSNOTAVAILABLE; >>> + } >> >> Does it support any other CLSIDs? This seems like too much. Static >> factory instance will work too I suppose. > > According to my windows7 registry, yes, there are other CLSIDs in that dll, > like "MF Video Mixer" and "Tearless Window Presenter" for example. Ok, then this structure is fine I guess. Thanks for checking. > Not sure what exactly static factory instance means. I mean a static, non-heap allocated, instance. But that's minor. > > Regards, > Fabian Maurer > >

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Fabian Maurer

Hi, thanks for your feedback. > Shouldn't it use strmbase? You mean the methods that for example quartz/nullrenderer.c uses in NullRenderer_Vtbl? I'm not sure, that's why I just stubbed them. > This needs at test for aggregation support. Sorry I don't know what you mean. Care to elaborate? > > +typedef struct { > > + IBaseFilter IBaseFilter_iface; > > + LONG ref; > > +} EnhancedVideoRendererImpl; > > Does this need to be exposed? You mean I shouldn't need to put that in a header? I just did it like in d3dxof, and it's the same in uiribbon. But yes, I could change that. > > + TRACE("(0x%p, %d, %p)\n", instance, reason, reserved); > > + > Format looks wrong. Already used that in my uiribbon patch and it was fine though. What should I change about it? > It still doesn't do anything. Yes, I'll re-add that. > What does XF prefix stand for? Also please use consistent type names and > formatting. > > I personally don't think this export needs a documentation header. > > I think it's better to let QueryInterface handle this. I just copied that code from d3dxof, I figured it was ok since it was accepted into my uiribbon patch. Should I change it? > > + for (i=0; i < sizeof(object_creation)/sizeof(object_creation[0]); > > i++) > > + { > > + if (IsEqualGUID(object_creation[i].clsid, rclsid)) > > + break; > > + } > > + > > + if (i == sizeof(object_creation)/sizeof(object_creation[0])) > > + { > > + FIXME("%s: no class found.\n", debugstr_guid(rclsid)); > > + return CLASS_E_CLASSNOTAVAILABLE; > > + } > > Does it support any other CLSIDs? This seems like too much. Static > factory instance will work too I suppose. According to my windows7 registry, yes, there are other CLSIDs in that dll, like "MF Video Mixer" and "Tearless Window Presenter" for example. Not sure what exactly static factory instance means. Regards, Fabian Maurer

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Fabian Maurer

Hi Alistair, > Your missing some IID checks here. You mean for example the DirectShow interfaces like "IAMCertifiedOutputProtection" "IMediaEventSink" and so on? I skipped them for now, because they are not needed to fix that particular bug. Do I have to add all of them at once? Regards, Fabian Maurer

Aug. 18, 2017

Re: [1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 18.08.2017 13:41, Dmitry Timoshkov wrote: > > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > > --- > > dlls/user32/tests/dialog.c | 6 ++++++ > > dlls/user32/tests/resource.rc | 6 ++++++ > > 2 files changed, 12 insertions(+) > > > > There is no need to resubmit, the patches are exactly identical to > what Andrew submitted. Also, why the hell is there my sign-off? It is > apparently not fine for you when Andrew wants to take responsiblity > for your patches, but you expect me to take responsibility for it, > without confirming that I'm fine with it first? For other people I > would now start to explain that Wine Staging also accepts workarounds > and imperfect patches, and that the addition to Wine Staging does not > imply my sign-off, but I'm pretty sure you are well aware of it... I'm sorry about adding your sign-off, probably I should have longer waiting for your reply before submitting, and apparently I was too optimistic about implicit sign-off of the wine-staging maintainer when adding the patches... -- Dmitry.

Aug. 18, 2017

Re: [1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

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=32738 Your paranoid android. === w7u (32 bit msg) === msg.c:5084: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 11: the msg 0x001c was expected, but got msg 0x0047 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 12: the msg 0x0086 was expected, but got msg 0x001c instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 13: the msg 0x0006 was expected, but got msg 0x0086 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 18: the msg 0x0009 was expected, but got msg 0x0006 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 19: the msg 0x0007 was expected, but got msg 0x0009 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 20: the msg 0x0047 was expected, but got msg 0x0007 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 21: the msg 0x0003 was expected, but got msg 0x0047 instead msg.c:5207: Test failed: SetWindowPos:show_popup_first_show_window: 22: the msg sequence is not complete: expected 0000 - actual 0003 === wvistau64 (32 bit listbox) === listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === wvistau64 (64 bit listbox) === listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === w864 (32 bit broadcast) === The task timed out === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit sysparams) === sysparams.c:206: Test failed: Unexpected WM_DISPLAYCHANGE message === w864 (64 bit sysparams) === The task timed out

Aug. 18, 2017

Re: [1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Sebastian Lackner

On 18.08.2017 13:41, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/user32/tests/dialog.c | 6 ++++++ > dlls/user32/tests/resource.rc | 6 ++++++ > 2 files changed, 12 insertions(+) > There is no need to resubmit, the patches are exactly identical to what Andrew submitted. Also, why the hell is there my sign-off? It is apparently not fine for you when Andrew wants to take responsiblity for your patches, but you expect me to take responsibility for it, without confirming that I'm fine with it first? For other people I would now start to explain that Wine Staging also accepts workarounds and imperfect patches, and that the addition to Wine Staging does not imply my sign-off, but I'm pretty sure you are well aware of it...

Aug. 18, 2017

Re: JACK driver for WINE

by Andrew Eikum

On Thu, Aug 17, 2017 at 01:14:00PM -0600, Jeremy Banks wrote: > I am wanting to output the audio from various applications run in WINE to > the JACK server on my computer. I would prefer that WINE do this natively > instead of routing across various wrapper setups with ALSA or PulseAudio. I > have looked on the WINE wiki page for sound[1] and see that there was a > JACK driver at one point, but it was removed when the driver architecture > was changed. > Hey Jeremy, thanks for your interest! Like Austin said, I do most of the audio stuff in Wine these days, so you'll probably be working mostly with me. First, I'd request that you try out the alternatives to implementing a driver. I don't know what your requirements are, but there are existing solutions for running PulseAudio on top of JACK. I'm not super familiar with JACK, but I think you'll want to follow the "Redirecting PulseAudio to JACK" section here[1], then make sure Wine is using the winepulse driver. If that doesn't meet your requirements, you could also try redirecting winealsa to JACK, see[2,3]. This may have lower latency than running PA. The reason we resist adding new drivers is it adds a lot of work for the maintainers (i.e., me). I test each significant change to any part of our audio code on all four of our existing drivers (ALSA, OSS, PulseAudio, and macOS's CoreAudio), both by running the Wine unit tests and by testing all of the many audio applications I have that use the relevant APIs. On top of the testing itself, that means I have to understand how to run and maintain all four of those audio systems on my hardware. Further, any bug fixed or new feature added to one driver has to be understood and replicated in all other drivers, if applicable. So you can see why I'd request you try existing solutions before jumping straight to a new audio driver. If you can convince me that existing solutions don't work for your requirements, then we can talk about adding a new driver to Wine. I'd at least like to be convinced that you've already tried alternatives and understand why they are unacceptable for your usecase. > I am interested in trying to implement a driver to get WINE talking to JACK > natively. The wiki says to ask on the mailing list before starting such a > project, and so here I am. I have downloaded a local copy of the source repo > and have started browsing through its contents. Being unfamiliar with the > WINE codebase, which portions of the source should I start studying first? I > am interested in studying the drivers for ALSA, OSS, and Pulse for > comparison; do those live in a particular place in the source tree? I'm > presently looking on the Wiki for other helpful information, but is there > some particular documentation I should be studying for this endeavor? > Once you get over that hurdle, you'll need to implement a winejack.drv similar to winealsa, winepulse, winecoreaudio, or wineoss. You'll want to copy whichever is closest to JACK's API and then modify it to use JACK. winealsa and wineoss operate in push mode (we maintain our own timers to keep the audio buffer full). winepulse and winecoreaudio are in pull mode (the audio system asks us to provide it with data). I don't recall which type of API JACK is. At a very high level, you'll need to implement all of the functions in the .spec file. You can look into the existing drivers to understand what those APIs do. The audio drivers export a few COM interfaces, which are used directly by applications or by dsound, winmm, and some other modules. The really important interfaces are IAudioClient, IAudioRenderClient, IAudioCaptureClient, and IAudioClock, and there are a few lesser-used interfaces besides. Once you've implemented those interfaces, they'll need to pass the tests mentioned on the wiki page. [1] https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Pul… [2] https://wiki.winehq.org/Sound#What_about_JACK.3F [3] http://jackaudio.org/faq/routing_alsa.html Andrew

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Alistair Leslie-Hughes

Hi Fabian, On 18/08/17 11:25, Fabian Maurer wrote: > + if (IsEqualGUID(riid, &IID_IUnknown) > + || IsEqualGUID(riid, &IID_IBaseFilter)) > + { Your missing some IID checks here. Alistair.

Aug. 18, 2017

Re: [PATCH] evr: Add stubs for EnhancedVideoRenderer

by Nikolay Sivov

On 18.08.2017 4:25, Fabian Maurer wrote: > +static const IBaseFilterVtbl IBaseFilter_Vtbl = > +{ > + /*** IUnknown methods ***/ > + EnhancedVideoRendererImpl_QueryInterface, > + EnhancedVideoRendererImpl_AddRef, > + EnhancedVideoRendererImpl_Release, > + /*** IPersist methods ***/ > + EnhancedVideoRendererImpl_GetClassID, > + /*** IMediaFilter methods ***/ > + EnhancedVideoRendererImpl_Stop, > + EnhancedVideoRendererImpl_Pause, > + EnhancedVideoRendererImpl_Run, > + EnhancedVideoRendererImpl_GetState, > + EnhancedVideoRendererImpl_SetSyncSource, > + EnhancedVideoRendererImpl_GetSyncSource, > + /*** IBaseFilter methods ***/ > + EnhancedVideoRendererImpl_EnumPins, > + EnhancedVideoRendererImpl_FindPin, > + EnhancedVideoRendererImpl_QueryFilterInfo, > + EnhancedVideoRendererImpl_JoinFilterGraph, > + EnhancedVideoRendererImpl_QueryVendorInfo > +}; Shouldn't it use strmbase? > +HRESULT EnhancedVideoRendererImpl_Create(IUnknown *pUnkOuter, void **ppObj) > +{ > + EnhancedVideoRendererImpl *object; > + > + TRACE("(%p,%p)\n", pUnkOuter, ppObj); > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(EnhancedVideoRendererImpl)); > + if (!object) > + return E_OUTOFMEMORY; > + > + object->IBaseFilter_iface.lpVtbl = &IBaseFilter_Vtbl; > + object->ref = 1; > + > + *ppObj = &object->IBaseFilter_iface; > + > + return S_OK; > +} This needs at test for aggregation support. > +typedef struct { > + IBaseFilter IBaseFilter_iface; > + LONG ref; > +} EnhancedVideoRendererImpl; Does this need to be exposed? > + TRACE("(0x%p, %d, %p)\n", instance, reason, reserved); > + Format looks wrong. > - case DLL_WINE_PREATTACH: > - return FALSE; /* prefer native version */ It still doesn't do anything. > +static HRESULT WINAPI XFCF_QueryInterface(LPCLASSFACTORY iface,REFIID riid, void **ppobj) > +{ What does XF prefix stand for? Also please use consistent type names and formatting. > +/******************************************************************************* > + * Retrieves class object from a DLL object > + * > + * NOTES > + * Docs say returns STDAPI > + * > + * PARAMS > + * rclsid [I] CLSID for the class object > + * riid [I] Reference to identifier of interface for class object > + * ppv [O] Address of variable to receive interface pointer for riid > + * > + * RETURNS > + * Success: S_OK > + * Failure: CLASS_E_CLASSNOTAVAILABLE, E_OUTOFMEMORY, E_INVALIDARG, > + * E_UNEXPECTED > + */ > +HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) I personally don't think this export needs a documentation header. > + if ( !IsEqualGUID( &IID_IClassFactory, riid ) > + && ! IsEqualGUID( &IID_IUnknown, riid) ) > + return E_NOINTERFACE; I think it's better to let QueryInterface handle this. > + for (i=0; i < sizeof(object_creation)/sizeof(object_creation[0]); i++) > + { > + if (IsEqualGUID(object_creation[i].clsid, rclsid)) > + break; > + } > + > + if (i == sizeof(object_creation)/sizeof(object_creation[0])) > + { > + FIXME("%s: no class found.\n", debugstr_guid(rclsid)); > + return CLASS_E_CLASSNOTAVAILABLE; > + } Does it support any other CLSIDs? This seems like too much. Static factory instance will work too I suppose.

Aug. 18, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

On Thu, Aug 17, 2017 at 9:35 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: > And the reason it didn't crash with v1 is that the whole chain of > releases (from fontface to factory, file, etc) was protected by lock. > While this version releases the lock after removing fontface from the > cache. Sorry, this is wrong. It actually should've crashed even with v1 (and now that I think of it I think I did get couple of crashes in this codepath even with v1). So I guess with this patch for w/e reason timing have changed and that different race became more likely. And this is fine, but fontfile should be protected as well.

Aug. 18, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

On Thu, Aug 17, 2017 at 11:14 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 17.08.2017 10:40, Sebastian Lackner wrote: >> On 17.08.2017 07:11, Anton Romanov wrote: >>> On Wed, Aug 16, 2017 at 10:05 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: >>>> On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >>>>> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >>>>> --- >>>>> dlls/dwrite/dwrite_private.h | 15 ++++++++--- >>>>> dlls/dwrite/font.c | 30 +++++++++++++-------- >>>>> dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- >>>>> 3 files changed, 74 insertions(+), 34 deletions(-) So I dived a bit deeper into that and it looks like there is now a race for fontfile: 004c:trace:dwrite:dwritefontface_Release (0x189c09a0)->(0) 005c:trace:dwrite:dwritefontface_GetSimulations (0x189c09a0) 005c:trace:dwrite:dwritefontface_GetFiles (0x189c09a0)->(0xa5fe400 0xa5fe408) 005c:trace:dwrite:dwritefontfile_AddRef (0x15cf7f00)->(3) 005c:trace:dwrite:dwritefontfile_GetReferenceKey (0x15cf7f00)->(0xa5fe404, 0xa5fe3fc) 005c:trace:dwrite:dwritefontfile_Release (0x15cf7f00)->(2) 005c:trace:dwrite:dwritefontface_QueryInterface (0x189c09a0)->({27f2a904-4eb8-441d-9678-0563f53e3e2f} 0xa5fe57c) 005c:warn:dwrite:factory_get_cached_fontface Failed to get {27f2a904-4eb8-441d-9678-0563f53e3e2f} from fontface, hr 0x80004005. 005c:trace:dwrite:factory_get_cached_fontface returning cached fontface 0x189c09a0 005c:trace:dwrite:shareddwritefactory_AddRef (0x3a0cf18) 004c:trace:dwrite_file:localfontfilestream_Release (0x1633b128)->(0) 005c:trace:dwrite:dwritefontfile_GetLoader (0x15cf7f00)->(0xa5fe408) 005c:trace:dwrite:localfontfileloader_AddRef (0x15cf5108)->(225) 005c:trace:dwrite:dwritefontfile_GetReferenceKey (0x15cf7f00)->(0xa5fe410, 0xa5fe40c) 005c:trace:dwrite:localfontfileloader_CreateStreamFromKey (0x15cf5108)->(0x15cf8fc0, 64, 0x1633aff8) 005c:trace:dwrite:localfontfileloader_CreateStreamFromKey name: L"C:\\windows\\fonts\\Ariali.TTF" 005c:trace:dwrite_file:localfontfilestream_AddRef (0x1633b128)->(1) 005c:trace:dwrite:localfontfileloader_Release (0x15cf5108)->(224) 005c:trace:dwrite:get_stream_from_file 0x15cf7f00 -> 0x1633b128 005c:trace:dwrite:dwritefontfile_AddRef (0x15cf7f00)->(3) 005c:trace:dwrite_file:localfontfilestream_ReadFileFragment (0x1633b128)->(0xa5fe318, 0x0, 0xc, 0xa5fe31c) The crash is in thread 5c with backtrace being: =>0 0x7d442918 opentype_get_font_table+0xa8(stream_desc=0xa5fe410, tag=0x322f534f, table_data=0xa5fe39c, table_context=0xa5fe38c, table_size=0x0(nil), found=0x0(nil)) [/home/theli/Projects/wine-build/32/dlls/dwrite/../../../../wine/dlls/dwrite/opentype.c:1075] in dwrite (0x0a5fe338) 1 0x7d442f0e opentype_get_font_metrics+0x5d(stream_desc=<is not available>, metrics=<is not available>, caret=<is not available>) [/home/theli/Projects/wine-build/32/dlls/dwrite/../../../../wine/dlls/dwrite/opentype.c:1209] in dwrite (0x0a5fe3b8) 2 0x7d42a089 create_fontface+0x2c8(desc=0xa5fe470, cached_list=0x3a0cf34, ret=0xa5fe57c) [/home/theli/Projects/wine-build/32/dlls/dwrite/../../../../wine/dlls/dwrite/font.c:4354] in dwrite (0x0a5fe438) 3 0x7d42a396 get_fontface_from_font.isra+0xb5() in dwrite (0x0a5fe4a8) 4 0x7d42a420 dwritefont3_CreateFontFace+0x5f(iface=<couldn't compute location>, fontface=<couldn't compute location>) [/home/theli/Projects/wine-build/32/dlls/dwrite/../../../../wine/dlls/dwrite/font.c:1674] in dwrite (0x0a5fe4d8) 5 0x7d41d42b dwritefont_CreateFontFace+0x5a(iface=<couldn't compute location>, fontface=<couldn't compute location>) [/home/theli/Projects/wine-build/32/dlls/dwrite/../../include/dwrite_3.h:1208] in dwrite (0x0a5fe518) And the reason it didn't crash with v1 is that the whole chain of releases (from fontface to factory, file, etc) was protected by lock. While this version releases the lock after removing fontface from the cache. Also with this patch the line TRACE("returning cached fontface %p\n", cached->fontface); Should probably be under the else branch as it outputs this regardless of whether it actually acquired a reference.

Aug. 18, 2017

Re: JACK driver for WINE

by Austin English

On Thu, Aug 17, 2017 at 2:14 PM, Jeremy Banks <korethr(a)gmail.com> wrote: > Hello all, > > I am wanting to output the audio from various applications run in WINE to > the JACK server on my computer. I would prefer that WINE do this natively > instead of routing across various wrapper setups with ALSA or PulseAudio. I > have looked on the WINE wiki page for sound[1] and see that there was a > JACK driver at one point, but it was removed when the driver architecture > was changed. > > I am interested in trying to implement a driver to get WINE talking to JACK > natively. The wiki says to ask on the mailing list before starting such a > project, and so here I am. I have downloaded a local copy of the source repo > and have started browsing through its contents. Being unfamiliar with the > WINE codebase, which portions of the source should I start studying first? I > am interested in studying the drivers for ALSA, OSS, and Pulse for > comparison; do those live in a particular place in the source tree? I'm > presently looking on the Wiki for other helpful information, but is there > some particular documentation I should be studying for this endeavor? Hi Jeremy, You're looking for https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winealsa.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/wineandroid.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winecoreaudio.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/wineoss.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winepulse.drv note that a lot of the sound code is in mmdevapi: https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/mmdevapi Andrew Eikum maintains wine's sound infrastructure, he's the guy you want if you have more involved questions. Good luck! -- -Austin GPG: 14FB D7EA A041 937B

Aug. 17, 2017

Re: [PATCH] comctl32/listview: Keep the active item selected after hwndEdit is destroyed

by Nikolay Sivov

On 10.08.2017 7:54, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/listview.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index 73eceff509..05bd375571 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -10216,6 +10216,7 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, IN > static BOOL bGroupSelect = TRUE; > POINT pt = { x, y }; > INT nItem; > + BOOL editing = FALSE; > > TRACE("(key=%hu, X=%u, Y=%u)\n", wKey, x, y); > > @@ -10309,11 +10310,20 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, IN > else > { > if (!infoPtr->bFocus) > + { > + editing = IsWindow(infoPtr->hwndEdit); > SetFocus(infoPtr->hwndSelf); > + } > > - /* remove all selections */ > + /* keep the active item selected after hwndEdit is destroyed, or deselect all items */ > if (!(wKey & MK_CONTROL) && !(wKey & MK_SHIFT)) > - LISTVIEW_DeselectAll(infoPtr); > + { > + if (editing) > + LISTVIEW_DeselectAllSkipItem(infoPtr, infoPtr->nFocusedItem); > + else > + LISTVIEW_DeselectAll(infoPtr); > + } > + Maybe this could be reduced to a single unconditional call: LISTVIEW_DeselectAllSkipItem(infoPtr, infoPtr->nEditLabelItem); > ReleaseCapture(); > } > >

Aug. 17, 2017

Re: [PATCH resend] msxml3: Remove CRs in domtext_put_data and add them in domtext_get_xml.

by Nikolay Sivov

On 03.08.2017 18:17, Alex Henrie wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=42468 > > To be clear, I am not trying to fix all whitespace processing issues. I > am only trying to prevent "" from being erroneously inserted into > the output. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/msxml3/tests/domdoc.c | 106 +++++++++++++++++++++++++++++++++++++-------- > dlls/msxml3/text.c | 42 +++++++++++++++--- > 2 files changed, 122 insertions(+), 26 deletions(-) > > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c I think it needs more tests, for xml:space and put_preserveWhiteSpace(). > diff --git a/dlls/msxml3/text.c b/dlls/msxml3/text.c > index 3a12d4bf62..6814c1f817 100644 > --- a/dlls/msxml3/text.c > +++ b/dlls/msxml3/text.c > @@ -519,10 +519,15 @@ static HRESULT WINAPI domtext_get_xml( > BSTR* p) > { > domtext *This = impl_from_IXMLDOMText( iface ); > + HRESULT hr; > > TRACE("(%p)->(%p)\n", This, p); > > - return node_get_xml(&This->node, FALSE, p); > + hr = node_get_xml(&This->node, FALSE, p); > + if (hr == S_OK) > + *p = EnsureCorrectEOL(*p); > + > + return hr; Will node_get_xml(..., TRUE, ...) work? > } > > static HRESULT WINAPI domtext_transformNode( > @@ -616,15 +621,38 @@ static HRESULT WINAPI domtext_put_data( > BSTR data) > { > domtext *This = impl_from_IXMLDOMText( iface ); > - static const WCHAR rnW[] = {'\r','\n',0}; > + BSTR normalized_data = NULL; > + HRESULT hr; > + int i, j; > > TRACE("(%p)->(%s)\n", This, debugstr_w(data)); > > - if (data && !strcmpW(rnW, data)) > - This->node.node->name = xmlStringTextNoenc; > - else > - domtext_reset_noenc(This); > - return node_set_content(&This->node, data); > + if (data) > + { > + /* normalize line endings */ > + normalized_data = SysAllocStringLen(NULL, SysStringLen(data)); > + if (!normalized_data) return E_OUTOFMEMORY; > + for (i = 0, j = 0; data[i]; i++) > + { > + if (data[i] == '\r') > + { > + if (data[i + 1] == '\n') > + continue; /* change \r\n to just \n */ > + else > + normalized_data[j] = '\n'; /* change \r by itself to \n */ > + } > + else > + normalized_data[j] = data[i]; > + j++; > + } > + normalized_data[j] = 0; The only purpose for that is to inhibit libxml2 escaping, right? Could this be done the way it is now, but with something more elaborate than comparing to "\r\n"? > + } > + > + domtext_reset_noenc(This); > + hr = node_set_content(&This->node, normalized_data); > + > + SysFreeString(normalized_data); > + return hr; > } > > static HRESULT WINAPI domtext_get_length( >

Aug. 17, 2017

JACK driver for WINE

by Jeremy Banks

Hello all, I am wanting to output the audio from various applications run in WINE to the JACK server on my computer. I would prefer that WINE do this natively instead of routing across various wrapper setups with ALSA or PulseAudio. I have looked on the WINE wiki page for sound[1] and see that there was a JACK driver at one point, but it was removed when the driver architecture was changed. I am interested in trying to implement a driver to get WINE talking to JACK natively. The wiki says to ask on the mailing list before starting such a project, and so here I am. I have downloaded a local copy of the source repo and have started browsing through its contents. Being unfamiliar with the WINE codebase, which portions of the source should I start studying first? I am interested in studying the drivers for ALSA, OSS, and Pulse for comparison; do those live in a particular place in the source tree? I'm presently looking on the Wiki for other helpful information, but is there some particular documentation I should be studying for this endeavor? Regards, Jeremy Banks 1. https://wiki.winehq.org/Sound#Backend_information

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Nikolay Sivov

On 17.08.2017 10:40, Sebastian Lackner wrote: > On 17.08.2017 07:11, Anton Romanov wrote: >> On Wed, Aug 16, 2017 at 10:05 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: >>> On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >>>> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >>>> --- >>>> dlls/dwrite/dwrite_private.h | 15 ++++++++--- >>>> dlls/dwrite/font.c | 30 +++++++++++++-------- >>>> dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- >>>> 3 files changed, 74 insertions(+), 34 deletions(-) >>>> >>> Since apps seem to freely use fontface interfaces from multiple >>> threads - Isn't the following race possible? >>> >>> +----------------+------------------------+-------------------------+ >>> | T1 | T2 | T3 | >>> +----------------+------------------------+-------------------------+ >>> | Release | | | >>> | Decrement | | | >>> | == 0 -> True | | | >>> | | Query_Interface/AddRef | | >>> | | Increment | | > > After the last Release call the app should not be calling any function on > the object directly. > > The only valid code path to obtain a new reference is going through > factory_get_cached_fontface. The code in this function is written in such > a way that it only uses very specific safe methods. Most importantly, > destroyed font faces are skipped, so for properly written apps no race > conditions are possible. > >>> | | | Release | >>> | | | Decrement | >>> | free(cached) | | | >>> | factory_unlock | | | >>> | | | use after free (cached) | >>> +----------------+------------------------+-------------------------+ >> Actually, with this version of the patch looks like this is exactly >> the crash I'm consistently getting now (was fine with v1): >> >> 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(1) >> 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(0) >> 004c:trace:dwrite:dwritefontface_GetFiles (0x97936c8)->(0x339d58 0x339d50) >> 004c:trace:dwrite:dwritefontface_GetIndex (0x97936c8) >> 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("GSUB" >> 0x339e60 0x339e68 0x339e64 0x339e5c) > > It is interesting that there is no "returning cached fontface" in the log > above. This suggests that your interpretation of the error is wrong, the > app basically operates on a destroyed object (or there is an error somewhere > else). > > Does this really work reliable on Windows? If yes it means the current idea > of thread safety is not really sufficient. Maybe Windows preserves cache > entries for some specific time (or for the duration of the factory), even > after the last reference is gone? Or maybe the factory has a reference on > each font face? Yes, it's possible there's some MRU list as well. I'm almost sure factory does not keep a reference, at least not in a way IUnknown exposes it, I'll need to check if we have tests for that, and maybe add some. > >

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

The test bot re-ran all of the tests because the RC file was changed. None of the failures below are in dialog.c. Andrew On Thu, Aug 17, 2017 at 10:26:46AM -0500, Marvin wrote: > 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=32717 > > Your paranoid android. > > > === wvistau64 (32 bit listbox) === > listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 > listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 > > === wvistau64 (64 bit listbox) === > listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 > listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 > > === w864 (64 bit broadcast) === > The task timed out > > === w8 (32 bit sysparams) === > sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 > > === w864 (32 bit sysparams) === > sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Fri, Aug 18, 2017 at 12:08:14AM +0800, Dmitry Timoshkov wrote: > > Please don't try to pretend that you are participating in some process, > > especially when you clearly have no idea what's that. What you are doing > > is stealing the work done by somebody else, admitting at the same time > > that you are not familar with that code. > > > > Golly, I wonder why no one respects you. Thank you mister "no one". I guess that providing good argumentation or investigating a problem and creating a patch that solves it is much more work than stealing somebody else patches and once receiving a complaint start speculating around. -- Dmitry.

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

On Fri, Aug 18, 2017 at 12:08:14AM +0800, Dmitry Timoshkov wrote: > Please don't try to pretend that you are participating in some process, > especially when you clearly have no idea what's that. What you are doing > is stealing the work done by somebody else, admitting at the same time > that you are not familar with that code. > Golly, I wonder why no one respects you. Andrew

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > > > Again, I asked Sebastian to send it on your behalf, precisely to avoid > > > > > this argument. He told me to send it instead, so I did. > > > > > > > > I'd appreciate if you could avoid sending my patches without my permission > > > > in future. Thanks. > > > > > > > > > > If you don't want your code used under the terms of the LGPL then I > > > suggest you stop releasing code under the terms of the LGPL. > > > > Once again: it's not about licensing, it's about respect. You had > > admitted in the private e-mail (when you asked about permission > > to send my patches) that you are not familiar with that code, and > > asked for my opinion. But once you've received my response you > > decided to ignore my opinion. So, you took my patches that you have > > no idea what are doing and sent to wine-patches with your own sign-off > > pretending that you had reviewed the patch. That's at least pretty > > rude and ridiculous behaviour, isn't it? > > > > No. If you don't want to participate in the wine-staging process, you > should stop contributing to wine-staging. Please don't try to pretend that you are participating in some process, especially when you clearly have no idea what's that. What you are doing is stealing the work done by somebody else, admitting at the same time that you are not familar with that code. -- Dmitry.

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

On Thu, Aug 17, 2017 at 11:51:55PM +0800, Dmitry Timoshkov wrote: > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > > > Again, I asked Sebastian to send it on your behalf, precisely to avoid > > > > this argument. He told me to send it instead, so I did. > > > > > > I'd appreciate if you could avoid sending my patches without my permission > > > in future. Thanks. > > > > > > > If you don't want your code used under the terms of the LGPL then I > > suggest you stop releasing code under the terms of the LGPL. > > Once again: it's not about licensing, it's about respect. You had > admitted in the private e-mail (when you asked about permission > to send my patches) that you are not familiar with that code, and > asked for my opinion. But once you've received my response you > decided to ignore my opinion. So, you took my patches that you have > no idea what are doing and sent to wine-patches with your own sign-off > pretending that you had reviewed the patch. That's at least pretty > rude and ridiculous behaviour, isn't it? > No. If you don't want to participate in the wine-staging process, you should stop contributing to wine-staging. Andrew

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > Again, I asked Sebastian to send it on your behalf, precisely to avoid > > > this argument. He told me to send it instead, so I did. > > > > I'd appreciate if you could avoid sending my patches without my permission > > in future. Thanks. > > > > If you don't want your code used under the terms of the LGPL then I > suggest you stop releasing code under the terms of the LGPL. Once again: it's not about licensing, it's about respect. You had admitted in the private e-mail (when you asked about permission to send my patches) that you are not familiar with that code, and asked for my opinion. But once you've received my response you decided to ignore my opinion. So, you took my patches that you have no idea what are doing and sent to wine-patches with your own sign-off pretending that you had reviewed the patch. That's at least pretty rude and ridiculous behaviour, isn't it? -- Dmitry.

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Sebastian Lackner

On 17.08.2017 16:29, Dmitry Timoshkov wrote: > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > >> On Thu, Aug 17, 2017 at 10:09:10PM +0800, Dmitry Timoshkov wrote: >>> It's not about licensing, it's about respect. You asked me a permission >>> privately - I answered that I don't allow it. That's it. >>> >> >> I didn't ask your permission privately, I asked if the patch was >> unsafe for inclusion in Wine. > > You asked is it OK to send my patches to winehq, and my response was - No. > >> The purpose of wine-staging is to >> prepare and test patches for inclusion in Wine. > > My personal motivation for sending patches to wine-staging is pretty > different. > >> Again, I asked Sebastian to send it on your behalf, precisely to avoid >> this argument. He told me to send it instead, so I did. > > I'd appreciate if you could avoid sending my patches without my permission > in future. Thanks. > @ Dmitry: The whole discussion is really ridiculous. First of all, don't blame Andrew, blame me. I told him that it is fine to send those patches. More importantly, if you plan to continue contributing to Wine Staging, you either have to send all of your patches yourself in a timely manner, or accept that other people pick up your patches and improve / send them. I have no idea why you see this as an insult. What are people supposed to do when they would like to get the bug fixed, and your solution is considered the right one? Would you prefer if people write an identical patch, and send it with their own name? (No, this is not meant as a serious question...) It is not really reasonable to expect everyone else to wait for your agreement / until you do it yourself. I also don't expect this for my own patches. In fact, I even appreciate when other people help with improving and upstreaming our stuff. Best regards, Sebastian

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

On Thu, Aug 17, 2017 at 10:29:49PM +0800, Dmitry Timoshkov wrote: > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > The purpose of wine-staging is to > > prepare and test patches for inclusion in Wine. > > My personal motivation for sending patches to wine-staging is pretty > different. > I don't think you should abuse wine-staging for your own purposes. Regardless, don't get angry at me when I *do* use it for its intended purpose. > > Again, I asked Sebastian to send it on your behalf, precisely to avoid > > this argument. He told me to send it instead, so I did. > > I'd appreciate if you could avoid sending my patches without my permission > in future. Thanks. > If you don't want your code used under the terms of the LGPL then I suggest you stop releasing code under the terms of the LGPL. Andrew

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

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=32717 Your paranoid android. === wvistau64 (32 bit listbox) === listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === wvistau64 (64 bit listbox) === listbox.c:706: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:941: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === w864 (64 bit broadcast) === The task timed out === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Thu, Aug 17, 2017 at 10:09:10PM +0800, Dmitry Timoshkov wrote: > > It's not about licensing, it's about respect. You asked me a permission > > privately - I answered that I don't allow it. That's it. > > > > I didn't ask your permission privately, I asked if the patch was > unsafe for inclusion in Wine. You asked is it OK to send my patches to winehq, and my response was - No. > The purpose of wine-staging is to > prepare and test patches for inclusion in Wine. My personal motivation for sending patches to wine-staging is pretty different. > Again, I asked Sebastian to send it on your behalf, precisely to avoid > this argument. He told me to send it instead, so I did. I'd appreciate if you could avoid sending my patches without my permission in future. Thanks. -- Dmitry.

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

On Thu, Aug 17, 2017 at 10:09:10PM +0800, Dmitry Timoshkov wrote: > It's not about licensing, it's about respect. You asked me a permission > privately - I answered that I don't allow it. That's it. > I didn't ask your permission privately, I asked if the patch was unsafe for inclusion in Wine. The purpose of wine-staging is to prepare and test patches for inclusion in Wine. Again, I asked Sebastian to send it on your behalf, precisely to avoid this argument. He told me to send it instead, so I did. Andrew

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > I think that I've expressed my opinion clear enough in my response > > to your private e-mail that I don't allow you to send my patches > > included in the wine-staging tree to winehq, and explained well enough > > my reasoning. The only person who has my permission is Sebastian Lackner - > > wine-staging maintainer. I'm too sometimes sending the patches, but I have > > to admit that's pretty rare cases these days, and usually that's not my > > personal decision. > > > > I asked Sebastian to send it on IRC. He told me to go ahead and send > it, so I did. > > > Please try to find your own areas to work on, and stop stealing patches > > created by somebody else, especially when directly asked not to. > > > > Perhaps you should go re-read the LGPL. It's not about licensing, it's about respect. You asked me a permission privately - I answered that I don't allow it. That's it. -- Dmitry.

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Sebastian Lackner

On 17.08.2017 15:57, Dmitry Timoshkov wrote: > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > >> From: Dmitry Timoshkov <dmitry(a)baikal.ru> >> >> Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> >> --- >> dlls/user32/tests/dialog.c | 6 ++++++ >> dlls/user32/tests/resource.rc | 6 ++++++ >> 2 files changed, 12 insertions(+) > > I think that I've expressed my opinion clear enough in my response > to your private e-mail that I don't allow you to send my patches > included in the wine-staging tree to winehq, and explained well enough > my reasoning. The only person who has my permission is Sebastian Lackner - > wine-staging maintainer. I'm too sometimes sending the patches, but I have > to admit that's pretty rare cases these days, and usually that's not my > personal decision. > > Please try to find your own areas to work on, and stop stealing patches > created by somebody else, especially when directly asked not to. > I think I have also made clear, that all patches included in Wine Staging are provided under the LGPL2 license, which does not allow any additional contraints. Everyone is welcome to improve them, send them, or do with them whatever they want, as long as authorship and license is preserved (which is the case here). There is really no reason to complain. Best regards, Sebastian Lackner

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Andrew Eikum

On Thu, Aug 17, 2017 at 09:57:10PM +0800, Dmitry Timoshkov wrote: > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > From: Dmitry Timoshkov <dmitry(a)baikal.ru> > > > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > > --- > > dlls/user32/tests/dialog.c | 6 ++++++ > > dlls/user32/tests/resource.rc | 6 ++++++ > > 2 files changed, 12 insertions(+) > > I think that I've expressed my opinion clear enough in my response > to your private e-mail that I don't allow you to send my patches > included in the wine-staging tree to winehq, and explained well enough > my reasoning. The only person who has my permission is Sebastian Lackner - > wine-staging maintainer. I'm too sometimes sending the patches, but I have > to admit that's pretty rare cases these days, and usually that's not my > personal decision. > I asked Sebastian to send it on IRC. He told me to go ahead and send it, so I did. > Please try to find your own areas to work on, and stop stealing patches > created by somebody else, especially when directly asked not to. > Perhaps you should go re-read the LGPL. Andrew

Aug. 17, 2017

Re: [PATCH 1/2] user32/tests: Test DialogBoxParam using a dialog template with invalid control class.

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > From: Dmitry Timoshkov <dmitry(a)baikal.ru> > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > dlls/user32/tests/dialog.c | 6 ++++++ > dlls/user32/tests/resource.rc | 6 ++++++ > 2 files changed, 12 insertions(+) I think that I've expressed my opinion clear enough in my response to your private e-mail that I don't allow you to send my patches included in the wine-staging tree to winehq, and explained well enough my reasoning. The only person who has my permission is Sebastian Lackner - wine-staging maintainer. I'm too sometimes sending the patches, but I have to admit that's pretty rare cases these days, and usually that's not my personal decision. Please try to find your own areas to work on, and stop stealing patches created by somebody else, especially when directly asked not to. -- Dmitry.

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Sebastian Lackner

On 15.08.2017 13:40, Nikolay Sivov wrote: > if (cached_key_size == key_size && !memcmp(cached_key, key, key_size)) { > + if (FAILED(hr = IDWriteFontFace4_QueryInterface(cached->fontface, riid, obj))) > + WARN("Failed to get %s from fontface, hr %#x.\n", debugstr_guid(riid), hr); > + > TRACE("returning cached fontface %p\n", cached->fontface); > - *font_face = (IDWriteFontFace*)cached->fontface; > - return S_OK; > + break; > } > } There is still a minor problem (no race condition though). Lets assume a fontface is just about to be destroyed, then the code above will abort enumeration after reaching the fontface with refcount == 0. Lets assume the newly created fontface is added after the old one, then all following attempts to get the fontface from the cache will fail, until the old one has finally be removed. This issue can be avoided by doing "continue;" instead of "break;" for E_FAIL.

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Sebastian Lackner

On 17.08.2017 10:11, Anton Romanov wrote: >> Does this really work reliable on Windows? If yes it means the current idea >> of thread safety is not really sufficient. Maybe Windows preserves cache >> entries for some specific time (or for the duration of the factory), even >> after the last reference is gone? Or maybe the factory has a reference on >> each font face? > > Sorry, I did misread the patch a bit. I'll take a closer look after I > have some sleep. > Here is the full lifetime of that fontface grepped from the log: > https://paste.ee/p/3No74 ( egrep "(0x97936c8|warn)" > ~/Desktop/Magic_Crash.log ) > And at the very list I cannot reproduce this crash on either windows > or wine with v1 of this patch. > The log contains the following line: 004c:warn:dwrite:factory_get_cached_fontface Failed to get {27f2a904-4eb8-441d-9678-0563f53e3e2f} from fontface, hr 0x80004005. This means the cached interface was not used, and it is unclear where the pointer in the following line comes from. Maybe I'm missing something, but for me it still looks like a use-after-free. It does not really mean much that v1 "fixed" it, sometimes a small timing difference is sufficient to hide the bug. ;) Best regards, Sebastian

Aug. 17, 2017

Re: [PATCH] kernel32/nls: Added LOCALE_SNAN entries

by Nikolay Sivov

On 08/17/2017 03:19 AM, Henri Verbeet wrote: > On 17 August 2017 at 00:28, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> diff --git a/dlls/kernel32/nls/far.nls b/dlls/kernel32/nls/far.nls >> index 0f5b17068b..2baf289223 100644 >> --- a/dlls/kernel32/nls/far.nls >> +++ b/dlls/kernel32/nls/far.nls >> @@ -124,6 +124,7 @@ STRINGTABLE LANGUAGE LANG_PERSIAN, SUBLANG_DEFAULT >> LOCALE_SMONTHNAME13 "" >> LOCALE_SMONTHOUSANDSEP "٬" >> LOCALE_SNAME "fa-IR" >> + LOCALE_SNAN "ﻥﺎﻋﺩﺩ" > That doesn't look right. According to > http://www.unicode.org/cldr/charts/latest/by_type/numbers.symbols.html#2a6d… > "ناعدد" is correct, but the above is using the Presentation Forms-B > characters. Thanks for checking. I sent v2. > >

Aug. 17, 2017

Re: [PATCH] msi: Print error number when GetProcAddress fails

by Nikolay Sivov

On 08/17/2017 01:24 PM, Carlos Palminha wrote: > > On 17-08-2017 10:24, Hans Leidekker wrote: >> On Wed, 2017-08-16 at 17:20 +0100, Carlos Palminha wrote: >>> diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c >>> index 922927e8903..cfdfe852efb 100644 >>> --- a/dlls/msi/custom.c >>> +++ b/dlls/msi/custom.c >>> @@ -608,7 +608,7 @@ static DWORD ACTION_CallDllFunction( const GUID *guid ) >>> ERR("failed to create handle for %p\n", remote_package ); >>> } >>> else >>> - ERR("GetProcAddress(%s) failed\n", debugstr_w( function ) ); >>> + ERR("GetProcAddress(%s) failed: %d\n", debugstr_w( function ), GetLastError() ); >>> >>> FreeLibrary(hModule); >> This doesn't appear to add any useful information. Our implementation of >> GetProcAddress sets either ERROR_PROC_NOT_FOUND or ERROR_MOD_NOT_FOUND and >> LoadLibrary must have succeeded before reaching this code. > > This is useful exactly for the cases where the library handle is ok but it fails trying to call a function from the DLL. > Printing the the error number is coherent with other cases and bring extra info about what went wrong calling the function. > > Missing is an error condition on its own. The point is it's either missing or present, extra error code won't tell anything new.

Aug. 17, 2017

Re: [PATCH] msi: Print error number when GetProcAddress fails

by Carlos Palminha

On 17-08-2017 10:24, Hans Leidekker wrote: > On Wed, 2017-08-16 at 17:20 +0100, Carlos Palminha wrote: >> diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c >> index 922927e8903..cfdfe852efb 100644 >> --- a/dlls/msi/custom.c >> +++ b/dlls/msi/custom.c >> @@ -608,7 +608,7 @@ static DWORD ACTION_CallDllFunction( const GUID *guid ) >> ERR("failed to create handle for %p\n", remote_package ); >> } >> else >> - ERR("GetProcAddress(%s) failed\n", debugstr_w( function ) ); >> + ERR("GetProcAddress(%s) failed: %d\n", debugstr_w( function ), GetLastError() ); >> >> FreeLibrary(hModule); > > This doesn't appear to add any useful information. Our implementation of > GetProcAddress sets either ERROR_PROC_NOT_FOUND or ERROR_MOD_NOT_FOUND and > LoadLibrary must have succeeded before reaching this code. This is useful exactly for the cases where the library handle is ok but it fails trying to call a function from the DLL. Printing the the error number is coherent with other cases and bring extra info about what went wrong calling the function.

Aug. 17, 2017

Re: [PATCH] msi: Print error number when GetProcAddress fails

by Hans Leidekker

On Wed, 2017-08-16 at 17:20 +0100, Carlos Palminha wrote: > diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c > index 922927e8903..cfdfe852efb 100644 > --- a/dlls/msi/custom.c > +++ b/dlls/msi/custom.c > @@ -608,7 +608,7 @@ static DWORD ACTION_CallDllFunction( const GUID *guid ) > ERR("failed to create handle for %p\n", remote_package ); > } > else > - ERR("GetProcAddress(%s) failed\n", debugstr_w( function ) ); > + ERR("GetProcAddress(%s) failed: %d\n", debugstr_w( function ), GetLastError() ); > > FreeLibrary(hModule); This doesn't appear to add any useful information. Our implementation of GetProcAddress sets either ERROR_PROC_NOT_FOUND or ERROR_MOD_NOT_FOUND and LoadLibrary must have succeeded before reaching this code.

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

On Thu, Aug 17, 2017 at 12:40 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 17.08.2017 07:11, Anton Romanov wrote: >> On Wed, Aug 16, 2017 at 10:05 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: >>> On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >>>> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >>>> --- >>>> dlls/dwrite/dwrite_private.h | 15 ++++++++--- >>>> dlls/dwrite/font.c | 30 +++++++++++++-------- >>>> dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- >>>> 3 files changed, 74 insertions(+), 34 deletions(-) >>>> >>> Since apps seem to freely use fontface interfaces from multiple >>> threads - Isn't the following race possible? >>> >>> +----------------+------------------------+-------------------------+ >>> | T1 | T2 | T3 | >>> +----------------+------------------------+-------------------------+ >>> | Release | | | >>> | Decrement | | | >>> | == 0 -> True | | | >>> | | Query_Interface/AddRef | | >>> | | Increment | | > > After the last Release call the app should not be calling any function on > the object directly. > > The only valid code path to obtain a new reference is going through > factory_get_cached_fontface. The code in this function is written in such > a way that it only uses very specific safe methods. Most importantly, > destroyed font faces are skipped, so for properly written apps no race > conditions are possible. > >>> | | | Release | >>> | | | Decrement | >>> | free(cached) | | | >>> | factory_unlock | | | >>> | | | use after free (cached) | >>> +----------------+------------------------+-------------------------+ >> Actually, with this version of the patch looks like this is exactly >> the crash I'm consistently getting now (was fine with v1): >> >> 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(1) >> 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(0) >> 004c:trace:dwrite:dwritefontface_GetFiles (0x97936c8)->(0x339d58 0x339d50) >> 004c:trace:dwrite:dwritefontface_GetIndex (0x97936c8) >> 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("GSUB" >> 0x339e60 0x339e68 0x339e64 0x339e5c) > > It is interesting that there is no "returning cached fontface" in the log > above. This suggests that your interpretation of the error is wrong, the > app basically operates on a destroyed object (or there is an error somewhere > else). > > Does this really work reliable on Windows? If yes it means the current idea > of thread safety is not really sufficient. Maybe Windows preserves cache > entries for some specific time (or for the duration of the factory), even > after the last reference is gone? Or maybe the factory has a reference on > each font face? Sorry, I did misread the patch a bit. I'll take a closer look after I have some sleep. Here is the full lifetime of that fontface grepped from the log: https://paste.ee/p/3No74 ( egrep "(0x97936c8|warn)" ~/Desktop/Magic_Crash.log ) And at the very list I cannot reproduce this crash on either windows or wine with v1 of this patch.

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Sebastian Lackner

On 17.08.2017 07:11, Anton Romanov wrote: > On Wed, Aug 16, 2017 at 10:05 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: >> On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >>> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >>> --- >>> dlls/dwrite/dwrite_private.h | 15 ++++++++--- >>> dlls/dwrite/font.c | 30 +++++++++++++-------- >>> dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- >>> 3 files changed, 74 insertions(+), 34 deletions(-) >>> >> Since apps seem to freely use fontface interfaces from multiple >> threads - Isn't the following race possible? >> >> +----------------+------------------------+-------------------------+ >> | T1 | T2 | T3 | >> +----------------+------------------------+-------------------------+ >> | Release | | | >> | Decrement | | | >> | == 0 -> True | | | >> | | Query_Interface/AddRef | | >> | | Increment | | After the last Release call the app should not be calling any function on the object directly. The only valid code path to obtain a new reference is going through factory_get_cached_fontface. The code in this function is written in such a way that it only uses very specific safe methods. Most importantly, destroyed font faces are skipped, so for properly written apps no race conditions are possible. >> | | | Release | >> | | | Decrement | >> | free(cached) | | | >> | factory_unlock | | | >> | | | use after free (cached) | >> +----------------+------------------------+-------------------------+ > Actually, with this version of the patch looks like this is exactly > the crash I'm consistently getting now (was fine with v1): > > 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(1) > 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(0) > 004c:trace:dwrite:dwritefontface_GetFiles (0x97936c8)->(0x339d58 0x339d50) > 004c:trace:dwrite:dwritefontface_GetIndex (0x97936c8) > 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("GSUB" > 0x339e60 0x339e68 0x339e64 0x339e5c) It is interesting that there is no "returning cached fontface" in the log above. This suggests that your interpretation of the error is wrong, the app basically operates on a destroyed object (or there is an error somewhere else). Does this really work reliable on Windows? If yes it means the current idea of thread safety is not really sufficient. Maybe Windows preserves cache entries for some specific time (or for the duration of the factory), even after the last reference is gone? Or maybe the factory has a reference on each font face?

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

On Wed, Aug 16, 2017 at 10:05 PM, Anton Romanov <theli.ua(a)gmail.com> wrote: > On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >> --- >> dlls/dwrite/dwrite_private.h | 15 ++++++++--- >> dlls/dwrite/font.c | 30 +++++++++++++-------- >> dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- >> 3 files changed, 74 insertions(+), 34 deletions(-) >> > Since apps seem to freely use fontface interfaces from multiple > threads - Isn't the following race possible? > > +----------------+------------------------+-------------------------+ > | T1 | T2 | T3 | > +----------------+------------------------+-------------------------+ > | Release | | | > | Decrement | | | > | == 0 -> True | | | > | | Query_Interface/AddRef | | > | | Increment | | > | | | Release | > | | | Decrement | > | free(cached) | | | > | factory_unlock | | | > | | | use after free (cached) | > +----------------+------------------------+-------------------------+ Actually, with this version of the patch looks like this is exactly the crash I'm consistently getting now (was fine with v1): 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(1) 0093:trace:dwrite:dwritefontface_Release (0x97936c8)->(0) 004c:trace:dwrite:dwritefontface_GetFiles (0x97936c8)->(0x339d58 0x339d50) 004c:trace:dwrite:dwritefontface_GetIndex (0x97936c8) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("GSUB" 0x339e60 0x339e68 0x339e64 0x339e5c) 004c:trace:dwrite:dwritefontface_ReleaseFontTable (0x97936c8)->((nil)) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("glyf" 0x339e00 0x339e08 0x339e04 0x339dfc) 004c:trace:dwrite:dwritefontface_ReleaseFontTable (0x97936c8)->((nil)) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("CFF " 0x339e00 0x339e08 0x339e04 0x339dfc) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("COLR" 0x339e00 0x339e08 0x339e04 0x339dfc) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("SVG " 0x339e00 0x339e08 0x339e04 0x339dfc) 004c:trace:dwrite:dwritefontface_TryGetFontTable (0x97936c8)->("sbix" 0x339e00 0x339e08 0x339e04 0x339dfc) 004c:trace:dwrite:dwritetextanalyzer_GetGlyphPlacements (L"1" 0x33b264 0x33b444 1 0x9636198 0x9635dc0 1 0x97936c8 16.00 0 0 "Zyyy" L"en-US" 0x95f5760 0x70456084 1 0x96ef808 0xd231630) 004c:trace:dwrite:dwritefontface_QueryInterface (0x97936c8)->({a71efdb4-9fdb-4838-ad90-cfc3be8c3daf} 0x339fd0) 004c:trace:dwrite:dwritefontface_GetMetrics (0x97936c8)->(0x339fd8) 004c:trace:dwrite:dwritefontface1_GetDesignGlyphAdvances (0x97936c8)->(1 0x9636198 0x339fd4 0) 004c:trace:dwrite:dwritefontface_Release (0x97936c8)->(1) 004c:trace:dwrite:dwritefontface_GetDesignGlyphMetrics (0x97936c8)->(0x7045637c 1 0x7045638c 0) 004c:trace:dwrite:dwritefontface_GetSimulations (0x97936c8) 004c:trace:dwrite:dwritefontface_Release (0x97936c8)->(0) wine: Unhandled page fault on read access to 0xffffffff at address 0x37719c8 (thread 004c), starting debugger...

Aug. 17, 2017

Re: [v5 PATCH 1/3] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

On Tue, Aug 15, 2017 at 4:40 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/dwrite_private.h | 15 ++++++++--- > dlls/dwrite/font.c | 30 +++++++++++++-------- > dlls/dwrite/main.c | 63 +++++++++++++++++++++++++++++++------------- > 3 files changed, 74 insertions(+), 34 deletions(-) > Since apps seem to freely use fontface interfaces from multiple threads - Isn't the following race possible? +----------------+------------------------+-------------------------+ | T1 | T2 | T3 | +----------------+------------------------+-------------------------+ | Release | | | | Decrement | | | | == 0 -> True | | | | | Query_Interface/AddRef | | | | Increment | | | | | Release | | | | Decrement | | free(cached) | | | | factory_unlock | | | | | | use after free (cached) | +----------------+------------------------+-------------------------+

Aug. 17, 2017

Re: [PATCH] kernel32/nls: Added LOCALE_SNAN entries

by Henri Verbeet

On 17 August 2017 at 00:28, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/kernel32/nls/far.nls b/dlls/kernel32/nls/far.nls > index 0f5b17068b..2baf289223 100644 > --- a/dlls/kernel32/nls/far.nls > +++ b/dlls/kernel32/nls/far.nls > @@ -124,6 +124,7 @@ STRINGTABLE LANGUAGE LANG_PERSIAN, SUBLANG_DEFAULT > LOCALE_SMONTHNAME13 "" > LOCALE_SMONTHOUSANDSEP "٬" > LOCALE_SNAME "fa-IR" > + LOCALE_SNAN "ﻥﺎﻋﺩﺩ" That doesn't look right. According to http://www.unicode.org/cldr/charts/latest/by_type/numbers.symbols.html#2a6d… "ناعدد" is correct, but the above is using the Presentation Forms-B characters.

Aug. 17, 2017

Re: [PATCH v3] user32/combo: Set listview popup height correctly and add tests

by Fabian Maurer

Oh thanks, I'll change that. I'll wait a while for further feedback before re-sending though. Regards, Fabian Maurer

Aug. 16, 2017

Re: [PATCH v3] user32/combo: Set listview popup height correctly and add tests

by Nikolay Sivov

It's a listbox, not listview.

Aug. 16, 2017

Re: D3D8 Software Vertex Processing

by Jan Havran

Hello again! On 16.8.2017 11:38, Stefan Dösinger wrote: > Hi, > > Good work isolating the issue :-) > > Am 2017-08-15 um 20:57 schrieb Jan Havran: >> How hard would be to fix it for D3D8 (and D3D9)? > It's not an evening task, but certainly doable. The feature has example > code in the dx8 and 9 sdk. Someone even started a patch and attached it > to bug 39057. MSDN documents the feature here: > https://msdn.microsoft.com/de-de/library/windows/desktop/bb174594(v=vs.85).… I did not know about this patch. I tested it and it works! > I had a quick look at the patch attached to bugzilla. Here is a > non-exhaustive list of concernes I have: > > *) The test should be extended to cover cases of conflicting pipeline > configuration, e.g. D3DRS_INDEXEDVERTEXBLENDENABLE is enabled but > D3DRS_VERTEXBLEND is not, or both states are enabled but no weight data > is contained in the vertices. The test doesn't test vertex declarations > and if it is indeed the case that only D3DDECLTYPE_UBYTE4 index values > are valid. The existing D3DFVF_LASTBETA_D3DCOLOR definition suggests > that at least D3DDECLTYPE_D3DCOLOR is valid too. > > The answer to some of those issues may be "it depends on the driver", in > which case a comment describing the outcome is fine and the test doesn't > have to actively check the feature. > > *) Porting the test to d3d8 and ddraw would be a good idea, especially > since the game you have is a d3d8 game. It shouldn't be too difficult to > adapt, and it can wait until the d3d9 version of the test is agreed on. The original game uses d3d8, yes. But there exist community util (made by Brchi), which converts D3D8 calls into D3D9, so it would be nice to have it in both d3d8 and d3d9, but it is not required. > *) I am torn on its use of UBOs for the matrices. The 256 shader > constants (256 vec4's aka 1024 uniforms) of d3d9 GPUs should be enough > for 32 matrices (this leaves 128 constants for other parameters). Those > GPUs don't have UBOs anyway. I think d3d10 GPUs (necessary for UBO > support) advertise 1024 constants or more (4096 uniforms), which should > give you the 128 matrices you need for your game. The game will not crash with 128 matrices, yes, but it is a question if it will be rendered correctly. Maybe dump question, I do not understand D3D much. > If however there are games that need the 255 matrices that SWVP offers > and there are still drivers that have less than 2048 old-style uniforms > you need a UBO codepath. If in addition there is no game that is happy > with <= 32 matrices you might as well drop the codepath for legacy uniforms. Hmm, sounds kinda difficult :) > *) For the UBO path glBufferSubData may be worth a try, or mapping the > buffer with GL_MAP_INVALIDATE_BUFFER_BIT and always re-uploading > everything. Doing a GL_WRITE_ONLY map like it currently does will stall > the pipeline. > > *) I don't think it is necessary to run the test for SW, HW and mixed > VP, doing it once should be ok since the result appears to be the same > in all cases. > > Am 2017-08-15 um 21:55 schrieb Jan Havran: >> Small update, value of MaxVertexBlendMatrixIndex in HWVP on both Windows >> and Wine is not real value from GetDeviceCaps, but, as Brchi told me, >> this function was hooked in VCStarter (that Vietcong community util) to >> set this variable to 126. Anyway, SWVP value should be real. > Why does VCStarter set the value to 126 when it's known to cause a > crash? I guess it is between a Rock (crash) and a hard place (broken > rendering because the real HWVP value is much smaller). I am not sure, but I was told that there were some problems with default HWVP value. > Fwiw, wined3d.dll and d3d9.dll can be compiled for Windows, so with > indexed blending support in Wine VCStarter could ship wined3d (under the > terms of the LGPLv2) Hmm, interesting, thx for info. I will let him know. Anyway, it is nice to see that the sollution (even not in the git at the moment) was found exactly 10 years after reporting bug :) Thank you very much for your help, I will keep watching updates of patch from #39057

Aug. 16, 2017

Re: [PATCH] gdiplus: Implement transform matrix for line gradient brushes

by Andrew Eikum

On Tue, Aug 15, 2017 at 12:47:48PM -0500, Vincent Povirk wrote: > I wrote a test program (attached), and it doesn't work when the start > point isn't 0,0. > Right, I got the sign on the offset in blend_line_gradient backwards. Thanks for the test program. > > + if (line->startpoint.X == line->endpoint.X) > > + t = line->startpoint.Y > line->endpoint.Y ? 3.f * M_PI / 2.f : M_PI / 2.f; > > + else > > + t = atanf((line->endpoint.Y - line->startpoint.Y) / (line->endpoint.X - line->startpoint.X)); > > + > > + t_cos = cosf(t); > > + t_sin = sinf(t); > > This seems like an oddly complicated and fragile way to normalize a vector. Yeah, I just took that straight from Mono's libgdiplus without understanding it. I'll study it some more and see if I can simplify it. Andrew

Aug. 16, 2017

Re: [PATCH] avrt: Add AvQuerySystemResponsiveness stub.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > > > > +BOOL WINAPI AvQuerySystemResponsiveness(HANDLE AvrtHandle, PULONG SystemResponsivenessValue) > > > > +{ > > > > + FIXME("(%p, %p): stub\n", AvrtHandle, SystemResponsivenessValue); > > > > + return TRUE; > > > > +} > > > > + > > > > > > If you're going to return TRUE, you need to initialize > > > *SystemResponsivenessValue to something meaningful. > > > > > > While you're at it, we generally prefer 'ULONG *' to 'PULONG', > > > > I'd guess that public APIs should follow the PSDK declarations, and > > where PSDK has PULONG an appropriate Wine header should have ULONG > > as well. > > This isn't a header, it's the implementation. This doesn't really matter, in order to be usable any API implementation eventually should have a declaration in a header, and an implementation can't have a different signature from a declaration in the public header. > Even in a header it would be better to be more typographically > different from the PSDK. Uh, I'd suggest to not open a can of worms. It's better to keep the source compatibility with PSDK as a de-facto standard. -- Dmitry.

Aug. 16, 2017

Re: [PATCH v2] server: Use queue_irp() also for synchronous IRPs.

by Alexandre Julliard

Zebediah Figura <z.figura12(a)gmail.com> writes: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > server/device.c | 46 ++++++++++++++++++++-------------------------- > 1 file changed, 20 insertions(+), 26 deletions(-) It's probably a matter of taste, but this doesn't look to me like an improvement. -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2017

Re: [PATCH] avrt: Add AvQuerySystemResponsiveness stub.

by Huw Davies

On Wed, Aug 16, 2017 at 08:39:32PM +0800, Dmitry Timoshkov wrote: > Huw Davies <huw(a)codeweavers.com> wrote: > > > > +BOOL WINAPI AvQuerySystemResponsiveness(HANDLE AvrtHandle, PULONG SystemResponsivenessValue) > > > +{ > > > + FIXME("(%p, %p): stub\n", AvrtHandle, SystemResponsivenessValue); > > > + return TRUE; > > > +} > > > + > > > > If you're going to return TRUE, you need to initialize > > *SystemResponsivenessValue to something meaningful. > > > > While you're at it, we generally prefer 'ULONG *' to 'PULONG', > > I'd guess that public APIs should follow the PSDK declarations, and > where PSDK has PULONG an appropriate Wine header should have ULONG > as well. This isn't a header, it's the implementation. Even in a header it would be better to be more typographically different from the PSDK. Huw.

Aug. 16, 2017

Re: [PATCH] avrt: Add AvQuerySystemResponsiveness stub.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > > +BOOL WINAPI AvQuerySystemResponsiveness(HANDLE AvrtHandle, PULONG SystemResponsivenessValue) > > +{ > > + FIXME("(%p, %p): stub\n", AvrtHandle, SystemResponsivenessValue); > > + return TRUE; > > +} > > + > > If you're going to return TRUE, you need to initialize > *SystemResponsivenessValue to something meaningful. > > While you're at it, we generally prefer 'ULONG *' to 'PULONG', I'd guess that public APIs should follow the PSDK declarations, and where PSDK has PULONG an appropriate Wine header should have ULONG as well. -- Dmitry.

Aug. 16, 2017

Re: [v4 5/5] kernel32/tests: Add tests for LoadLibrary with LIBRARY_SEARCH_* flags

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=32694 Your paranoid android. === wvistau64 (32 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === w2008s64 (32 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === wvistau64 (64 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === w2008s64 (64 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8

Aug. 16, 2017

Re: [PATCH] avrt: Add AvQuerySystemResponsiveness stub.

by Huw Davies

On Wed, Aug 16, 2017 at 02:22:13PM +0300, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/avrt/avrt.spec | 2 +- > dlls/avrt/main.c | 6 ++++++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/dlls/avrt/avrt.spec b/dlls/avrt/avrt.spec > index 640a12ac22..a7dfc42879 100644 > --- a/dlls/avrt/avrt.spec > +++ b/dlls/avrt/avrt.spec > @@ -1,4 +1,4 @@ > -@ stub AvQuerySystemResponsiveness > +@ stdcall AvQuerySystemResponsiveness(long ptr) > @ stdcall AvRevertMmThreadCharacteristics(long) > @ stub AvRtCreateThreadOrderingGroup > @ stub AvRtCreateThreadOrderingGroupExA > diff --git a/dlls/avrt/main.c b/dlls/avrt/main.c > index 8a110250ae..68e44d6098 100644 > --- a/dlls/avrt/main.c > +++ b/dlls/avrt/main.c > @@ -83,6 +83,12 @@ HANDLE WINAPI AvSetMmThreadCharacteristicsW(LPCWSTR TaskName, LPDWORD TaskIndex) > return (HANDLE)0x12345678; > } > > +BOOL WINAPI AvQuerySystemResponsiveness(HANDLE AvrtHandle, PULONG SystemResponsivenessValue) > +{ > + FIXME("(%p, %p): stub\n", AvrtHandle, SystemResponsivenessValue); > + return TRUE; > +} > + If you're going to return TRUE, you need to initialize *SystemResponsivenessValue to something meaningful. While you're at it, we generally prefer 'ULONG *' to 'PULONG', although I realise there are several of the latter form in this file. Huw.

Aug. 16, 2017

Re: D3D8 Software Vertex Processing

by Stefan Dösinger

Hi, Good work isolating the issue :-) Am 2017-08-15 um 20:57 schrieb Jan Havran: > How hard would be to fix it for D3D8 (and D3D9)? It's not an evening task, but certainly doable. The feature has example code in the dx8 and 9 sdk. Someone even started a patch and attached it to bug 39057. MSDN documents the feature here: https://msdn.microsoft.com/de-de/library/windows/desktop/bb174594(v=vs.85).… I had a quick look at the patch attached to bugzilla. Here is a non-exhaustive list of concernes I have: *) The test should be extended to cover cases of conflicting pipeline configuration, e.g. D3DRS_INDEXEDVERTEXBLENDENABLE is enabled but D3DRS_VERTEXBLEND is not, or both states are enabled but no weight data is contained in the vertices. The test doesn't test vertex declarations and if it is indeed the case that only D3DDECLTYPE_UBYTE4 index values are valid. The existing D3DFVF_LASTBETA_D3DCOLOR definition suggests that at least D3DDECLTYPE_D3DCOLOR is valid too. The answer to some of those issues may be "it depends on the driver", in which case a comment describing the outcome is fine and the test doesn't have to actively check the feature. *) Porting the test to d3d8 and ddraw would be a good idea, especially since the game you have is a d3d8 game. It shouldn't be too difficult to adapt, and it can wait until the d3d9 version of the test is agreed on. *) I am torn on its use of UBOs for the matrices. The 256 shader constants (256 vec4's aka 1024 uniforms) of d3d9 GPUs should be enough for 32 matrices (this leaves 128 constants for other parameters). Those GPUs don't have UBOs anyway. I think d3d10 GPUs (necessary for UBO support) advertise 1024 constants or more (4096 uniforms), which should give you the 128 matrices you need for your game. If however there are games that need the 255 matrices that SWVP offers and there are still drivers that have less than 2048 old-style uniforms you need a UBO codepath. If in addition there is no game that is happy with <= 32 matrices you might as well drop the codepath for legacy uniforms. *) For the UBO path glBufferSubData may be worth a try, or mapping the buffer with GL_MAP_INVALIDATE_BUFFER_BIT and always re-uploading everything. Doing a GL_WRITE_ONLY map like it currently does will stall the pipeline. *) I don't think it is necessary to run the test for SW, HW and mixed VP, doing it once should be ok since the result appears to be the same in all cases. Am 2017-08-15 um 21:55 schrieb Jan Havran: > Small update, value of MaxVertexBlendMatrixIndex in HWVP on both Windows > and Wine is not real value from GetDeviceCaps, but, as Brchi told me, > this function was hooked in VCStarter (that Vietcong community util) to > set this variable to 126. Anyway, SWVP value should be real. Why does VCStarter set the value to 126 when it's known to cause a crash? I guess it is between a Rock (crash) and a hard place (broken rendering because the real HWVP value is much smaller). Fwiw, wined3d.dll and d3d9.dll can be compiled for Windows, so with indexed blending support in Wine VCStarter could ship wined3d (under the terms of the LGPLv2)

Aug. 16, 2017

Re: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64

by Martin Storsjö

On Wed, 16 Aug 2017, Alexandre Julliard wrote: > André Hentschel <nerv(a)dawncrow.de> writes: > >> The upstreamed variadic function handling is terrific, thanks for that! >> I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... >> At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. >> It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... >> On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 >> OK... We need this improvement, I'll sign it off :) > > I'm doing Android/ARM64 builds to verify that the platform doesn't get > broken after commit rounds, so I'll need to wait until this feature > makes it to the Android NDK to apply the patch. Ok, let's hope it makes its way into NDK r16. They don't use fixed releases of LLVM but some random snapshot plus fixes, iirc. The feature itself was merged around mid July, with the last fixes early August. Since the amount of users building for arm64 probably is very small so far (the three of us?), I don't mind waiting until it's easily available for you, so we don't need to do a huge mess with compiler version identification for this feature in the headers. // Martin

Aug. 16, 2017

Re: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > The upstreamed variadic function handling is terrific, thanks for that! > I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... > At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. > It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... > On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 > OK... We need this improvement, I'll sign it off :) I'm doing Android/ARM64 builds to verify that the platform doesn't get broken after commit rounds, so I'll need to wait until this feature makes it to the Android NDK to apply the patch. -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2017

Re: [PATCH] usp10: fall back to 'dflt' language if shaping language tag not found

by Henri Verbeet

On 15 August 2017 at 16:27, Aric Stewart <aric(a)codeweavers.com> wrote: > On 8/14/17 1:27 PM, Henri Verbeet wrote: >> On 14 August 2017 at 20:04, Aric Stewart <aric(a)codeweavers.com> wrote: >>> + script = get_opentype_script(hdc,psa,psc,FALSE); >> Does that do anything? If I'm reading the code correctly that will set >> it to the same value it already was. (In which case most of this would >> simplify to "if (!script) script = MS_MAKE_TAG('l','a','t','n');") > > Not quite. The above loop that sets script tries twice, once with get_opentype_script(..., FALSE) then with get_opentype_script(..., TRUE) so if script is set coming into that loop it is from the TRUE loop, > "attempt" counts down from 2, so the first iteration has "try_new" as TRUE, the second iteration has it as FALSE.

Aug. 15, 2017

Re: D3D8 Software Vertex Processing

by Jan Havran

Small update, value of MaxVertexBlendMatrixIndex in HWVP on both Windows and Wine is not real value from GetDeviceCaps, but, as Brchi told me, this function was hooked in VCStarter (that Vietcong community util) to set this variable to 126. Anyway, SWVP value should be real. On 15.8.2017 20:57, Jan Havran wrote: > Bingo! > > I finally managed to install Windows 7 on my laptop and tried some > debugging (I was comparing it to Wine). You was right, I have found > that the game calls some D3D8 function where it gets D3DCAPS8 > structure. In that structure it tests MaxVertexBlendMatrixIndex > (offset 0xAC) and depend on that value it executes one or another > branch. On Windows MaxVertexBlendMatrixIndex is set always to 255 as > it says MS Dev Center for SWVP [1] (well, it is for D3D9, but i think > it should be the same as D3D8). But the problem is that this value is > set to 0 in Wine ([1] says that 0 means following: "device does not > support indexed matrices"). As I have never heard about this issue on > Windows, I guess that indexed matrices are always supported on > Windows. I tested SWVP and HWVP on both Windows and Wine and here are > the results: > > Vietcong (Windows) with SW Vertex: 255 > Vietcong (Windows) with HW Vertex: 126 > Vietcong (Wine) with SW Vertex: 0 > Vietcong (Wine) with HW Vertex: 126 > > So the game expects (was tested) 255 in SWVP but it gets 0. The > minimum value of MaxVertexBlendMatrixIndex for which the application > runs fine is 127, while anything below it (like 126 for HWVP or 0 for > Wine SWVP/HWVP) will execute some broken branch (but for certain > soldier figures only). > > When I set this value to 255 in dlls/d3d8/device.c the game do not > crash anymore, but instead of that there are some rendering problems > (as you predicted, so you was right again). See attachment in [2]. > > How hard would be to fix it for D3D8 (and D3D9)? > > [1] > https://msdn.microsoft.com/en-us/library/windows/desktop/bb206316(v=vs.85).… > [2] https://bugs.winehq.org/show_bug.cgi?id=9337#c44 > > > On 6.8.2017 22:25, Jan Havran wrote: >> >> >> On 6.8.2017 20:36, Stefan Dösinger wrote: >>> On 06/08/17 17:19, Jan Havran wrote: >>>> Can I simply edit some code in Wine (some D3D flag) >>>> so the game will think that it use SW vertexes, so after checking some >>>> flags by game it will not jump into some unfinished branches for HW >>>> vertexes? I just want to test if it is really caused by this. From >>>> application view, what is difference between using SW and HW vertexes, >>>> do you think that using HW vertexes with code done for SW vertexes >>>> will >>>> work? >>> This behavior should already be in place. If the app requsts a software >>> vertex processing device and asks us for the device description >>> later we >>> should report that this is a software vertex processing device. We even >>> do some software-like things if the app wants SWVP, like ignore >>> D3DLOCK_DISCARD on buffers. >>> >>> The game may check some derived properties though and expect some >>> capability that SWVP has, but HWVP does not. The most likely case is >>> support for more than 256 vertex shader constants. Modern GPUs support >>> much more than that in OpenGL, but not in d3d8/9 on Windows. Because of >>> this we filter this in dlls/d3d8/device.c, d3dcaps_from_wined3dcaps(). >>> Look for D3D8_MAX_VERTEX_SHADER_CONSTANTF at the end. It is likely that >>> this restriction is not in place on Windows with SWVP. You can try to >>> just disable this line. >> >> Wine is big magic to me right now, so thank you for your tips, I will >> try to test that. >> >>> >>> Another possible culprit is fixed function vertex blending using matrix >>> indices. You can try to set MaxVertexBlendMatrices and >>> MaxVertexBlendMatrixIndex to 4 and 256 respectively (check on >>> Windows if >>> those values are accurate, I might misremember them). This >>> functionality >>> is unimplemented in Wine, so expect rendering problems if the game uses >>> this. It should be possible to implement this feature in our fixed >>> function replacement shader though. >> >> Ok, I will test it. Unfrotunately I didnt find piece of code where >> the game decide which vertex processing it will use yet - maybe I >> will install Windows so I will be able to compare execution of >> branches between Windows and Linux. >> >>> The bug report doesn't have a crash dump. The similarity to windows >>> HWVP >>> might mislead you. Try to compare your crash to the one of windows >>> HWVP. >>> in particular, see if the crash address is the same. >> >> Well, I was talking about my issue with Brchi and we came to the >> conclusion that it was crashing in the same function for both Linux >> (Wine) and Windows (with enabled HWVP). Unfortunately, there is >> version of his util without HWVP enabled (which doesnt work in Wine >> as I said, because the game use branches for HWVP here) and after >> that version with HWVP enabled only, but with fixed game code (by >> memory patching) so there is no way how can I test it on Windows >> (because I dont have version of the util where it is crashing for >> Windows, since there is no version with HWVP enabled and without fix >> of this issue at the same time). >> >> Anyway, this game has plenty of problems on newer Windows, but I >> never heard about this issue even on Windows 10. >> >> I will try some tests you described and report back as soon as possible. >> >> Thanks for your time. >> >> > > >

Aug. 15, 2017

Re: D3D8 Software Vertex Processing

by Jan Havran

Bingo! I finally managed to install Windows 7 on my laptop and tried some debugging (I was comparing it to Wine). You was right, I have found that the game calls some D3D8 function where it gets D3DCAPS8 structure. In that structure it tests MaxVertexBlendMatrixIndex (offset 0xAC) and depend on that value it executes one or another branch. On Windows MaxVertexBlendMatrixIndex is set always to 255 as it says MS Dev Center for SWVP [1] (well, it is for D3D9, but i think it should be the same as D3D8). But the problem is that this value is set to 0 in Wine ([1] says that 0 means following: "device does not support indexed matrices"). As I have never heard about this issue on Windows, I guess that indexed matrices are always supported on Windows. I tested SWVP and HWVP on both Windows and Wine and here are the results: Vietcong (Windows) with SW Vertex: 255 Vietcong (Windows) with HW Vertex: 126 Vietcong (Wine) with SW Vertex: 0 Vietcong (Wine) with HW Vertex: 126 So the game expects (was tested) 255 in SWVP but it gets 0. The minimum value of MaxVertexBlendMatrixIndex for which the application runs fine is 127, while anything below it (like 126 for HWVP or 0 for Wine SWVP/HWVP) will execute some broken branch (but for certain soldier figures only). When I set this value to 255 in dlls/d3d8/device.c the game do not crash anymore, but instead of that there are some rendering problems (as you predicted, so you was right again). See attachment in [2]. How hard would be to fix it for D3D8 (and D3D9)? [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb206316(v=vs.85).… [2] https://bugs.winehq.org/show_bug.cgi?id=9337#c44 On 6.8.2017 22:25, Jan Havran wrote: > > > On 6.8.2017 20:36, Stefan Dösinger wrote: >> On 06/08/17 17:19, Jan Havran wrote: >>> Can I simply edit some code in Wine (some D3D flag) >>> so the game will think that it use SW vertexes, so after checking some >>> flags by game it will not jump into some unfinished branches for HW >>> vertexes? I just want to test if it is really caused by this. From >>> application view, what is difference between using SW and HW vertexes, >>> do you think that using HW vertexes with code done for SW vertexes will >>> work? >> This behavior should already be in place. If the app requsts a software >> vertex processing device and asks us for the device description later we >> should report that this is a software vertex processing device. We even >> do some software-like things if the app wants SWVP, like ignore >> D3DLOCK_DISCARD on buffers. >> >> The game may check some derived properties though and expect some >> capability that SWVP has, but HWVP does not. The most likely case is >> support for more than 256 vertex shader constants. Modern GPUs support >> much more than that in OpenGL, but not in d3d8/9 on Windows. Because of >> this we filter this in dlls/d3d8/device.c, d3dcaps_from_wined3dcaps(). >> Look for D3D8_MAX_VERTEX_SHADER_CONSTANTF at the end. It is likely that >> this restriction is not in place on Windows with SWVP. You can try to >> just disable this line. > > Wine is big magic to me right now, so thank you for your tips, I will > try to test that. > >> >> Another possible culprit is fixed function vertex blending using matrix >> indices. You can try to set MaxVertexBlendMatrices and >> MaxVertexBlendMatrixIndex to 4 and 256 respectively (check on Windows if >> those values are accurate, I might misremember them). This functionality >> is unimplemented in Wine, so expect rendering problems if the game uses >> this. It should be possible to implement this feature in our fixed >> function replacement shader though. > > Ok, I will test it. Unfrotunately I didnt find piece of code where the > game decide which vertex processing it will use yet - maybe I will > install Windows so I will be able to compare execution of branches > between Windows and Linux. > >> The bug report doesn't have a crash dump. The similarity to windows HWVP >> might mislead you. Try to compare your crash to the one of windows HWVP. >> in particular, see if the crash address is the same. > > Well, I was talking about my issue with Brchi and we came to the > conclusion that it was crashing in the same function for both Linux > (Wine) and Windows (with enabled HWVP). Unfortunately, there is > version of his util without HWVP enabled (which doesnt work in Wine as > I said, because the game use branches for HWVP here) and after that > version with HWVP enabled only, but with fixed game code (by memory > patching) so there is no way how can I test it on Windows (because I > dont have version of the util where it is crashing for Windows, since > there is no version with HWVP enabled and without fix of this issue at > the same time). > > Anyway, this game has plenty of problems on newer Windows, but I never > heard about this issue even on Windows 10. > > I will try some tests you described and report back as soon as possible. > > Thanks for your time. > >

Aug. 15, 2017

Re: [PATCH] gdiplus: Implement transform matrix for line gradient brushes

by Vincent Povirk

I wrote a test program (attached), and it doesn't work when the start point isn't 0,0. > + if (line->startpoint.X == line->endpoint.X) > + t = line->startpoint.Y > line->endpoint.Y ? 3.f * M_PI / 2.f : M_PI / 2.f; > + else > + t = atanf((line->endpoint.Y - line->startpoint.Y) / (line->endpoint.X - line->startpoint.X)); > + > + t_cos = cosf(t); > + t_sin = sinf(t); This seems like an oddly complicated and fragile way to normalize a vector.

Aug. 15, 2017

Re: [PATCH v3 5/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Jacek Caban

On 10.08.2017 20:52, Zebediah Figura wrote: > v2: register IE and IEM separately, and the latter with SINGLEUSE > (thanks Jacek) > > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > --- > dlls/ieframe/ieframe.h | 5 +- > dlls/ieframe/ieframe_main.c | 35 ++++--------- > dlls/ieframe/iexplore.c | 111 ++++++++++++++++++++++++++++++++++++++--- > dlls/ieframe/tests/ie.c | 21 ++++++++ > programs/iexplore/iexplore.inf | 3 ++ > 5 files changed, 142 insertions(+), 33 deletions(-) > > diff --git a/dlls/ieframe/ieframe.h b/dlls/ieframe/ieframe.h > index d1f1c5daf24..c690d5c6878 100644 > --- a/dlls/ieframe/ieframe.h > +++ b/dlls/ieframe/ieframe.h > @@ -312,13 +312,16 @@ TID_LIST > } tid_t; > > HRESULT get_typeinfo(tid_t,ITypeInfo**) DECLSPEC_HIDDEN; > -HRESULT register_class_object(BOOL) DECLSPEC_HIDDEN; > > HRESULT WINAPI CUrlHistory_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > HRESULT WINAPI InternetExplorer_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > HRESULT WINAPI InternetShortcut_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > HRESULT WINAPI WebBrowser_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > HRESULT WINAPI WebBrowserV1_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > +HRESULT WINAPI InternetExplorerManager_Create(IClassFactory*,IUnknown*,REFIID,void**) DECLSPEC_HIDDEN; > + > +extern IClassFactory InternetExplorerFactory; > +extern IClassFactory InternetExplorerManagerFactory; This is missing DECLSPEC_HIDDEN. > > +/****************************************************************** > + * IInternetExplorerManager implementation > + */ > +struct internet_explorer_manager { > + IInternetExplorerManager IInternetExplorerManager_iface; > + LONG ref; > +}; Please use the type from public declaration (coclass). See how InternetExplorer object is declared. > +HRESULT WINAPI InternetExplorerManager_Create(IClassFactory *iface, IUnknown *pOuter, REFIID riid, void **ppv) > +{ > + struct internet_explorer_manager *ret; > + > + TRACE("(%p %s %p)\n", pOuter, debugstr_guid(riid), ppv); > + > + if (!(ret = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*ret)))) > + return E_OUTOFMEMORY; > + > + ret->IInternetExplorerManager_iface.lpVtbl = &InternetExplorerManager_vtbl; > + return IInternetExplorerManager_QueryInterface(&ret->IInternetExplorerManager_iface, riid, ppv); > +} This leaks the object if QueryInterface fails. The usual way to handle is to set initial ref to 1 and release the object after QI() call. > +static void test_InternetExplorerManager(void) > +{ > + IUnknown *unk; > + ULONG ref; > + HRESULT hres; > + > + hres = CoCreateInstance(&CLSID_InternetExplorerManager, NULL, CLSCTX_LOCAL_SERVER, > + &IID_IInternetExplorerManager, (void**)&unk); > + ok(hres == S_OK || hres == REGDB_E_CLASSNOTREG, "Could not create InternetExplorerManager instance: %08x\n", hres); Use broken() for failure with older versions. > + > + if(hres != S_OK) > + return; This could use a win_skip(). Thanks, Jacek

Aug. 15, 2017

Re: [PATCH v3 4/5] ieframe: Parse multiple command-line arguments.

by Jacek Caban

Hi Zebediah, On 10.08.2017 20:52, Zebediah Figura wrote: > + if (!strncmpiW(cmdline, embeddingW, length)) > + embedding = TRUE; > + else if (!strncmpiW(cmdline, nohomeW, length)) > + nohome = TRUE; > + else if (*cmdline == '-') > + FIXME("ignoring unknown option %s\n", debugstr_wn(cmdline, length)); It's probably not very important, but with native IE unknown options seem to be treated as URLs (iexplore.exe -test tries to open "-test" URL). Thanks, Jacek

Aug. 15, 2017

Re: [PATCH 2/3] include: Add CryptProtectMemory and CryptUnprotectMemory.

by Alex Henrie

2017-08-15 9:08 GMT-06:00 Michael Stefaniuc <mstefani(a)winehq.org>: > On 08/15/2017 05:00 PM, Alex Henrie wrote: >> Needed for PuTTY to compile with Winelib. >> >> Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> >> --- >> include/wincrypt.h | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/include/wincrypt.h b/include/wincrypt.h >> index abbe99f245..058798c4f4 100644 >> --- a/include/wincrypt.h >> +++ b/include/wincrypt.h >> @@ -4428,6 +4428,9 @@ BOOL WINAPI CryptUnprotectData( DATA_BLOB* pDataIn, LPWSTR* ppszDataDescr, >> DATA_BLOB* pOptionalEntropy, PVOID pvReserved, >> CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct, DWORD dwFlags, DATA_BLOB* pDataOut ); >> >> +BOOL WINAPI CryptProtectMemory(void *pData, DWORD cbData, DWORD dwFlags); >> +BOOL WINAPI CryptUnrotectMemory(void *pData, DWORD cbData, DWORD dwFlags); > Isn't that missing a p^ ? Yes, thanks for catching that. Actually PuTTY only uses CryptProtectMemory, but I thought it was a good idea to add both functions. -Alex

Aug. 15, 2017

Re: [PATCH 2/3] include: Add CryptProtectMemory and CryptUnprotectMemory.

by Michael Stefaniuc

On 08/15/2017 05:00 PM, Alex Henrie wrote: > Needed for PuTTY to compile with Winelib. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > include/wincrypt.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/wincrypt.h b/include/wincrypt.h > index abbe99f245..058798c4f4 100644 > --- a/include/wincrypt.h > +++ b/include/wincrypt.h > @@ -4428,6 +4428,9 @@ BOOL WINAPI CryptUnprotectData( DATA_BLOB* pDataIn, LPWSTR* ppszDataDescr, > DATA_BLOB* pOptionalEntropy, PVOID pvReserved, > CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct, DWORD dwFlags, DATA_BLOB* pDataOut ); > > +BOOL WINAPI CryptProtectMemory(void *pData, DWORD cbData, DWORD dwFlags); > +BOOL WINAPI CryptUnrotectMemory(void *pData, DWORD cbData, DWORD dwFlags); Isn't that missing a p^ ? bye michael > + > DWORD WINAPI CertGetNameStringA(PCCERT_CONTEXT pCertContext, DWORD dwType, > DWORD dwFlags, void *pvTypePara, LPSTR pszNameString, DWORD cchNameString); > DWORD WINAPI CertGetNameStringW(PCCERT_CONTEXT pCertContext, DWORD dwType, >

Aug. 15, 2017

Re: [PATCH] usp10: fall back to 'dflt' language if shaping language tag not found

by Aric Stewart

On 8/14/17 1:27 PM, Henri Verbeet wrote: > On 14 August 2017 at 20:04, Aric Stewart <aric(a)codeweavers.com> wrote: >> + script = get_opentype_script(hdc,psa,psc,FALSE); > Does that do anything? If I'm reading the code correctly that will set > it to the same value it already was. (In which case most of this would > simplify to "if (!script) script = MS_MAKE_TAG('l','a','t','n');") > > Not quite. The above loop that sets script tries twice, once with get_opentype_script(..., FALSE) then with get_opentype_script(..., TRUE) so if script is set coming into that loop it is from the TRUE loop, which (mostly just for some Indic languages) is different. The quick search I did seemed that we wanted the first case not the second for the dflt language case. It may be for some fonts we end up needing to search both the old and new script tags but if we do we can expand this later. -aric

Aug. 15, 2017

Re: [3/8] bcrypt: Add a stub implementation of BCryptEncrypt.

by Jacek Caban

Hi Hans, On 15.08.2017 14:51, Hans Leidekker wrote: > diff --git a/dlls/bcrypt/bcrypt_main.c b/dlls/bcrypt/bcrypt_main.c > index 3d70c15e7c..ccab676c1a 100644 > --- a/dlls/bcrypt/bcrypt_main.c > +++ b/dlls/bcrypt/bcrypt_main.c > @@ -515,7 +515,7 @@ NTSTATUS WINAPI BCryptGetProperty( BCRYPT_HANDLE handle, LPCWSTR prop, UCHAR *bu > NTSTATUS WINAPI BCryptSetProperty( BCRYPT_HANDLE handle, const WCHAR *prop, UCHAR *value, ULONG size, ULONG flags ) > { > FIXME( "%p, %s, %p, %u, %08x\n", handle, debugstr_w(prop), value, size, flags ); > - return STATUS_SUCCESS; > + return STATUS_NOT_IMPLEMENTED; I think this part was meant to be in patch 2/8. Thanks, Jacek

Aug. 15, 2017

Re: [PATCH] user32/combo: Set listview popup height correctly and add tests

by Fabian Maurer

> 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=32672 > === w7u (32 bit combo) === > combo.c:786: Test failed: Test 2, expected list height to be 16, got 0 > combo.c:786: Test failed: Test 3, expected list height to be 16, got 18 > combo.c:786: Test failed: Test 4, expected list height to be 32, got 18 > combo.c:786: Test failed: Test 5, expected list height to be 32, got 36 > combo.c:786: Test failed: Test 6, expected list height to be 32, got 36 > combo.c:786: Test failed: Test 7, expected list height to be 32, got 36 > combo.c:786: Test failed: Test 8, expected list height to be 32, got 36 > combo.c:786: Test failed: Test 11, expected list height to be 16, got 0 > combo.c:786: Test failed: Test 12, expected list height to be 16, got 18 > combo.c:786: Test failed: Test 13, expected list height to be 32, got 18 > combo.c:786: Test failed: Test 14, expected list height to be 48, got 36 > combo.c:781: Test failed: Test 15, expected list height to be 48, got 54 > combo.c:786: Test failed: Test 16, expected list height to be 64, got 54 > combo.c:786: Test failed: Test 17, expected list height to be 64, got 72 > combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 Fixed the one failure, but it looks like this machine does have a different listview-item size. Have to look into it.

Aug. 14, 2017

Re: [PATCH] user32/combo: Set listview popup height correctly and add tests

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=32672 Your paranoid android. === wxppro (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w2003std (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === wvistau64 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w2008s64 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w7u (32 bit combo) === combo.c:786: Test failed: Test 2, expected list height to be 16, got 0 combo.c:786: Test failed: Test 3, expected list height to be 16, got 18 combo.c:786: Test failed: Test 4, expected list height to be 32, got 18 combo.c:786: Test failed: Test 5, expected list height to be 32, got 36 combo.c:786: Test failed: Test 6, expected list height to be 32, got 36 combo.c:786: Test failed: Test 7, expected list height to be 32, got 36 combo.c:786: Test failed: Test 8, expected list height to be 32, got 36 combo.c:786: Test failed: Test 11, expected list height to be 16, got 0 combo.c:786: Test failed: Test 12, expected list height to be 16, got 18 combo.c:786: Test failed: Test 13, expected list height to be 32, got 18 combo.c:786: Test failed: Test 14, expected list height to be 48, got 36 combo.c:781: Test failed: Test 15, expected list height to be 48, got 54 combo.c:786: Test failed: Test 16, expected list height to be 64, got 54 combo.c:786: Test failed: Test 17, expected list height to be 64, got 72 combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w7pro64 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w8 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w864 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === w1064 (32 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 00000000 === wvistau64 (64 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000 === w2008s64 (64 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000 === w7pro64 (64 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000 === w864 (64 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000 === w1064 (64 bit combo) === combo.c:315: Test failed: Focus not on Main Window, instead on 0000000000000000

Aug. 14, 2017

Re: [PATCH] usp10: fall back to 'dflt' language if shaping language tag not found

by Henri Verbeet

On 14 August 2017 at 20:04, Aric Stewart <aric(a)codeweavers.com> wrote: > + script = get_opentype_script(hdc,psa,psc,FALSE); Does that do anything? If I'm reading the code correctly that will set it to the same value it already was. (In which case most of this would simplify to "if (!script) script = MS_MAKE_TAG('l','a','t','n');")

Aug. 14, 2017

Re: [1/3] shell32: Implement SHCreateItemFromRelativeName.

by Jactry Zeng

Thanks! I sent another try. 2017-08-14 18:41 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > On Sat, Aug 12, 2017 at 11:42:40PM +0800, Jactry Zeng wrote: > > +HRESULT WINAPI SHCreateItemFromRelativeName(IShellItem *parent, PCWSTR > name, IBindCtx *pbc, > > + REFIID riid, void **ppv) > > +{ > > + LPITEMIDLIST pidl_folder = NULL, pidl = NULL; > > + IShellFolder *desktop = NULL, *folder = NULL; > > + HRESULT hr; > > + > > + TRACE("(%p, %p, %p, %s, %p)\n", parent, name, pbc, > debugstr_guid(riid), ppv); > > Use debugstr_w() to trace 'name'. > > > + > > + if(!ppv) > > + return E_INVALIDARG; > > + *ppv = NULL; > > + if(!name) > > + return E_INVALIDARG; > > + > > + hr = SHGetIDListFromObject((IUnknown*)parent, &pidl_folder); > > + if(hr != S_OK) > > + return hr; > > + > > + hr = SHGetDesktopFolder(&desktop); > > + if(hr != S_OK) > > + goto cleanup; > > + > > + if(!_ILIsDesktop(pidl_folder)) > > + { > > + hr = IShellFolder_BindToObject(desktop, pidl_folder, pbc, > &IID_IShellFolder, > > + (void**)&folder); > > You should pass a NULL IBindCtx here. pbc is associated with binding the > name. > > > + if(hr != S_OK) > > + goto cleanup; > > + } > > + > > + hr = IShellFolder_ParseDisplayName(folder ? folder : desktop, > NULL, pbc, (LPWSTR)name, > > + NULL, &pidl, NULL); > > + if(hr != S_OK) > > + goto cleanup; > > + hr = SHCreateItemFromIDList(pidl, riid, ppv); > > + > > > diff --git a/dlls/shell32/tests/shlfolder.c b/dlls/shell32/tests/ > shlfolder.c > > index 9e7127dfea..cbab88035a 100644 > > --- a/dlls/shell32/tests/shlfolder.c > > +++ b/dlls/shell32/tests/shlfolder.c > > > @@ -2519,6 +2523,86 @@ static void test_SHCreateShellItem(void) > > else > > win_skip("No SHCreateItemFromIDList\n"); > > > > + /* SHCreateItemFromRelativeName */ > > + if(pSHCreateItemFromRelativeName && pSHGetKnownFolderPath) > > + { > > + IShellItem *shellitem_desktop = NULL; > > + WCHAR *desktop_path, *displayname; > > + WCHAR testfile_path[MAX_PATH] = {0}; > > + HANDLE file; > > + LPITEMIDLIST pidl_desktop_testfile = NULL; > > + int order; > > + > > + ret = pSHCreateShellItem(NULL, NULL, pidl_desktop, > &shellitem_desktop); > > + ok(ret == S_OK, "SHCreateShellItem failed: 0x%08x.\n", ret); > > + > > + shellitem = (void*)0xdeadbeef; > > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, NULL, > NULL, &IID_IShellItem, > > + (void**)&shellitem); > > + ok(ret == E_INVALIDARG, "Expected 0x%08x but > SHCreateItemFromRelativeName return: 0x%08x.\n", > > + E_INVALIDARG, ret); > > + ok(shellitem == NULL, "shellitem was %p.\n", shellitem); > > + > > + /* Test with a non-existent file */ > > + shellitem = (void*)0xdeadbeef; > > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, > testfileW, NULL, &IID_IShellItem, > > + (void**)&shellitem); > > + ok(ret == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > > + "Expected 0x%08x but SHCreateItemFromRelativeName return: > 0x%08x.\n", > > + HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), ret); > > + ok(shellitem == NULL, "shellitem was %p.\n", shellitem); > > + > > + /* Create a file for testing in desktop folder */ > > + pSHGetKnownFolderPath(&FOLDERID_Desktop, 0, NULL, > &desktop_path); > > + lstrcatW(testfile_path, desktop_path); > > + myPathAddBackslashW(testfile_path); > > + lstrcatW(testfile_path, testfileW); > > + file = CreateFileW(testfile_path, GENERIC_WRITE, 0, NULL, > CREATE_NEW, 0, NULL); > > + ok(file != INVALID_HANDLE_VALUE, "CreateFileW failed! Last > error: 0x%08x.\n", GetLastError()); > > + CloseHandle(file); > > + > > + shellitem = (void*)0xdeadbeef; > > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, > testfileW, NULL, &IID_IShellItem, > > + (void**)&shellitem); > > + ok(ret == S_OK, "SHCreateItemFromRelativeName failed: > 0x%08x.\n", ret); > > + ok(shellitem != NULL, "shellitem was %p.\n", shellitem); > > + if(SUCCEEDED(ret)) > > + { > > + ret = IShellItem_GetDisplayName(shellitem, 0, > &displayname); > > + ok(ret == S_OK, "IShellItem_GetDisplayName failed: > 0x%08x.\n", ret); > > + ok(!lstrcmpW(displayname, testfileW), "got wrong display > name: %s.\n", wine_dbgstr_w(displayname)); > > + > > + shellitem2 = (void*)0xdeadbeef; > > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, > testfileW, NULL, &IID_IShellItem, > > + (void**)&shellitem2); > > + ok(ret == S_OK, "SHCreateItemFromRelativeName failed: > 0x%08x.\n", ret); > > + ret = IShellItem_Compare(shellitem, shellitem2, 0, &order); > > + ok(ret == S_OK, "IShellItem_Compare failed: 0x%08x.\n", > ret); > > + ok(!order, "order got wrong value: %d.\n", order); > > + IShellItem_Release(shellitem2); > > + > > + shellitem2 = (void*)0xdeadbeef; > > + ret = IShellFolder_ParseDisplayName(desktopfolder, NULL, > NULL, testfileW, NULL, > > + &pidl_desktop_testfile, > NULL); > > + ok(ret == S_OK, "ParseDisplayName failed 0x%08x.\n", ret); > > + ret = pSHCreateItemFromIDList(pidl_desktop_testfile, > &IID_IShellItem, (void**)&shellitem2); > > + ret = IShellItem_Compare(shellitem, shellitem2, 0, &order); > > + ok(ret == S_OK, "IShellItem_Compare fail: 0x%08x.\n", ret); > > + ok(!order, "order got wrong value: %d.\n", order); > > + pILFree(pidl_desktop_testfile); > > + IShellItem_Release(shellitem2); > > + > > + IShellItem_Release(shellitem); > > + } > > + > > + DeleteFileW(testfile_path); > > + CoTaskMemFree(desktop_path); > > + CoTaskMemFree(displayname); > > dipslayname is uninitialized if the 'if' block isn't executed. Either > move this inside the 'if' block, or just get rid of the 'if' > condition. We expect the condition to succeed in all cases anyway. > > Huw. > > > -- Regards, Jactry Zeng

Aug. 14, 2017

Re: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64

by Martin Storsjö

On Mon, 14 Aug 2017, André Hentschel wrote: > Am 14.08.2017 um 12:35 schrieb Martin Storsjo: >> Windows uses a different ABI for va_list on arm64 just like on x86_64. >> >> On x86_64, the calling convention for windows functions is completely >> different from the one on other platforms. On arm64, they're mostly the >> same, with the only exception being variadic functions (where all float >> arguments are passed in integer registers, since the va_list is a single >> pointer). >> >> Any functions using __builtin_ms_va_start need to be decorated with >> __attribute__((ms_abi)). >> >> Add a check in configure for the support of __builtin_ms_va_list >> (both features appared in clang at the same time, in the 5.0 release). >> >> This fixes running binaries that use e.g. printf style functions >> (e.g. midl.exe from the windows 10 sdk), fixing >> https://bugs.winehq.org/show_bug.cgi?id=38886. >> >> Signed-off-by: Martin Storsjo <martin(a)martin.st> >> --- >> clang 5.0, which this requires, isn't yet released, but is in RC2 and >> will probably be released pretty soon. >> --- >> configure.ac | 7 +++++++ >> include/msvcrt/crtdefs.h | 6 +++++- >> include/windef.h | 6 +++++- >> include/wine/test.h | 4 ++-- >> 4 files changed, 19 insertions(+), 4 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index 7d52b24..c33221f 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -179,6 +179,13 @@ case $host in >> CFLAGS="$CFLAGS -marm" >> AC_SUBST(TARGETFLAGS,"-marm") >> ;; >> + aarch64*) >> + AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list]) >> + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])], >> + [AC_MSG_RESULT([yes])], >> + [AC_MSG_RESULT([no]) >> + AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])]) > > Hi, > > The upstreamed variadic function handling is terrific, thanks for that! > I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... > At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. > It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... > On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 Yeah, I was a little worried about this, but I thought that making this part conditional in the headers would make it quite messy, for something that is mostly transitional anyway. Now the other question is who would be willing to implement the same in gcc. Since it requires changes to the implementation of va_start (which, at least in llvm, is pretty closely tied with the implementation of stack frame handling and callee register saving), it's a much larger task than I originally thought when I embarked on it. In June, I tried grepping the gcc tree for the relevant keywords, but I decided to skip it for now. // Martin

Aug. 14, 2017

Re: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64

by André Hentschel

Am 14.08.2017 um 12:35 schrieb Martin Storsjo: > Windows uses a different ABI for va_list on arm64 just like on x86_64. > > On x86_64, the calling convention for windows functions is completely > different from the one on other platforms. On arm64, they're mostly the > same, with the only exception being variadic functions (where all float > arguments are passed in integer registers, since the va_list is a single > pointer). > > Any functions using __builtin_ms_va_start need to be decorated with > __attribute__((ms_abi)). > > Add a check in configure for the support of __builtin_ms_va_list > (both features appared in clang at the same time, in the 5.0 release). > > This fixes running binaries that use e.g. printf style functions > (e.g. midl.exe from the windows 10 sdk), fixing > https://bugs.winehq.org/show_bug.cgi?id=38886. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > clang 5.0, which this requires, isn't yet released, but is in RC2 and > will probably be released pretty soon. > --- > configure.ac | 7 +++++++ > include/msvcrt/crtdefs.h | 6 +++++- > include/windef.h | 6 +++++- > include/wine/test.h | 4 ++-- > 4 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 7d52b24..c33221f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -179,6 +179,13 @@ case $host in > CFLAGS="$CFLAGS -marm" > AC_SUBST(TARGETFLAGS,"-marm") > ;; > + aarch64*) > + AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list]) > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])], > + [AC_MSG_RESULT([yes])], > + [AC_MSG_RESULT([no]) > + AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])]) Hi, The upstreamed variadic function handling is terrific, thanks for that! I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 OK... We need this improvement, I'll sign it off :) Now, we only need to convince distributions to avoid x18

Aug. 14, 2017

Re: [2/3 v4] shell32: Implement SHCreateItemInKnownFolder.

by Huw Davies

On Sat, Aug 12, 2017 at 11:42:43PM +0800, Jactry Zeng wrote: > Superseded patch 136380. > > ChangLog: > v4: > - Using SHCreateItemFromRelativeName() for implementing > SHCreateItemInKnownFolder(); > - Fix a logic error in tests. > v3: > - Load SHGetKnownFolderPath() dynamically. > v2: > - Using SHGetKnownFolderIDList() instead of SHGetKnownFolderPath() and > IShellFolder_ParseDisplayName(); > - Add more tests. > > Signed-off-by: Jactry Zeng <jzen g(a)codeweavers.com> > --- > dlls/shell32/shell32.spec | 1 + > dlls/shell32/shellitem.c | 35 +++++++++++++ > dlls/shell32/tests/shlfolder.c | 111 > +++++++++++++++++++++++++++++++++++++++++ > include/shobjidl.idl | 1 + > 4 files changed, 148 insertions(+) > This and patch 3/3 look good to me, so just fix up 1/3 and resend the series. Huw.

Aug. 14, 2017

Re: [1/3] shell32: Implement SHCreateItemFromRelativeName.

by Huw Davies

On Sat, Aug 12, 2017 at 11:42:40PM +0800, Jactry Zeng wrote: > +HRESULT WINAPI SHCreateItemFromRelativeName(IShellItem *parent, PCWSTR name, IBindCtx *pbc, > + REFIID riid, void **ppv) > +{ > + LPITEMIDLIST pidl_folder = NULL, pidl = NULL; > + IShellFolder *desktop = NULL, *folder = NULL; > + HRESULT hr; > + > + TRACE("(%p, %p, %p, %s, %p)\n", parent, name, pbc, debugstr_guid(riid), ppv); Use debugstr_w() to trace 'name'. > + > + if(!ppv) > + return E_INVALIDARG; > + *ppv = NULL; > + if(!name) > + return E_INVALIDARG; > + > + hr = SHGetIDListFromObject((IUnknown*)parent, &pidl_folder); > + if(hr != S_OK) > + return hr; > + > + hr = SHGetDesktopFolder(&desktop); > + if(hr != S_OK) > + goto cleanup; > + > + if(!_ILIsDesktop(pidl_folder)) > + { > + hr = IShellFolder_BindToObject(desktop, pidl_folder, pbc, &IID_IShellFolder, > + (void**)&folder); You should pass a NULL IBindCtx here. pbc is associated with binding the name. > + if(hr != S_OK) > + goto cleanup; > + } > + > + hr = IShellFolder_ParseDisplayName(folder ? folder : desktop, NULL, pbc, (LPWSTR)name, > + NULL, &pidl, NULL); > + if(hr != S_OK) > + goto cleanup; > + hr = SHCreateItemFromIDList(pidl, riid, ppv); > + > diff --git a/dlls/shell32/tests/shlfolder.c b/dlls/shell32/tests/shlfolder.c > index 9e7127dfea..cbab88035a 100644 > --- a/dlls/shell32/tests/shlfolder.c > +++ b/dlls/shell32/tests/shlfolder.c > @@ -2519,6 +2523,86 @@ static void test_SHCreateShellItem(void) > else > win_skip("No SHCreateItemFromIDList\n"); > > + /* SHCreateItemFromRelativeName */ > + if(pSHCreateItemFromRelativeName && pSHGetKnownFolderPath) > + { > + IShellItem *shellitem_desktop = NULL; > + WCHAR *desktop_path, *displayname; > + WCHAR testfile_path[MAX_PATH] = {0}; > + HANDLE file; > + LPITEMIDLIST pidl_desktop_testfile = NULL; > + int order; > + > + ret = pSHCreateShellItem(NULL, NULL, pidl_desktop, &shellitem_desktop); > + ok(ret == S_OK, "SHCreateShellItem failed: 0x%08x.\n", ret); > + > + shellitem = (void*)0xdeadbeef; > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, NULL, NULL, &IID_IShellItem, > + (void**)&shellitem); > + ok(ret == E_INVALIDARG, "Expected 0x%08x but SHCreateItemFromRelativeName return: 0x%08x.\n", > + E_INVALIDARG, ret); > + ok(shellitem == NULL, "shellitem was %p.\n", shellitem); > + > + /* Test with a non-existent file */ > + shellitem = (void*)0xdeadbeef; > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, testfileW, NULL, &IID_IShellItem, > + (void**)&shellitem); > + ok(ret == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected 0x%08x but SHCreateItemFromRelativeName return: 0x%08x.\n", > + HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), ret); > + ok(shellitem == NULL, "shellitem was %p.\n", shellitem); > + > + /* Create a file for testing in desktop folder */ > + pSHGetKnownFolderPath(&FOLDERID_Desktop, 0, NULL, &desktop_path); > + lstrcatW(testfile_path, desktop_path); > + myPathAddBackslashW(testfile_path); > + lstrcatW(testfile_path, testfileW); > + file = CreateFileW(testfile_path, GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, NULL); > + ok(file != INVALID_HANDLE_VALUE, "CreateFileW failed! Last error: 0x%08x.\n", GetLastError()); > + CloseHandle(file); > + > + shellitem = (void*)0xdeadbeef; > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, testfileW, NULL, &IID_IShellItem, > + (void**)&shellitem); > + ok(ret == S_OK, "SHCreateItemFromRelativeName failed: 0x%08x.\n", ret); > + ok(shellitem != NULL, "shellitem was %p.\n", shellitem); > + if(SUCCEEDED(ret)) > + { > + ret = IShellItem_GetDisplayName(shellitem, 0, &displayname); > + ok(ret == S_OK, "IShellItem_GetDisplayName failed: 0x%08x.\n", ret); > + ok(!lstrcmpW(displayname, testfileW), "got wrong display name: %s.\n", wine_dbgstr_w(displayname)); > + > + shellitem2 = (void*)0xdeadbeef; > + ret = pSHCreateItemFromRelativeName(shellitem_desktop, testfileW, NULL, &IID_IShellItem, > + (void**)&shellitem2); > + ok(ret == S_OK, "SHCreateItemFromRelativeName failed: 0x%08x.\n", ret); > + ret = IShellItem_Compare(shellitem, shellitem2, 0, &order); > + ok(ret == S_OK, "IShellItem_Compare failed: 0x%08x.\n", ret); > + ok(!order, "order got wrong value: %d.\n", order); > + IShellItem_Release(shellitem2); > + > + shellitem2 = (void*)0xdeadbeef; > + ret = IShellFolder_ParseDisplayName(desktopfolder, NULL, NULL, testfileW, NULL, > + &pidl_desktop_testfile, NULL); > + ok(ret == S_OK, "ParseDisplayName failed 0x%08x.\n", ret); > + ret = pSHCreateItemFromIDList(pidl_desktop_testfile, &IID_IShellItem, (void**)&shellitem2); > + ret = IShellItem_Compare(shellitem, shellitem2, 0, &order); > + ok(ret == S_OK, "IShellItem_Compare fail: 0x%08x.\n", ret); > + ok(!order, "order got wrong value: %d.\n", order); > + pILFree(pidl_desktop_testfile); > + IShellItem_Release(shellitem2); > + > + IShellItem_Release(shellitem); > + } > + > + DeleteFileW(testfile_path); > + CoTaskMemFree(desktop_path); > + CoTaskMemFree(displayname); dipslayname is uninitialized if the 'if' block isn't executed. Either move this inside the 'if' block, or just get rid of the 'if' condition. We expect the condition to succeed in all cases anyway. Huw.

Aug. 14, 2017

Re: [PATCH] mfplat: Add MFTEnumEx stub.

by Alistair Leslie-Hughes

Hi Andrey, On 14/08/17 19:59, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > + * MFTEnumEx (mfplat.@) > + */ > +HRESULT WINAPI MFTEnumEx(GUID category, UINT32 flags, const MFT_REGISTER_TYPE_INFO *input_type, > + const MFT_REGISTER_TYPE_INFO *output_type, IMFActivate ***activate, > + UINT32 *pcount) > +{ > + FIXME("(%s, %x, %p, %p, %p, %p): stub\n", debugstr_guid(&category), flags, input_type, > + output_type, activate, pcount); > + return S_OK; > +} If you must return S_OK, please set pcount to 0. (maybe rename pcount to count at the same time). Alistair.

Aug. 14, 2017

Re: [PATCH] wined3d: Reduce timeout value to avoid GL_TIMEOUT_EXPIRED on macOS

by Henri Verbeet

On 12 August 2017 at 16:29, Robert Xiao <brx(a)cs.cmu.edu> wrote: > Hmm, I did not know that. Can we do > > ((GLuint64)1) << 62 > Yeah, that should work. Not sure there's a reason to prefer it over "~(GLuint64)0 >> 1" though. > Also, I am a little confused about your comment that the patch doesn't > preserve the low bits. My aim was to keep 0xffff0000 in the low 32 bits - > doesn't "- 0xffff" achieve that goal? > No, that gets you 0x3fffffffffff0001. But as I said, I don't think it matters. ~0xffff was chosen because it was an easy to write value smaller than 0xfffffffffffffbff, not because it was otherwise special.

Aug. 12, 2017

Re: [PATCH] wined3d: Reduce timeout value to avoid GL_TIMEOUT_EXPIRED on macOS

by Robert Xiao

Hmm, I did not know that. Can we do ((GLuint64)1) << 62 Also, I am a little confused about your comment that the patch doesn't preserve the low bits. My aim was to keep 0xffff0000 in the low 32 bits - doesn't "- 0xffff" achieve that goal? Thanks for your feedback. Robert On Sat, Aug 12, 2017 at 05:28 Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 12 August 2017 at 11:06, <nneonneo(a)gmail.com> wrote: > > - /* Apple seems to be into arbitrary limits, and timeouts larger > than > > - * 0xfffffffffffffbff immediately return GL_TIMEOUT_EXPIRED. We > don't > > - * really care and can live with waiting a few μs less. (OS X > 10.7.4). */ > > + /* Timeouts near 0xffffffffffffffff may immediately return > GL_TIMEOUT_EXPIRED, > > + * possibly because macOS internally adds some slop to the > timer. To avoid this, > > + * we use a large number that isn't near the point of overflow > (macOS 10.12.5). > > + */ > > GLenum gl_ret = GL_EXTCALL(glClientWaitSync(fence->object.sync, > > - GL_SYNC_FLUSH_COMMANDS_BIT, ~(GLuint64)0xffff)); > > + GL_SYNC_FLUSH_COMMANDS_BIT, (GLuint64)((1ULL << 62ULL) > - 0xffff))); > Adjusting the workaround is probably fine, but ULL literals are not > portable. Does something along the lines of "~(GLuint64)0 >> 1" work > as well? I don't think we care about the low bits, but note that the > patch as it is doesn't actually preserve them. >

Aug. 12, 2017

Re: [PATCH] wined3d: Reduce timeout value to avoid GL_TIMEOUT_EXPIRED on macOS

by Henri Verbeet

On 12 August 2017 at 11:06, <nneonneo(a)gmail.com> wrote: > - /* Apple seems to be into arbitrary limits, and timeouts larger than > - * 0xfffffffffffffbff immediately return GL_TIMEOUT_EXPIRED. We don't > - * really care and can live with waiting a few μs less. (OS X 10.7.4). */ > + /* Timeouts near 0xffffffffffffffff may immediately return GL_TIMEOUT_EXPIRED, > + * possibly because macOS internally adds some slop to the timer. To avoid this, > + * we use a large number that isn't near the point of overflow (macOS 10.12.5). > + */ > GLenum gl_ret = GL_EXTCALL(glClientWaitSync(fence->object.sync, > - GL_SYNC_FLUSH_COMMANDS_BIT, ~(GLuint64)0xffff)); > + GL_SYNC_FLUSH_COMMANDS_BIT, (GLuint64)((1ULL << 62ULL) - 0xffff))); Adjusting the workaround is probably fine, but ULL literals are not portable. Does something along the lines of "~(GLuint64)0 >> 1" work as well? I don't think we care about the low bits, but note that the patch as it is doesn't actually preserve them.

Aug. 12, 2017

Re: [PATCH resend 1/2] krnl386.exe16: Use toupper() instead of RtlUpperChar().

by Zebediah Figura

On 08/11/2017 09:13 PM, Alexandre Julliard wrote: > Zebediah Figura <z.figura12(a)gmail.com> writes: > >> Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> >> --- >> dlls/krnl386.exe16/ne_module.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) > > I don't think that's a good idea. Why do you need that? > It's not necessary; it was just intended as a bit of a simplification.

Aug. 12, 2017

Re: [PATCH resend 1/2] krnl386.exe16: Use toupper() instead of RtlUpperChar().

by Alexandre Julliard

Zebediah Figura <z.figura12(a)gmail.com> writes: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/krnl386.exe16/ne_module.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) I don't think that's a good idea. Why do you need that? -- Alexandre Julliard julliard(a)winehq.org

Aug. 12, 2017

Re: [PATCH v3 2/5] ieproxy: Add stub DLL.

by Jacek Caban

On 11.08.2017 16:49, Zebediah Figura wrote: > On 08/11/2017 09:47 AM, Jacek Caban wrote: >> On 10.08.2017 20:52, Zebediah Figura wrote: >>> --- a/loader/wine.inf.in >>> +++ b/loader/wine.inf.in >>> @@ -2559,6 +2559,7 @@ HKLM,%CurrentVersion%\Telephony\Country >>> List\998,"SameAreaRule",,"G" >>> 11,,msxml6.dll >>> 11,,shdocvw.dll >>> 16422,Internet Explorer,iexplore.exe >>> +16422,Internet Explorer,ieproxy.dll >>> 16422,Windows Media Player,wmplayer.exe >>> 16422,Windows NT\Accessories,wordpad.exe >>> 11,,* >>> @@ -2613,6 +2614,7 @@ HKLM,%CurrentVersion%\Telephony\Country >>> List\998,"SameAreaRule",,"G" >>> 16410,Microsoft, >>> 16412,Microsoft, >>> 16422,Internet Explorer,iexplore.exe >>> +16422,Internet Explorer,ieproxy.dll >> >> >> Are you sure about it? It's in regular system32 (and syswow64) on my >> Win10. >> >> >> Jacek >> > > It's in that folder on my Win7. I'm not sure it matters, of course. In that case it probably doesn't matter in practice, yeah. I think it's better for us to use simpler solution requiring no special treatment, so please leave it in system32. Jacek

Aug. 11, 2017

Re: [PATCH v3 2/5] ieproxy: Add stub DLL.

by Zebediah Figura

On 08/11/2017 09:47 AM, Jacek Caban wrote: > On 10.08.2017 20:52, Zebediah Figura wrote: >> --- a/loader/wine.inf.in >> +++ b/loader/wine.inf.in >> @@ -2559,6 +2559,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,"SameAreaRule",,"G" >> 11,,msxml6.dll >> 11,,shdocvw.dll >> 16422,Internet Explorer,iexplore.exe >> +16422,Internet Explorer,ieproxy.dll >> 16422,Windows Media Player,wmplayer.exe >> 16422,Windows NT\Accessories,wordpad.exe >> 11,,* >> @@ -2613,6 +2614,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,"SameAreaRule",,"G" >> 16410,Microsoft, >> 16412,Microsoft, >> 16422,Internet Explorer,iexplore.exe >> +16422,Internet Explorer,ieproxy.dll > > > Are you sure about it? It's in regular system32 (and syswow64) on my Win10. > > > Jacek > It's in that folder on my Win7. I'm not sure it matters, of course.

Aug. 11, 2017

Re: [PATCH v3 2/5] ieproxy: Add stub DLL.

by Jacek Caban

On 10.08.2017 20:52, Zebediah Figura wrote: > --- a/loader/wine.inf.in > +++ b/loader/wine.inf.in > @@ -2559,6 +2559,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,"SameAreaRule",,"G" > 11,,msxml6.dll > 11,,shdocvw.dll > 16422,Internet Explorer,iexplore.exe > +16422,Internet Explorer,ieproxy.dll > 16422,Windows Media Player,wmplayer.exe > 16422,Windows NT\Accessories,wordpad.exe > 11,,* > @@ -2613,6 +2614,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,"SameAreaRule",,"G" > 16410,Microsoft, > 16412,Microsoft, > 16422,Internet Explorer,iexplore.exe > +16422,Internet Explorer,ieproxy.dll Are you sure about it? It's in regular system32 (and syswow64) on my Win10. Jacek

Aug. 11, 2017

Re: [PATCH v5 1/5] include: Add initial ieautomation.idl

by Jacek Caban

On 11.08.2017 16:10, Zebediah Figura wrote: > +cpp_quote("#define INTERNETEXPLORERCONFIGURATION_HOST 0x00000001") This should be a value of INTERNETEXPLORERCONFIGURATION enum. Jacek

Aug. 11, 2017

Re: [PATCH v4 1/5] include: Add initial ieautomation.idl

by Jacek Caban

On 11.08.2017 15:54, Zebediah Figura wrote: > + */ > + > +import "unknwn.idl"; One more thing I didn't notice earlier: this should be ocidl.idl. Jacek

Aug. 11, 2017

Re: [v3 5/5] kernel32/tests: Add tests for LoadLibrary with LIBRARY_SEARCH_* flags

by Carlos Palminha

Hi, My patch with test is producing a strange result in Test Bot. I'm getting a ERROR_NOT_ENOUGH_MEMORY when calling LoadLibraryExA only in Vista and Win2008 64bit. Any hint? Regards, C.Palminha On 11-08-2017 11:39, Carlos Palminha wrote: > Test LIBRARY_SEARCH_* flags when loading libraries. > Uses helper from path.c to create the test dll file. > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > v3: > - Improved check for Win2003 cases > > v2: > - Split the tests affecting different files > - Tests checks for Win2003 cases > > dlls/kernel32/tests/module.c | 132 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 131 insertions(+), 1 deletion(-) > > diff --git a/dlls/kernel32/tests/module.c b/dlls/kernel32/tests/module.c > index bb22c24316c..96dd3277c1b 100644 > --- a/dlls/kernel32/tests/module.c > +++ b/dlls/kernel32/tests/module.c > @@ -407,6 +407,136 @@ static void testLoadLibraryEx(void) > FreeLibrary(hmodule); > } > > +/* use some functions and strcutures from loader.c */ > +extern DWORD create_test_dll( const IMAGE_DOS_HEADER *dos_header, UINT dos_size, > + const IMAGE_NT_HEADERS *nt_header, const char *dll_name ); > +extern const IMAGE_NT_HEADERS nt_header_template; > + > +static void testLoadLibraryExSearchFlags(void) > +{ > + HMODULE hmodule; > + char tmpPath[MAX_PATH]; > + char dllName[] = "testFlags.dll"; > + char tmpFullFile[MAX_PATH]; > + char sysFullFile[MAX_PATH]; > + IMAGE_DOS_HEADER dos_header; > + IMAGE_NT_HEADERS nt_header; > + ULONG file_size; > + char fullPath[MAX_PATH]; > + DWORD version; > + BOOL is_win2003 = FALSE; > + > + GetTempPathA(MAX_PATH, tmpPath); > + lstrcpyA(tmpFullFile, tmpPath); > + lstrcatA(tmpFullFile, dllName); > + > + /* check for required function */ > + if (!pSetDllDirectoryA) > + { > + win_skip("SetDllDirectoryA not available\n"); > + return; > + } > + > + /* check if we are in win2003... flags are not supported */ > + version = GetVersion(); > + if ((LOBYTE(LOWORD(version)) == 5) && (HIBYTE(LOWORD(version))==2)) > + is_win2003 = TRUE; > + > + /* try to load test dll from test path before creating it*/ > + SetLastError(0xdeadbeef); > + pSetDllDirectoryA(tmpPath); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_USER_DIRS); > + ok (hmodule == NULL, "Test library %s should not be loaded from %s\n", dllName, tmpPath); > + ok( GetLastError() == ERROR_MOD_NOT_FOUND || GetLastError() == ERROR_DLL_NOT_FOUND || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + pSetDllDirectoryA(NULL); > + > + /* create test library */ > + lstrcpyA(fullPath, tmpPath); > + lstrcatA(fullPath, dllName); > + > + dos_header.e_magic = IMAGE_DOS_SIGNATURE; > + dos_header.e_lfanew = sizeof(dos_header); > + > + nt_header = nt_header_template; > + > + nt_header.FileHeader.NumberOfSections = 1; > + nt_header.FileHeader.SizeOfOptionalHeader = sizeof(IMAGE_OPTIONAL_HEADER); > + nt_header.OptionalHeader.SectionAlignment = 0x1000; > + nt_header.OptionalHeader.FileAlignment = 0x1000; > + nt_header.OptionalHeader.SizeOfImage = sizeof(dos_header) + sizeof(nt_header_template) + sizeof(IMAGE_SECTION_HEADER) + 0x1000; > + nt_header.OptionalHeader.SizeOfHeaders = sizeof(dos_header) + sizeof(nt_header_template) + sizeof(IMAGE_SECTION_HEADER); > + > + file_size = create_test_dll(&dos_header, sizeof(dos_header), &nt_header, fullPath); > + ok( file_size, "could not create '%s'\n",fullPath); > + > + /* try to load test dll without specifying the test path */ > + SetLastError(0xdeadbeef); > + pSetDllDirectoryA(NULL); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_USER_DIRS); > + ok (hmodule == NULL, "Test library should not be loaded from 'NULL' path\n"); > + ok( GetLastError() == ERROR_MOD_NOT_FOUND || GetLastError() == ERROR_DLL_NOT_FOUND || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + > + /* try to load test dll from test path */ > + SetLastError(0xdeadbeef); > + pSetDllDirectoryA(tmpPath); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_USER_DIRS); > + if(is_win2003) > + ok (hmodule == NULL, "Test library should not be loaded from %s in Win2003 (flag not supported)\n", tmpPath); > + else > + ok (hmodule != NULL, "Could not load test library %s from %s\n", dllName, tmpPath); > + ok(GetLastError() == 0xdeadbeef || GetLastError() == ERROR_SUCCESS || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected 0xdeadbeef or ERROR_SUCCESS or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + pSetDllDirectoryA(NULL); > + > + /* load non-existing test dll from system32 */ > + SetLastError(0xdeadbeef); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32); > + ok(hmodule == NULL, "%s should not be loaded\n", dllName); > + ok( GetLastError() == ERROR_MOD_NOT_FOUND || GetLastError() == ERROR_DLL_NOT_FOUND || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + > + /* move library from temp path to system32 and delete from old path */ > + GetWindowsDirectoryA(sysFullFile,MAX_PATH); > + lstrcatA(sysFullFile,"\\system32\\"); > + lstrcatA(sysFullFile, dllName); > + MoveFileA(tmpFullFile,sysFullFile); > + DeleteFileA(tmpFullFile); > + > + /* try to load dll using more than one flag */ > + pSetDllDirectoryA(tmpPath); > + SetLastError(0xdeadbeef); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_USER_DIRS | LOAD_LIBRARY_SEARCH_SYSTEM32); > + if(is_win2003) > + ok (hmodule == NULL, "Test library should not be loaded from 'system32' in Win2003 (flag not supported)\n"); > + else > + ok (hmodule != NULL, "Library %s was expected to be loaded from 'system32'\n", dllName); > + ok(GetLastError() == 0xdeadbeef || GetLastError() == ERROR_SUCCESS || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected 0xdeadbeef or ERROR_SUCCESS or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + pSetDllDirectoryA(NULL); > + > + /* try to load test dll from system32 */ > + SetLastError(0xdeadbeef); > + hmodule = LoadLibraryExA(dllName, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32); > + if(is_win2003) > + ok (hmodule == NULL, "Test library should not be loaded from 'system32' in Win2003 (flag not supported)\n"); > + else > + ok (hmodule != NULL, "Library %s was expected to be loaded from 'system32'\n", dllName); > + ok(GetLastError() == 0xdeadbeef || GetLastError() == ERROR_SUCCESS || GetLastError() == ERROR_INVALID_PARAMETER, > + "Expected 0xdeadbeef or ERROR_SUCCESS or ERROR_INVALID_PARAMETER (win2003), got %d\n", GetLastError()); > + FreeLibrary(hmodule); > + > + /* delete test dll from system32 directory */ > + DeleteFileA(sysFullFile); > + > +} > + > static void testGetDllDirectory(void) > { > CHAR bufferA[MAX_PATH]; > @@ -744,7 +874,6 @@ START_TEST(module) > WCHAR filenameW[MAX_PATH]; > > /* Test if we can use GetModuleFileNameW */ > - > SetLastError(0xdeadbeef); > GetModuleFileNameW(NULL, filenameW, MAX_PATH); > if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > @@ -766,6 +895,7 @@ START_TEST(module) > testLoadLibraryA_Wrong(); > testGetProcAddress_Wrong(); > testLoadLibraryEx(); > + testLoadLibraryExSearchFlags(); > testGetModuleHandleEx(); > testK32GetModuleInformation(); > } >

Aug. 11, 2017

Re: [PATCH v3 1/5] include: Add initial ieautomation.idl

by Jacek Caban

On 10.08.2017 20:52, Zebediah Figura wrote: > + > +cpp_quote("DEFINE_GUID(CLSID_InternetExplorerManager, 0xdf4fcc34, 0x067a, 0x4e0a, 0x83,0x52, 0x4a,0x1a,0x50,0x95,0x34,0x6e);") Please use coclass, like in PSDK, instead. Jacek

Aug. 11, 2017

Re: [v3 5/5] kernel32/tests: Add tests for LoadLibrary with LIBRARY_SEARCH_* flags

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=32633 Your paranoid android. === wvistau64 (32 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === w2008s64 (32 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === wvistau64 (64 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8 === w2008s64 (64 bit module) === module.c:479: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x) or ERROR_INVALID_PARAMETER (win2003), got 8

Aug. 11, 2017

Re: [PATCH] comctl32/listview: Keep the active item selected after hwndEdit is destroyed

by Hugh McMaster

On Thursday, 10 August 2017 11:43 PM, Nikolay Sivov wrote: > Could you describe how I should be testing this? On Windows, when you have finished editing a listview item, you can either press Return or left-click in an empty area of the listview control to exit and update the item. In both cases, the item retains the selection rectangle. On Wine, this only happens after pressing the Return key. The source shows that we are deselecting all items on left mouse click in LISTVIEW_LButtonDown(). Note that we correctly maintain selection while clicking in empty space and holding either the Ctrl or Shift keys.

Aug. 11, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Jacek Caban

On 10.08.2017 20:28, Zebediah Figura wrote: > It seems like it would be correct to register IEM when -startmanager > is passed and IE otherwise. Yes, that sounds right. Jacek

Aug. 10, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Zebediah Figura

On 08/10/2017 01:01 PM, Jacek Caban wrote: > On 10.08.2017 18:47, Zebediah Figura wrote: >> On 08/10/2017 09:33 AM, Jacek Caban wrote: >>> On 09.08.2017 20:12, Zebediah Figura wrote: >>>> On 08/09/2017 06:07 AM, Jacek Caban wrote: >>>>> >>>>> Are you sure that's how it's supposed to work? I didn't test it >>>>> myself, but given how it's registered and documented, I'd expect >>>>> that CLSID_InternetExplorerManager should live in a different >>>>> process from CLSID_InternetExplorer. It should be easy to >>>>> distinguish those processes with -startmanager command line argument. >>>>> >>>> >>>> I'm sorry, I don't understand what you mean. Isn't >>>> CoRegisterClassObject process-agnostic? >>> >>> >>> It is in a sense that created proxy/stub abstract where the object >>> lives, yes. But note that the actual instance of IE object must live >>> in one process or another. There is a lot of different aspects like >>> pluggable protocols, script engines, ActiveX objects, document >>> objects that live in its process and it's quite important for them >>> which process it is. I did a bit of testing and it seems to be a >>> separated process on Windows, so we should follow that. >>> >>> >>> Jacek >>> >> >> Isn't the IEM object already created in a different process with this >> patch (namely, iexplore.exe -startmanager), since it has to be created >> with CLSCTX_LOCAL_SERVER? > > Not really, see how CoRegisterClassObject is used. With your patches a > single process (both with -embeding and -startmanager arguments) > registers both CLSID_InternetExplorer and CLSID_InternetExplorerManager > with REGCLS_MULTIPLEUSE. It means that all instances of both objects > will live in this single process. I think that -embeding should register > CLSID_InternetExplorer and -startmanager should register > CLSID_InternetExplorerManager (probably with REGCLS_SINGLEUSE). > Ah, I see. I'm not sure that's quite right, though, since creating a IEM instance will pass both options. It seems like it would be correct to register IEM when -startmanager is passed and IE otherwise.

Aug. 10, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Jacek Caban

On 10.08.2017 18:47, Zebediah Figura wrote: > On 08/10/2017 09:33 AM, Jacek Caban wrote: >> On 09.08.2017 20:12, Zebediah Figura wrote: >>> On 08/09/2017 06:07 AM, Jacek Caban wrote: >>>> >>>> Are you sure that's how it's supposed to work? I didn't test it >>>> myself, but given how it's registered and documented, I'd expect >>>> that CLSID_InternetExplorerManager should live in a different >>>> process from CLSID_InternetExplorer. It should be easy to >>>> distinguish those processes with -startmanager command line argument. >>>> >>> >>> I'm sorry, I don't understand what you mean. Isn't >>> CoRegisterClassObject process-agnostic? >> >> >> It is in a sense that created proxy/stub abstract where the object >> lives, yes. But note that the actual instance of IE object must live >> in one process or another. There is a lot of different aspects like >> pluggable protocols, script engines, ActiveX objects, document >> objects that live in its process and it's quite important for them >> which process it is. I did a bit of testing and it seems to be a >> separated process on Windows, so we should follow that. >> >> >> Jacek >> > > Isn't the IEM object already created in a different process with this > patch (namely, iexplore.exe -startmanager), since it has to be created > with CLSCTX_LOCAL_SERVER? Not really, see how CoRegisterClassObject is used. With your patches a single process (both with -embeding and -startmanager arguments) registers both CLSID_InternetExplorer and CLSID_InternetExplorerManager with REGCLS_MULTIPLEUSE. It means that all instances of both objects will live in this single process. I think that -embeding should register CLSID_InternetExplorer and -startmanager should register CLSID_InternetExplorerManager (probably with REGCLS_SINGLEUSE). > And using CoCreateInstance, as with my previous patch, should also > create an InternetExplorer instance in another process? Not with your patch series, but when you get CoRegisterClassObject right then yes, it may be actually the right thing to do. > I don't understand DCOM very well. Perhaps you could expound on said > testing? I created an instance of CLSID_InternetExplorerManager and watched task manager for new iexplore.exe processes. I admit that it's not the most sophisticated testing ;) Jacek

Aug. 10, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Zebediah Figura

On 08/10/2017 09:33 AM, Jacek Caban wrote: > On 09.08.2017 20:12, Zebediah Figura wrote: >> On 08/09/2017 06:07 AM, Jacek Caban wrote: >>> Hi Zebediah, >>> >>> On 08.08.2017 20:04, Zebediah Figura wrote: >>>> HRESULT register_class_object(BOOL do_reg) >>>> { >>>> HRESULT hres; >>>> - static DWORD cookie; >>>> + static DWORD ie_cookie, iem_cookie; >>>> if(do_reg) { >>>> hres = CoRegisterClassObject(&CLSID_InternetExplorer, >>>> (IUnknown*)&InternetExplorerFactory, CLSCTX_SERVER, >>>> - REGCLS_MULTIPLEUSE|REGCLS_SUSPENDED, &cookie); >>>> - if (FAILED(hres)) { >>>> + REGCLS_MULTIPLEUSE, &ie_cookie); >>>> + if (FAILED(hres)) >>>> + ERR("failed to register object %08x\n", hres); >>>> + hres = CoRegisterClassObject(&CLSID_InternetExplorerManager, >>>> + (IUnknown*)&InternetExplorerManagerFactory, CLSCTX_SERVER, >>>> + REGCLS_MULTIPLEUSE, &iem_cookie); >>>> + if (FAILED(hres)) >>>> ERR("failed to register object %08x\n", hres); >>>> - return hres; >>>> - } >>>> - >>>> - hres = CoResumeClassObjects(); >>>> - if(SUCCEEDED(hres)) >>>> - return hres; >>>> - >>>> - ERR("failed to resume object %08x\n", hres); >>>> } >>>> - >>>> - return CoRevokeClassObject(cookie); >>>> + else >>>> + { >>>> + hres = CoRevokeClassObject(ie_cookie); >>>> + if (FAILED(hres)) >>>> + ERR("failed to register object %08x\n", hres); >>>> + hres = CoRevokeClassObject(iem_cookie); >>>> + if (FAILED(hres)) >>>> + ERR("failed to register object %08x\n", hres); >>>> + } >>>> + return hres; >>>> } >>> >>> Are you sure that's how it's supposed to work? I didn't test it >>> myself, but given how it's registered and documented, I'd expect that >>> CLSID_InternetExplorerManager should live in a different process from >>> CLSID_InternetExplorer. It should be easy to distinguish those >>> processes with -startmanager command line argument. >>> >> >> I'm sorry, I don't understand what you mean. Isn't >> CoRegisterClassObject process-agnostic? > > > It is in a sense that created proxy/stub abstract where the object > lives, yes. But note that the actual instance of IE object must live in > one process or another. There is a lot of different aspects like > pluggable protocols, script engines, ActiveX objects, document objects > that live in its process and it's quite important for them which process > it is. I did a bit of testing and it seems to be a separated process on > Windows, so we should follow that. > > > Jacek > Isn't the IEM object already created in a different process with this patch (namely, iexplore.exe -startmanager), since it has to be created with CLSCTX_LOCAL_SERVER? And using CoCreateInstance, as with my previous patch, should also create an InternetExplorer instance in another process? I don't understand DCOM very well. Perhaps you could expound on said testing?

Aug. 10, 2017

Re: [v3 PATCH 1/2] dwrite: Protect cached fontface list when accessed from multiple threads

by Anton Romanov

> --- snip --- > if (!ref) > { > EnterCriticalSection(...); > list_remove(...); > LeaveCriticalSection(...); > > ... > } > --- snip --- > > And when querying cached font faces: > > --- snip --- > EnterCriticalSection(...); > LIST_FOR_EACH_ENTRY(...) > { > ... > > /* the following code could also be hidden in QueryInterface */ > if (InterlockedIncrement( &obj->refcount ) == 1) > { > InterlockedDecrement( &obj->refcount ); > continue; > } > > /* return it */ > } > LeaveCriticalSection(...); > --- snip --- Doesn't the object just leak in this scenario though ? (assuming current refcount is 1) : ============= =========== Thread A Thread B ============= =========== enter_cs Increment Decrement ref != Zero Decrement leave_cs ============= ===========

Aug. 10, 2017

Re: [PATCH] gdiplus: Support GdipSetClipRegion in metafiles

by Vincent Povirk

+ stat = GdipGetRegionData(region, (BYTE*)object_record + FIELD_OFFSET(EmfPlusObject, Header.Size), size, NULL); + object_record->Header.DataSize = object_record->Header.Size; + object_record->Header.Size = record_size; This is a little too clever. I'd rather have a solution similar to write_path_data.

Aug. 10, 2017

Re: [v4 PATCH 1/2] dwrite: Protect cached fontface list when accessed from multiple threads

by Sebastian Lackner

On 10.08.2017 15:41, Nikolay Sivov wrote: > @@ -861,6 +877,10 @@ HRESULT factory_get_cached_fontface(IDWriteFactory5 *iface, IDWriteFontFile * co > const void *cached_key; > IDWriteFontFile *file; > > + if (IDWriteFontFace4_AddRef(cached->fontface) == 1) > + continue; > + IDWriteFontFace4_Release(cached->fontface); This will not work as expected. The refcount also matters when the object is about to be destroyed. There could be multiple threads running factory_get_cached_fontface() before _Release() can finally remove the fontface from the list. Please note that always calling _Release() also wouldn't be correct because it would run the destructor twice. It is not really necessary to access the private structs from other parts of dwrite, but you should either: * change AddRef to use something like interlocked_dec_if_nonzero (see ntdll/sync.c) * implement the check in QueryInterface (manually run InterlockedDecrement to decrement the refcount without going through the destructor) There are probably also other ways, for example using a flag to make sure the destructor is not called twice. Best regards, Sebastian

Aug. 10, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Jacek Caban

On 09.08.2017 20:12, Zebediah Figura wrote: > On 08/09/2017 06:07 AM, Jacek Caban wrote: >> Hi Zebediah, >> >> On 08.08.2017 20:04, Zebediah Figura wrote: >>> HRESULT register_class_object(BOOL do_reg) >>> { >>> HRESULT hres; >>> - static DWORD cookie; >>> + static DWORD ie_cookie, iem_cookie; >>> if(do_reg) { >>> hres = CoRegisterClassObject(&CLSID_InternetExplorer, >>> (IUnknown*)&InternetExplorerFactory, CLSCTX_SERVER, >>> - REGCLS_MULTIPLEUSE|REGCLS_SUSPENDED, &cookie); >>> - if (FAILED(hres)) { >>> + REGCLS_MULTIPLEUSE, &ie_cookie); >>> + if (FAILED(hres)) >>> + ERR("failed to register object %08x\n", hres); >>> + hres = CoRegisterClassObject(&CLSID_InternetExplorerManager, >>> + (IUnknown*)&InternetExplorerManagerFactory, >>> CLSCTX_SERVER, >>> + REGCLS_MULTIPLEUSE, &iem_cookie); >>> + if (FAILED(hres)) >>> ERR("failed to register object %08x\n", hres); >>> - return hres; >>> - } >>> - >>> - hres = CoResumeClassObjects(); >>> - if(SUCCEEDED(hres)) >>> - return hres; >>> - >>> - ERR("failed to resume object %08x\n", hres); >>> } >>> - >>> - return CoRevokeClassObject(cookie); >>> + else >>> + { >>> + hres = CoRevokeClassObject(ie_cookie); >>> + if (FAILED(hres)) >>> + ERR("failed to register object %08x\n", hres); >>> + hres = CoRevokeClassObject(iem_cookie); >>> + if (FAILED(hres)) >>> + ERR("failed to register object %08x\n", hres); >>> + } >>> + return hres; >>> } >> >> Are you sure that's how it's supposed to work? I didn't test it >> myself, but given how it's registered and documented, I'd expect that >> CLSID_InternetExplorerManager should live in a different process from >> CLSID_InternetExplorer. It should be easy to distinguish those >> processes with -startmanager command line argument. >> > > I'm sorry, I don't understand what you mean. Isn't > CoRegisterClassObject process-agnostic? It is in a sense that created proxy/stub abstract where the object lives, yes. But note that the actual instance of IE object must live in one process or another. There is a lot of different aspects like pluggable protocols, script engines, ActiveX objects, document objects that live in its process and it's quite important for them which process it is. I did a bit of testing and it seems to be a separated process on Windows, so we should follow that. Jacek

Aug. 10, 2017

Re: [PATCH] comctl32/listview: Keep the active item selected after hwndEdit is destroyed

by Nikolay Sivov

Could you describe how should I be testing this?

Aug. 10, 2017

Re: [v3 PATCH 1/2] dwrite: Protect cached fontface list when accessed from multiple threads

by Nikolay Sivov

On 10.08.2017 11:14, Sebastian Lackner wrote: > On 10.08.2017 08:45, Nikolay Sivov wrote: >> Based on patch by Anton Romanov <theli.ua(a)gmail.com> >> >> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >> --- >> dlls/dwrite/dwrite_private.h | 6 ++++-- >> dlls/dwrite/font.c | 24 ++++++++++++--------- >> dlls/dwrite/main.c | 50 +++++++++++++++++++++++++++++++++----------- >> 3 files changed, 56 insertions(+), 24 deletions(-) >> > > Isn't it also necessary to protect factory_cache_fontface()? It is. > > By the way: An alternative method to implement proper synchronization (which does > not require locking critical sections before InterlockedDecrement) would be to do > something like: > > In the destructor: > > --- snip --- > if (!ref) > { > EnterCriticalSection(...); > list_remove(...); > LeaveCriticalSection(...); > > ... > } > --- snip --- Yes, that's better I guess, thanks. > > And when querying cached font faces: > > --- snip --- > EnterCriticalSection(...); > LIST_FOR_EACH_ENTRY(...) > { > ... > > /* the following code could also be hidden in QueryInterface */ > if (InterlockedIncrement( &obj->refcount ) == 1) > { > InterlockedDecrement( &obj->refcount ); > continue; > } > > /* return it */ > } > LeaveCriticalSection(...); > --- snip --- In my case, to avoid exposing structure, it's enough to AddRef() == 1, and release otherwise I think. It's not important to decrement when we're in a process of destroying the object. > > This is also what is done in Wines threadpool implementation [1], and has the > advantage that the CS is not needed for every Release, only when the object is > really destroyed. But in the end it is a matter of taste, for rpcrt4 Jacek > also picked the "hold CS during InterlockedDecrement" method. > > [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/threadpool.c#l… > > Best regards, > Sebastian > >

Aug. 10, 2017

Re: [v3 PATCH 1/2] dwrite: Protect cached fontface list when accessed from multiple threads

by Sebastian Lackner

On 10.08.2017 08:45, Nikolay Sivov wrote: > Based on patch by Anton Romanov <theli.ua(a)gmail.com> > > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/dwrite_private.h | 6 ++++-- > dlls/dwrite/font.c | 24 ++++++++++++--------- > dlls/dwrite/main.c | 50 +++++++++++++++++++++++++++++++++----------- > 3 files changed, 56 insertions(+), 24 deletions(-) > Isn't it also necessary to protect factory_cache_fontface()? By the way: An alternative method to implement proper synchronization (which does not require locking critical sections before InterlockedDecrement) would be to do something like: In the destructor: --- snip --- if (!ref) { EnterCriticalSection(...); list_remove(...); LeaveCriticalSection(...); ... } --- snip --- And when querying cached font faces: --- snip --- EnterCriticalSection(...); LIST_FOR_EACH_ENTRY(...) { ... /* the following code could also be hidden in QueryInterface */ if (InterlockedIncrement( &obj->refcount ) == 1) { InterlockedDecrement( &obj->refcount ); continue; } /* return it */ } LeaveCriticalSection(...); --- snip --- This is also what is done in Wines threadpool implementation [1], and has the advantage that the CS is not needed for every Release, only when the object is really destroyed. But in the end it is a matter of taste, for rpcrt4 Jacek also picked the "hold CS during InterlockedDecrement" method. [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/threadpool.c#l… Best regards, Sebastian

Aug. 10, 2017

Re: [v2 PATCH 2/2] dwrite: Added a helper to check for supported characters

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - TRACE("(%p)->(0x%08x)\n", This, ch); > + TRACE("(%p)->(0x%#x)\n", This, ch); This will cause printing of the 0x prefix twice. Same applies to other places. -- Dmitry.

Aug. 10, 2017

Re: wineandroid: Add suffix to lib directory and wine binary on 64-bit

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > Am 08.08.2017 um 13:16 schrieb Alexandre Julliard: >> André Hentschel <nerv(a)dawncrow.de> writes: >> >>> This fixes at least arm64-v8a builds, where you have lib64/libwine.so and bin/wine64 >>> >>> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >>> --- >>> >>> This and "winebuild: Improved position independent code generation" enable Wine on ARM64 Android phones (e.g. most Android devices). >>> The check for 64 in the CPU_ABI can be discussed, but I think it's reliable and fast. >>> >>> dlls/wineandroid.drv/WineActivity.java | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> We already prefix with the ABI, so I think plain "lib" is better. >> > > The thing is that everything is installed to lib64, should I have a look in changing this? configure --libdir is the easiest, but we could probably change the default. It's not clear that lib64 makes much sense for Linux either these days. > Also it sounds like doing suffix for the wine binary is ok? It shouldn't be needed either, but wow64 support is going to take a bit more work. -- Alexandre Julliard julliard(a)winehq.org

Aug. 10, 2017

Re: [PATCH v2 2/5] include: Add initial ieautomation.idl

by Michael Stefaniuc

On 08/09/2017 06:03 PM, Zebediah Figura wrote: > On 08/09/2017 01:16 AM, Nikolay Sivov wrote: >> On 08.08.2017 21:04, Zebediah Figura wrote: >>> +[ >>> + object, >>> + uuid(acc84351-04ff-44f9-b23f-655ed168c6d5), >>> + oleautomation >>> +] >>> +interface IInternetExplorerManager : IUnknown >>> +{ >>> + HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR >>> url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); >>> +} >> >> This is not how it's defined in SDK - oleautomation is not used there >> and "url" argument has different attributes. >> >> > > Correct my misconception, but I thought consulting the SDK for public > headers wasn't allowed You can consult the SDK public headers as well as examples and what not. You can't copy from the headers. There is one exception though: if you plan to work on MFC then don't look at the MFC headers. ATL might be similar. bye michael

Aug. 9, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Zebediah Figura

On 08/09/2017 06:07 AM, Jacek Caban wrote: > Hi Zebediah, > > On 08.08.2017 20:04, Zebediah Figura wrote: >> HRESULT register_class_object(BOOL do_reg) >> { >> HRESULT hres; >> >> - static DWORD cookie; >> + static DWORD ie_cookie, iem_cookie; >> >> if(do_reg) { >> hres = CoRegisterClassObject(&CLSID_InternetExplorer, >> (IUnknown*)&InternetExplorerFactory, CLSCTX_SERVER, >> - REGCLS_MULTIPLEUSE|REGCLS_SUSPENDED, &cookie); >> - if (FAILED(hres)) { >> + REGCLS_MULTIPLEUSE, &ie_cookie); >> + if (FAILED(hres)) >> + ERR("failed to register object %08x\n", hres); >> + hres = CoRegisterClassObject(&CLSID_InternetExplorerManager, >> + (IUnknown*)&InternetExplorerManagerFactory, CLSCTX_SERVER, >> + REGCLS_MULTIPLEUSE, &iem_cookie); >> + if (FAILED(hres)) >> ERR("failed to register object %08x\n", hres); >> - return hres; >> - } >> - >> - hres = CoResumeClassObjects(); >> - if(SUCCEEDED(hres)) >> - return hres; >> - >> - ERR("failed to resume object %08x\n", hres); >> } >> - >> - return CoRevokeClassObject(cookie); >> + else >> + { >> + hres = CoRevokeClassObject(ie_cookie); >> + if (FAILED(hres)) >> + ERR("failed to register object %08x\n", hres); >> + hres = CoRevokeClassObject(iem_cookie); >> + if (FAILED(hres)) >> + ERR("failed to register object %08x\n", hres); >> + } >> + return hres; >> } > > Are you sure that's how it's supposed to work? I didn't test it myself, > but given how it's registered and documented, I'd expect that > CLSID_InternetExplorerManager should live in a different process from > CLSID_InternetExplorer. It should be easy to distinguish those processes > with -startmanager command line argument. > I'm sorry, I don't understand what you mean. Isn't CoRegisterClassObject process-agnostic? >> +static HRESULT WINAPI InternetExplorerManager_CreateObject(IInternetExplorerManager *iface, DWORD config, LPCWSTR url, REFIID riid, void **ppv) >> +{ >> + FIXME("(%p)->(0x%x, %s, %s, %p) semi-stub\n", iface, config, debugstr_w(url), debugstr_guid(riid), ppv); >> + >> + return CoCreateInstance(&CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER, riid, ppv); >> +} > > Using CoCreateInstance is very questionable here (eg. due to the comment > above). Also, a patch adding a stub should just return E_NOTIMPL. > Implementation deserves a separated patch. I'd expect that it should > just use internal ieframe functions to create a new IE instance. > > Also, I'd suggest to reorder patches to something like: 2, 4, 5, 1 > (likely replaced by support for -startmanager command line argument), 3 > and then a new patch implementing CreateObject. > > Thanks, > Jacek > > > Thanks for the review. I'll reorder the existing patches, but leave out an implementation of CreateObject() until I understand what it should be doing.

Aug. 9, 2017

Re: wineandroid: Add suffix to lib directory and wine binary on 64-bit

by André Hentschel

Am 08.08.2017 um 13:16 schrieb Alexandre Julliard: > André Hentschel <nerv(a)dawncrow.de> writes: > >> This fixes at least arm64-v8a builds, where you have lib64/libwine.so and bin/wine64 >> >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> >> This and "winebuild: Improved position independent code generation" enable Wine on ARM64 Android phones (e.g. most Android devices). >> The check for 64 in the CPU_ABI can be discussed, but I think it's reliable and fast. >> >> dlls/wineandroid.drv/WineActivity.java | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) > > We already prefix with the ABI, so I think plain "lib" is better. > The thing is that everything is installed to lib64, should I have a look in changing this? Also it sounds like doing suffix for the wine binary is ok?

Aug. 9, 2017

Re: [PATCH v2 2/5] include: Add initial ieautomation.idl

by Zebediah Figura

On 08/09/2017 01:16 AM, Nikolay Sivov wrote: > On 08.08.2017 21:04, Zebediah Figura wrote: >> +[ >> + object, >> + uuid(acc84351-04ff-44f9-b23f-655ed168c6d5), >> + oleautomation >> +] >> +interface IInternetExplorerManager : IUnknown >> +{ >> + HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); >> +} > > This is not how it's defined in SDK - oleautomation is not used there > and "url" argument has different attributes. > > Correct my misconception, but I thought consulting the SDK for public headers wasn't allowed?

Aug. 9, 2017

Re: [PATCH v2 5/5] ieproxy: Add proxy/stub for IInternetExplorerManager.

by Zebediah Figura

On 08/09/2017 12:08 AM, Alistair Leslie-Hughes wrote: > Hi Zebediah, > > > On 09/08/17 04:04, Zebediah Figura wrote: >> Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > >> interface IInternetExplorerManager : IUnknown >> { >> - HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); >> + [local] HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); >> + [call_as(CreateObject)] HRESULT RemoteCreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > > The public API doesn't have the RemoteCreateObject function. > > Best Regards > Alistair. > I assumed this was the normal way of handling functions that had to be proxied. How should that be done, then?

Aug. 9, 2017

Re: [PATCH 3/5] setupapi: Fix compiler warnings when converting between pointers and integers on 64-bit systems

by Aric Stewart

Hello, On 8/9/17 5:36 AM, Michael Stefaniuc wrote: > On 08/09/2017 04:26 AM, Hugh McMaster wrote: >> On Tuesday, 8 August 2017 9:04 PM, Alexandre Julliard wrote: >>> That's only hiding the bug. >> >> The basic problem is the use of DWORD in the following structure. On 64-bit >> systems we then see warnings about the sizeof(DWORD) vs sizeof(void *). >> >> /* Pointed to by SP_DEVINFO_DATA's Reserved member */ >> struct DeviceInfo >> { >> struct DeviceInfoSet *set; >> HKEY key; >> BOOL phantom; >> DWORD devId; >> LPWSTR instanceId; >> struct list interfaces; >> }; >> >> There are several ways to fix the core problem. One option is to replace >> the DWORD in that struct with DWORD_PTR or ULONG_PTR. >> Both types are identical, with DWORD_PTR being a typedef'd ULONG_PTR. >> >> Another option is to typedef a QWORD, and then use C preprocessing: >> #ifdef _WIN64 >> QWORD devId; >> #else >> DWORD devID; >> #endif >> >> Unfortunately, however we choose to fix this part, using (multiple) casts >> will still be necessary to prevent the compiler warning about >> mismatched size conversion between pointers and integers. >> >> For example, in line 471: >>> devInfo->devId = (DWORD)devInst; >> devInst is a HANDLE (i.e. void *). Quick correction here being a handle does not mean it is a HANDLE (i.e. void *). My work on windows seems to show that devnode handles tend to just be small incremental numbers (1, 2, 3, 4. etc) clearly they are references to some internal structure or such. >> >> Line 4027 in dlls/setupapi/devinst.c: >> struct DeviceInfo *ppdevInfo = GlobalLock((HANDLE)dnDevInst); >> dnDevInst is type DEVINST, which is a typedef'd DWORD. >> >> How do you want to proceed? > Your proposals will keep truncating a pointer to the lower 32 bits for > Win64. That's what Alexandre meant with just masking the error. > > As DevId is a DWORD (struct SP_DEVINFO_DATA from the public API) > wouldn't the correct fix be to move away from DevId being just a pointer? > https://msdn.microsoft.com/en-us/library/windows/hardware/ff552344(v=vs.85)… > It could be an index or a hash, something that fits into 32 bits. > > Aric might have some insight here as he looked at the Plug&Play manager > as well as at the Device Tree. > I do no have as much insight into the setupapi parts of this as I had just grazed the surface there with my HID work. However I do know that on windows devnodes are NOT pointers, they are handles. Using pointers instead of handles is a fast and easy thing done in many places in wine which bites us as we move to 64-bit. As I said I just scratched the surface of setupapi so I do not know the correct path forward here, but expanding the structure would not be, in my opinion. Likely we would need to build those handles, maybe based on user handles or something as they would need to be global. -aric

Aug. 9, 2017

Re: [PATCH v2 3/5] ieframe: Add stub implementation of IInternetExplorerManager.

by Jacek Caban

Hi Zebediah, On 08.08.2017 20:04, Zebediah Figura wrote: > HRESULT register_class_object(BOOL do_reg) > { > HRESULT hres; > > - static DWORD cookie; > + static DWORD ie_cookie, iem_cookie; > > if(do_reg) { > hres = CoRegisterClassObject(&CLSID_InternetExplorer, > (IUnknown*)&InternetExplorerFactory, CLSCTX_SERVER, > - REGCLS_MULTIPLEUSE|REGCLS_SUSPENDED, &cookie); > - if (FAILED(hres)) { > + REGCLS_MULTIPLEUSE, &ie_cookie); > + if (FAILED(hres)) > + ERR("failed to register object %08x\n", hres); > + hres = CoRegisterClassObject(&CLSID_InternetExplorerManager, > + (IUnknown*)&InternetExplorerManagerFactory, CLSCTX_SERVER, > + REGCLS_MULTIPLEUSE, &iem_cookie); > + if (FAILED(hres)) > ERR("failed to register object %08x\n", hres); > - return hres; > - } > - > - hres = CoResumeClassObjects(); > - if(SUCCEEDED(hres)) > - return hres; > - > - ERR("failed to resume object %08x\n", hres); > } > - > - return CoRevokeClassObject(cookie); > + else > + { > + hres = CoRevokeClassObject(ie_cookie); > + if (FAILED(hres)) > + ERR("failed to register object %08x\n", hres); > + hres = CoRevokeClassObject(iem_cookie); > + if (FAILED(hres)) > + ERR("failed to register object %08x\n", hres); > + } > + return hres; > } Are you sure that's how it's supposed to work? I didn't test it myself, but given how it's registered and documented, I'd expect that CLSID_InternetExplorerManager should live in a different process from CLSID_InternetExplorer. It should be easy to distinguish those processes with -startmanager command line argument. > +static HRESULT WINAPI InternetExplorerManager_CreateObject(IInternetExplorerManager *iface, DWORD config, LPCWSTR url, REFIID riid, void **ppv) > +{ > + FIXME("(%p)->(0x%x, %s, %s, %p) semi-stub\n", iface, config, debugstr_w(url), debugstr_guid(riid), ppv); > + > + return CoCreateInstance(&CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER, riid, ppv); > +} Using CoCreateInstance is very questionable here (eg. due to the comment above). Also, a patch adding a stub should just return E_NOTIMPL. Implementation deserves a separated patch. I'd expect that it should just use internal ieframe functions to create a new IE instance. Also, I'd suggest to reorder patches to something like: 2, 4, 5, 1 (likely replaced by support for -startmanager command line argument), 3 and then a new patch implementing CreateObject. Thanks, Jacek

Aug. 9, 2017

Re: [PATCH 3/5] setupapi: Fix compiler warnings when converting between pointers and integers on 64-bit systems

by Michael Stefaniuc

On 08/09/2017 04:26 AM, Hugh McMaster wrote: > On Tuesday, 8 August 2017 9:04 PM, Alexandre Julliard wrote: >> That's only hiding the bug. > > The basic problem is the use of DWORD in the following structure. On 64-bit > systems we then see warnings about the sizeof(DWORD) vs sizeof(void *). > > /* Pointed to by SP_DEVINFO_DATA's Reserved member */ > struct DeviceInfo > { > struct DeviceInfoSet *set; > HKEY key; > BOOL phantom; > DWORD devId; > LPWSTR instanceId; > struct list interfaces; > }; > > There are several ways to fix the core problem. One option is to replace > the DWORD in that struct with DWORD_PTR or ULONG_PTR. > Both types are identical, with DWORD_PTR being a typedef'd ULONG_PTR. > > Another option is to typedef a QWORD, and then use C preprocessing: > #ifdef _WIN64 > QWORD devId; > #else > DWORD devID; > #endif > > Unfortunately, however we choose to fix this part, using (multiple) casts > will still be necessary to prevent the compiler warning about > mismatched size conversion between pointers and integers. > > For example, in line 471: >> devInfo->devId = (DWORD)devInst; > devInst is a HANDLE (i.e. void *). > > Line 4027 in dlls/setupapi/devinst.c: > struct DeviceInfo *ppdevInfo = GlobalLock((HANDLE)dnDevInst); > dnDevInst is type DEVINST, which is a typedef'd DWORD. > > How do you want to proceed? Your proposals will keep truncating a pointer to the lower 32 bits for Win64. That's what Alexandre meant with just masking the error. As DevId is a DWORD (struct SP_DEVINFO_DATA from the public API) wouldn't the correct fix be to move away from DevId being just a pointer? https://msdn.microsoft.com/en-us/library/windows/hardware/ff552344(v=vs.85)… It could be an index or a hash, something that fits into 32 bits. Aric might have some insight here as he looked at the Plug&Play manager as well as at the Device Tree. bye michael

Aug. 9, 2017

Re: [PATCH v2 2/5] include: Add initial ieautomation.idl

by Nikolay Sivov

On 08.08.2017 21:04, Zebediah Figura wrote: > +[ > + object, > + uuid(acc84351-04ff-44f9-b23f-655ed168c6d5), > + oleautomation > +] > +interface IInternetExplorerManager : IUnknown > +{ > + HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > +} This is not how it's defined in SDK - oleautomation is not used there and "url" argument has different attributes.

Aug. 9, 2017

Re: [PATCH v2 5/5] ieproxy: Add proxy/stub for IInternetExplorerManager.

by Alistair Leslie-Hughes

Hi Zebediah, On 09/08/17 04:04, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > interface IInternetExplorerManager : IUnknown > { > - HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > + [local] HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > + [call_as(CreateObject)] HRESULT RemoteCreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); The public API doesn't have the RemoteCreateObject function. Best Regards Alistair.

Aug. 9, 2017

Re: [PATCH v2 5/5] ieproxy: Add proxy/stub for IInternetExplorerManager.

by Alistair Leslie-Hughes

Hi Zebediah, On 09/08/17 04:04, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > interface IInternetExplorerManager : IUnknown > { > - HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > + [local] HRESULT CreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); > + [call_as(CreateObject)] HRESULT RemoteCreateObject([in] DWORD config, [in, unique] LPCWSTR url, [in] REFIID riid, [out, iid_is(riid)] void **ppv); The public API doesn't have the RemoteCreateObject function. Best Regards Alistair.

Aug. 9, 2017

Re: [PATCH 3/5] setupapi: Fix compiler warnings when converting between pointers and integers on 64-bit systems

by Hugh McMaster

On Tuesday, 8 August 2017 9:04 PM, Alexandre Julliard wrote: > That's only hiding the bug. The basic problem is the use of DWORD in the following structure. On 64-bit systems we then see warnings about the sizeof(DWORD) vs sizeof(void *). /* Pointed to by SP_DEVINFO_DATA's Reserved member */ struct DeviceInfo { struct DeviceInfoSet *set; HKEY key; BOOL phantom; DWORD devId; LPWSTR instanceId; struct list interfaces; }; There are several ways to fix the core problem. One option is to replace the DWORD in that struct with DWORD_PTR or ULONG_PTR. Both types are identical, with DWORD_PTR being a typedef'd ULONG_PTR. Another option is to typedef a QWORD, and then use C preprocessing: #ifdef _WIN64 QWORD devId; #else DWORD devID; #endif Unfortunately, however we choose to fix this part, using (multiple) casts will still be necessary to prevent the compiler warning about mismatched size conversion between pointers and integers. For example, in line 471: > devInfo->devId = (DWORD)devInst; devInst is a HANDLE (i.e. void *). Line 4027 in dlls/setupapi/devinst.c: struct DeviceInfo *ppdevInfo = GlobalLock((HANDLE)dnDevInst); dnDevInst is type DEVINST, which is a typedef'd DWORD. How do you want to proceed? -- Hugh McMaster

Aug. 9, 2017

Re: [PATCH] kernel32: Uncomment Win7 stubs in specfile.

by Austin English

On Tue, Aug 8, 2017 at 2:42 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 08.08.2017 21:38, Zebediah Figura wrote: >> These were originally commented since the default Windows version >> was still XP. > > As I see you want to increase your regression count. ;) Whats the > point of advertising all those functions when Wine has no > implementation yet? Maybe you should throw it in staging and see what else we need to stub ;) -- -Austin GPG: 14FB D7EA A041 937B

Aug. 8, 2017

Re: [PATCH] kernel32: Uncomment Win7 stubs in specfile.

by Sebastian Lackner

On 08.08.2017 21:46, Zebediah Figura wrote: > On 08/08/2017 02:42 PM, Sebastian Lackner wrote: >> On 08.08.2017 21:38, Zebediah Figura wrote: >>> These were originally commented since the default Windows version >>> was still XP. >> >> As I see you want to increase your regression count. ;) Whats the >> point of advertising all those functions when Wine has no >> implementation yet? >> >> > > I was once told the stubs in specfiles were important, but now I don't know what to believe. (Certainly they've never seemed necessary...) > > I only submitted this patch because I tried to run a program and noticed warnings regarding unexported functions. > > A lot of applications work perfectly fine when Win7+ exports are missing, they will just assume that they are running on an old version of Windows and use a different code path. It is therefore better to wait until the functions are implemented before changing the spec file. For other dlls there might be different recommendations, but for kernel32 and ntdll there is really a very high risk of regressions when adding new stubs. Best regards, Sebastian

Aug. 8, 2017

Re: [PATCH] kernel32: Uncomment Win7 stubs in specfile.

by Zebediah Figura

On 08/08/2017 02:42 PM, Sebastian Lackner wrote: > On 08.08.2017 21:38, Zebediah Figura wrote: >> These were originally commented since the default Windows version >> was still XP. > > As I see you want to increase your regression count. ;) Whats the > point of advertising all those functions when Wine has no > implementation yet? > > I was once told the stubs in specfiles were important, but now I don't know what to believe. (Certainly they've never seemed necessary...) I only submitted this patch because I tried to run a program and noticed warnings regarding unexported functions.

Aug. 8, 2017

Re: [PATCH] kernel32: Uncomment Win7 stubs in specfile.

by Sebastian Lackner

On 08.08.2017 21:38, Zebediah Figura wrote: > These were originally commented since the default Windows version > was still XP. As I see you want to increase your regression count. ;) Whats the point of advertising all those functions when Wine has no implementation yet?

Aug. 8, 2017

Re: [PATCH 5/5] ieproxy: Add proxy/stub for IInternetExplorerManager.

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=32620 Your paranoid android. === build (build) === Make in include dir failed

Aug. 8, 2017

Re: shell32: Wait for process to finish when using flag SEE_MASK_NOASYNC

by Carlos Palminha

On 08-08-2017 17:33, Carlos Palminha wrote: > > > On 08-08-2017 17:17, Huw Davies wrote: >> On 8 Aug 2017, at 16:50, Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> wrote: >>> >>> Support for SEE_MASK_NOASYNC (same value as SEE_MASK_FLAG_DDEWAIT). >>> Waits for process execution to finish before returning. >>> >>> Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> >>> --- >>> dlls/shell32/shlexec.c | 17 ++++++++++++++++- >>> 1 file changed, 16 insertions(+), 1 deletion(-) >>> >>> diff --git a/dlls/shell32/shlexec.c b/dlls/shell32/shlexec.c >>> index c0ef53ab8e7..fe3eeeb5743 100644 >>> --- a/dlls/shell32/shlexec.c >>> +++ b/dlls/shell32/shlexec.c >>> @@ -344,6 +344,11 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, >>> dwCreationFlags = CREATE_UNICODE_ENVIRONMENT; >>> if (!(psei->fMask & SEE_MASK_NO_CONSOLE)) >>> dwCreationFlags |= CREATE_NEW_CONSOLE; >>> + >>> + if(psei->fMask & SEE_MASK_NOASYNC) { >>> + dwCreationFlags |= SEE_MASK_NOASYNC; >>> + } >>> + >>> if (CreateProcessW(NULL, (LPWSTR)lpCmd, NULL, NULL, FALSE, dwCreationFlags, env, >>> lpDirectory, &startup, &info)); >> >> Passing SEE_MASK_NOASYNC to CreateProcessW doesn’t look right… >> >> Huw. > > Yep... looking further into CreateProcessW it seems the flags are different from SHELL_Execute. > Waiting for the process to finish should open only at SHELL_Execute time. > > If the flag is not passed to CreateProcessW it seems ok, do you agree? > rerun the shlexec tests... seems ok now. v2 will follow.

Aug. 8, 2017

Re: Invitations to WineConf

by Michael Stefaniuc

On 08/07/2017 04:50 PM, Jeremy White wrote: > Hey folks, > > Last year we said that we were going to try to broaden our invitations > to the Wine conference to try to draw in more voices. This means > potentially asking users, and making personal appeals to people that we > would like to have at the conference. I have added the WineConf to the LWN events calendar: https://lwn.net/Calendar/Monthly/2017-10/ bye michael > > I plan to write a few personal notes extending invitations to folks that > I've thought of (or have had suggested to me). James in our office is > also going to reach out. > > But I'd like to ask everyone to help with that process. > > Roseanne, I'm particularly hoping you can reach out to the wine users in > some way. A post on the forums? Could we / should we do a big news item > so it's on the main page? > > I've asked PlayOnLinux folks as well as the Wineskin folks to come. > Anyone else? > > Cheers, > > Jeremy > > _______________________________________________ > wineconf mailing list > wineconf(a)winehq.org > https://www.winehq.org/mailman/listinfo/wineconf >

Aug. 8, 2017

Re: shell32: Wait for process to finish when using flag SEE_MASK_NOASYNC

by Carlos Palminha

On 08-08-2017 17:17, Huw Davies wrote: > On 8 Aug 2017, at 16:50, Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> wrote: >> >> Support for SEE_MASK_NOASYNC (same value as SEE_MASK_FLAG_DDEWAIT). >> Waits for process execution to finish before returning. >> >> Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> >> --- >> dlls/shell32/shlexec.c | 17 ++++++++++++++++- >> 1 file changed, 16 insertions(+), 1 deletion(-) >> >> diff --git a/dlls/shell32/shlexec.c b/dlls/shell32/shlexec.c >> index c0ef53ab8e7..fe3eeeb5743 100644 >> --- a/dlls/shell32/shlexec.c >> +++ b/dlls/shell32/shlexec.c >> @@ -344,6 +344,11 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, >> dwCreationFlags = CREATE_UNICODE_ENVIRONMENT; >> if (!(psei->fMask & SEE_MASK_NO_CONSOLE)) >> dwCreationFlags |= CREATE_NEW_CONSOLE; >> + >> + if(psei->fMask & SEE_MASK_NOASYNC) { >> + dwCreationFlags |= SEE_MASK_NOASYNC; >> + } >> + >> if (CreateProcessW(NULL, (LPWSTR)lpCmd, NULL, NULL, FALSE, dwCreationFlags, env, >> lpDirectory, &startup, &info)); > > Passing SEE_MASK_NOASYNC to CreateProcessW doesn’t look right… > > Huw. Yep... looking further into CreateProcessW it seems the flags are different from SHELL_Execute. Waiting for the process to finish should open only at SHELL_Execute time. If the flag is not passed to CreateProcessW it seems ok, do you agree?

Aug. 8, 2017

Re: shell32: Wait for process to finish when using flag SEE_MASK_NOASYNC

by Huw Davies

On 8 Aug 2017, at 16:50, Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> wrote: > > Support for SEE_MASK_NOASYNC (same value as SEE_MASK_FLAG_DDEWAIT). > Waits for process execution to finish before returning. > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > dlls/shell32/shlexec.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/shell32/shlexec.c b/dlls/shell32/shlexec.c > index c0ef53ab8e7..fe3eeeb5743 100644 > --- a/dlls/shell32/shlexec.c > +++ b/dlls/shell32/shlexec.c > @@ -344,6 +344,11 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, > dwCreationFlags = CREATE_UNICODE_ENVIRONMENT; > if (!(psei->fMask & SEE_MASK_NO_CONSOLE)) > dwCreationFlags |= CREATE_NEW_CONSOLE; > + > + if(psei->fMask & SEE_MASK_NOASYNC) { > + dwCreationFlags |= SEE_MASK_NOASYNC; > + } > + > if (CreateProcessW(NULL, (LPWSTR)lpCmd, NULL, NULL, FALSE, dwCreationFlags, env, > lpDirectory, &startup, &info)); Passing SEE_MASK_NOASYNC to CreateProcessW doesn’t look right… Huw.

Aug. 8, 2017

Re: Invitations to WineConf

by Alex Henrie

2017-08-07 8:50 GMT-06:00 Jeremy White <jwhite(a)codeweavers.com>: > Hey folks, > > Last year we said that we were going to try to broaden our invitations > to the Wine conference to try to draw in more voices. This means > potentially asking users, and making personal appeals to people that we > would like to have at the conference. > > I plan to write a few personal notes extending invitations to folks that > I've thought of (or have had suggested to me). James in our office is > also going to reach out. > > But I'd like to ask everyone to help with that process. > > Roseanne, I'm particularly hoping you can reach out to the wine users in > some way. A post on the forums? Could we / should we do a big news item > so it's on the main page? > > I've asked PlayOnLinux folks as well as the Wineskin folks to come. > Anyone else? I can forward your email to the ReactOS mailing lists if you'd like. -Alex

Aug. 8, 2017

Re: [v2 5/5] kernel32/tests: Add tests for LoadLibrary with LIBRARY_SEARCH_* flags

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=32619 Your paranoid android. === w2003std (32 bit module) === module.c:471: Test failed: Could not load test library testFlags.dll from C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ module.c:496: Test failed: Library testFlags.dll was expected to be loaded from 'system32' module.c:505: Test failed: Library testFlags.dll was expected to be loaded from 'system32'

Aug. 8, 2017

Re: [PATCH] netapi32: Return ERROR_SUCCESS in DsGetDcNameA/W.

by Huw Davies

On Fri, Aug 04, 2017 at 04:17:14PM +0300, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/netapi32/netapi32.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/netapi32/netapi32.c b/dlls/netapi32/netapi32.c > index 278d4528b0..0236a2ad53 100644 > --- a/dlls/netapi32/netapi32.c > +++ b/dlls/netapi32/netapi32.c > @@ -3024,7 +3024,7 @@ DWORD WINAPI DsGetDcNameW(LPCWSTR ComputerName, LPCWSTR AvoidDCName, > FIXME("(%s, %s, %s, %s, %08x, %p): stub\n", debugstr_w(ComputerName), > debugstr_w(AvoidDCName), debugstr_guid(DomainGuid), > debugstr_w(SiteName), Flags, DomainControllerInfo); > - return ERROR_CALL_NOT_IMPLEMENTED; > + return ERROR_SUCCESS; > } > > DWORD WINAPI DsGetDcNameA(LPCSTR ComputerName, LPCSTR AvoidDCName, > @@ -3034,7 +3034,7 @@ DWORD WINAPI DsGetDcNameA(LPCSTR ComputerName, LPCSTR AvoidDCName, > FIXME("(%s, %s, %s, %s, %08x, %p): stub\n", debugstr_a(ComputerName), > debugstr_a(AvoidDCName), debugstr_guid(DomainGuid), > debugstr_a(SiteName), Flags, DomainControllerInfo); > - return ERROR_CALL_NOT_IMPLEMENTED; > + return ERROR_SUCCESS; > } This can't be right. These functions are supposed to return a ptr to an allocated DOMAIN_CONTROLLER_INFO in the final parameter. If you return ERROR_SUCCESS, the app will likely dereference that uninitialized pointer. Huw.

Aug. 8, 2017

Re: [PATCH v3] shell32: Implement SHCreateItemInKnownFolder.

by Jactry Zeng

Hi Alistair, 2017-08-08 17:18 GMT+08:00 Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com>: > On 08/08/17 17:04, Jactry Zeng wrote: > > + /* SHCreateItemInKnownFolder */ > > + if(pSHCreateItemInKnownFolder || pSHGetKnownFolderPath) > > If one of these is NULL then the test will crash. > Yes, this is my fault. I will fix it in next try. Thanks for review! -- Regards, Jactry Zeng

Aug. 8, 2017

Re: wineandroid: Add suffix to lib directory and wine binary on 64-bit

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > This fixes at least arm64-v8a builds, where you have lib64/libwine.so and bin/wine64 > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > This and "winebuild: Improved position independent code generation" enable Wine on ARM64 Android phones (e.g. most Android devices). > The check for 64 in the CPU_ABI can be discussed, but I think it's reliable and fast. > > dlls/wineandroid.drv/WineActivity.java | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) We already prefix with the ABI, so I think plain "lib" is better. -- Alexandre Julliard julliard(a)winehq.org

Aug. 8, 2017

Re: [PATCH 3/5] setupapi: Fix compiler warnings when converting between pointers and integers on 64-bit systems

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/setupapi/devinst.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) That's only hiding the bug. -- Alexandre Julliard julliard(a)winehq.org

Aug. 8, 2017

Re: [PATCH v3] shell32: Implement SHCreateItemInKnownFolder.

by Alistair Leslie-Hughes

Hi Jactry, On 08/08/17 17:04, Jactry Zeng wrote: > + /* SHCreateItemInKnownFolder */ > + if(pSHCreateItemInKnownFolder || pSHGetKnownFolderPath) If one of these is NULL then the test will crash. Best Regards Alistair

Aug. 8, 2017

Re: [PATCH v3] shell32: Implement SHCreateItemInKnownFolder.

by Huw Davies

On Tue, Aug 08, 2017 at 03:04:21PM +0800, Jactry Zeng wrote: > diff --git a/dlls/shell32/shellitem.c b/dlls/shell32/shellitem.c > index 1e19f7c72e..0bfb4a7f6f 100644 > --- a/dlls/shell32/shellitem.c > +++ b/dlls/shell32/shellitem.c > @@ -662,6 +662,67 @@ HRESULT WINAPI SHCreateItemFromIDList(PCIDLIST_ABSOLUTE pidl, REFIID riid, void > return ret; > } > > +HRESULT WINAPI SHCreateItemInKnownFolder(REFKNOWNFOLDERID rfid, DWORD flags, > + LPWSTR filename, REFIID riid, void **ppv) > +{ > + HRESULT hr; > + WCHAR *pathW = NULL; > + IShellFolder *desktop = NULL, *folder = NULL; > + LPITEMIDLIST pidl_folder = NULL, pidl = NULL; > + > + TRACE("%p, %x, %s, %s, %p\n", rfid, flags, wine_dbgstr_w(filename), > + debugstr_guid(riid), ppv); > + > + if(!rfid || !ppv) > + return E_INVALIDARG; > + > + if(flags) > + FIXME("flags 0x%08x not supported\n", flags); > + > + *ppv = NULL; > + hr = SHGetKnownFolderIDList(rfid, 0, NULL, &pidl_folder); flags should just be passed as the second parameter here and then you can ditch the FIXME(). > + if(hr != S_OK) > + goto cleanup; > + > + hr = SHGetDesktopFolder(&desktop); > + if(hr != S_OK) > + goto cleanup; > + > + if(!IsEqualIID(rfid, &FOLDERID_Desktop)) > + { > + hr = IShellFolder_BindToObject(desktop, pidl_folder, NULL, &IID_IShellFolder, > + (void**)&folder); > + if(hr != S_OK) > + goto cleanup; > + } > + > + if(filename) > + { > + hr = IShellFolder_ParseDisplayName(folder ? folder : desktop, NULL, NULL, > + filename, NULL, &pidl, NULL); > + if(hr != S_OK) > + goto cleanup; > + hr = SHCreateItemFromIDList(pidl, riid, ppv); > + if(hr != S_OK) > + goto cleanup; > + } > + else > + hr = SHCreateItemFromIDList(pidl_folder, riid, ppv); Thinking about this some more, how about implementing SHCreateItemFromRelativeName() first? Then this function becomes something like: SHGetKnownFolderIDList( rfid, flags, NULL, &pidl ); SHCreateItemFromIDList( pidl, &IID_IShellItem, &parent ); if (name) SHCreateItemFromRelativeName( parent, name, NULL, iid, ppv ); else IShellItem_QueryInterface( parent, iid, ppv ); IShellItem_Release( parent ); ILFree( pidl ); > diff --git a/dlls/shell32/tests/shlfolder.c b/dlls/shell32/tests/shlfolder.c > index 9e7127dfea..461f8cea95 100644 > --- a/dlls/shell32/tests/shlfolder.c > +++ b/dlls/shell32/tests/shlfolder.c > > + /* SHCreateItemInKnownFolder */ > + if(pSHCreateItemInKnownFolder || pSHGetKnownFolderPath) I think you mean && here (although in practice it doesn't matter). > + if(0) > + { > + /* crashes on Windows */ > + pSHCreateItemInKnownFolder(NULL, 0, NULL, NULL, NULL); > + pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, NULL, NULL, NULL); > + pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, testfileW, &IID_IShellItem, NULL); > + } I'm not a big fan of this sort of thing, just leave it out. Huw.

Aug. 8, 2017

Re: [PATCH v2] shell32: Implement SHCreateItemInKnownFolder.

by Jactry Zeng

Hi Huw, SHCreateItemInKnownFolder() isn't available on WinXP and 2003 too. I sent another try which loading SHGetKnownFolderPath() dynamically. Thanks for review! 2017-08-07 18:33 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > On Fri, Aug 04, 2017 at 02:54:15PM +0800, Jactry Zeng wrote: > > diff --git a/dlls/shell32/tests/shlfolder.c b/dlls/shell32/tests/ > shlfolder.c > > index 9e7127dfea..b77619d428 100644 > > --- a/dlls/shell32/tests/shlfolder.c > > +++ b/dlls/shell32/tests/shlfolder.c > > @@ -2519,6 +2521,120 @@ static void test_SHCreateShellItem(void) > > else > > win_skip("No SHCreateItemFromIDList\n"); > > > > + /* SHCreateItemInKnownFolder */ > > + if(pSHCreateItemInKnownFolder) > > + { > > + WCHAR *desktop_path; > > + WCHAR testfile_path[MAX_PATH] = {0}; > > + HANDLE file; > > + WCHAR *displayname = NULL; > > + int order; > > + LPITEMIDLIST pidl_desktop_testfile = NULL; > > + > > + if(0) > > + { > > + /* crashes on Windows */ > > + pSHCreateItemInKnownFolder(NULL, 0, NULL, NULL, NULL); > > + pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, NULL, > NULL, NULL); > > + pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, > testfileW, &IID_IShellItem, NULL); > > + } > > + > > + shellitem = (void*)0xdeadbeef; > > + ret = pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, NULL, > &IID_IShellItem, > > + (void**)&shellitem); > > + ok(ret == S_OK, "SHCreateItemInKnownFolder failed: 0x%08x.\n", > ret); > > + ok(shellitem != NULL, "shellitem was %p.\n", shellitem); > > + if(SUCCEEDED(ret)) > > + { > > + shellitem2 = (void*)0xdeadbeef; > > + ret = pSHCreateShellItem(NULL, NULL, pidl_desktop, > &shellitem2); > > + ok(SUCCEEDED(ret), "SHCreateShellItem returned %x\n", ret); > > + if(SUCCEEDED(ret)) > > + { > > + ret = IShellItem_Compare(shellitem, shellitem2, 0, > &order); > > + ok(ret == S_OK, "IShellItem_Compare failed: 0x%08x\n", > ret); > > + ok(!order, "order got wrong value: %d\n", order); > > + IShellItem_Release(shellitem2); > > + } > > + IShellItem_Release(shellitem); > > + } > > + > > + /* Test with a non-existent file */ > > + shellitem = (void*)0xdeadbeef; > > + ret = pSHCreateItemInKnownFolder(&FOLDERID_Desktop, 0, > testfileW, &IID_IShellItem, > > + (void**)&shellitem); > > + ok(ret == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), "Expected > 0x%08x but SHCreateItemInKnownFolder return: 0x%08x.\n", > > + HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), ret); > > + ok(shellitem == NULL, "shellitem was %p.\n", shellitem); > > + > > + SHGetKnownFolderPath(&FOLDERID_Desktop, 0, NULL, > &desktop_path); > > It looks like SHGetKnownFolderPath is not available on WinXP, so > you'll have to load it dynamically. OTOH I think > SHCreateItemInKnownFolder() > is available on all the platforms that we care about, so you can static > link > to that one. > > Huw. > > > -- Regards, Jactry Zeng

Aug. 8, 2017

Re: [PATCH v2] ntdll: Fix wrong string size alloc when loading libraries

by Carlos Palminha

On 07-08-2017 19:55, Nikolay Sivov wrote: > On 07.08.2017 20:41, Carlos Palminha wrote: >> Fixed some nasty unhandled exceptions when loading libraries >> that don't have .dll extension. >> >> Problem was caused by wrong string size calculation. >> >> v2: Now properly takes into account strlen * sizeof WCHAR >> >> Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> >> --- >> dlls/ntdll/loader.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c >> index dd1f74c0fc..83dd6d378e 100644 >> --- a/dlls/ntdll/loader.c >> +++ b/dlls/ntdll/loader.c >> @@ -2141,7 +2141,7 @@ static NTSTATUS find_dll_file( const WCHAR *load_path, const WCHAR *libname, >> if (!(ext = strrchrW( libname, '.')) || strchrW( ext, '/' ) || strchrW( ext, '\\')) >> { >> if (!(dllname = RtlAllocateHeap( GetProcessHeap(), 0, >> - (strlenW(libname) * sizeof(WCHAR)) + sizeof(dllW) ))) >> + (strlenW(libname) * sizeof(WCHAR)) + (strlenW(dllW) * sizeof(WCHAR)) ))) >> return STATUS_NO_MEMORY; >> strcpyW( dllname, libname ); >> strcatW( dllname, dllW ); >> > > This is still shorter than it is now: > > sizeof(dllW) is 5 * sizeof(WCHAR) vs strlenW(dllW) * sizeof(WCHAR) == 4 > * sizeof(WCHAR). > yep, you are right! Somehow with my "patch" i stop getting the "Program Error" window with the exception. But after i realized i still got the exception "silently" in the logs. Need to better understand why its crashing around that Alloc. Regards, C.Palminha

Aug. 7, 2017

Re: Invitations to WineConf

by Jens Reyer

On 08/07/2017 10:50 AM, Jeremy White wrote: > Hey folks, > > Last year we said that we were going to try to broaden our invitations > to the Wine conference to try to draw in more voices. This means > potentially asking users, and making personal appeals to people that we > would like to have at the conference. > > I plan to write a few personal notes extending invitations to folks that > I've thought of (or have had suggested to me). James in our office is > also going to reach out. > > But I'd like to ask everyone to help with that process. > > Roseanne, I'm particularly hoping you can reach out to the wine users in > some way. A post on the forums? Could we / should we do a big news item > so it's on the main page? > > I've asked PlayOnLinux folks as well as the Wineskin folks to come. > Anyone else? I hope to come this year (too early to say for sure). You might reach out to other packagers, iirc you planned that last year. q4wine guy(s?) might also be interested (but I don't know much about that). Greets jre

Aug. 7, 2017

Re: [PATCH v2] ntdll: Fix wrong string size alloc when loading libraries

by Nikolay Sivov

On 07.08.2017 20:41, Carlos Palminha wrote: > Fixed some nasty unhandled exceptions when loading libraries > that don't have .dll extension. > > Problem was caused by wrong string size calculation. > > v2: Now properly takes into account strlen * sizeof WCHAR > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > dlls/ntdll/loader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index dd1f74c0fc..83dd6d378e 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2141,7 +2141,7 @@ static NTSTATUS find_dll_file( const WCHAR *load_path, const WCHAR *libname, > if (!(ext = strrchrW( libname, '.')) || strchrW( ext, '/' ) || strchrW( ext, '\\')) > { > if (!(dllname = RtlAllocateHeap( GetProcessHeap(), 0, > - (strlenW(libname) * sizeof(WCHAR)) + sizeof(dllW) ))) > + (strlenW(libname) * sizeof(WCHAR)) + (strlenW(dllW) * sizeof(WCHAR)) ))) > return STATUS_NO_MEMORY; > strcpyW( dllname, libname ); > strcatW( dllname, dllW ); > This is still shorter than it is now: sizeof(dllW) is 5 * sizeof(WCHAR) vs strlenW(dllW) * sizeof(WCHAR) == 4 * sizeof(WCHAR).

Aug. 7, 2017

Re: Invitations to WineConf

by Jeremy White

On 08/07/2017 11:48 AM, Rosanne DiMesio wrote: > On Mon, 7 Aug 2017 09:50:45 -0500 > Jeremy White <jwhite(a)codeweavers.com> wrote: >> >> Roseanne, I'm particularly hoping you can reach out to the wine users in >> some way. A post on the forums? Could we / should we do a big news item >> so it's on the main page? >> > I'd do both. The forum announcement should come from you rather than me. Maybe make the main page announcement a WWN article? Really? I would bet that on the Wine forums your name is better known and better loved than mine. > > My big question is: what are you planning for users? Users who don't live near enough to just drop in will want to know what's on the agenda before deciding. That's a good question. I think the key note and the socializing tend to work for users as well as they do for developers. The only concrete idea I have is to have a session titled something like: "What do users need?" We often say it would be nice to have the Agenda ahead of time, but efforts on that front often fall short. Arguably, we should have a visible schedule and at least a suggestion of an Agenda (and perhaps a link to last years Agenda would help people have a sense of the topics). I'll work with Jacek on getting a framework up. If others have suggestions, they can add them there. > >> I've asked PlayOnLinux folks as well as the Wineskin folks to come. >> Anyone else? >> > AppDB admins and maintainers? Most won't be interested, but some long-time, very active ones might. It's very easy to send an email to all of them through the AppDB. I think that would be a great idea. Cheers, Jeremy

Aug. 7, 2017

Re: [PATCH] ws2_32: Don't return synchronously if the connection is refused.

by Huw Davies

On Mon, Aug 07, 2017 at 03:39:14PM +0100, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/ws2_32/socket.c | 5 +++++ > dlls/ws2_32/tests/sock.c | 20 ++++++-------------- > 2 files changed, 11 insertions(+), 14 deletions(-) Please ignore this for now, it needs more work. Huw.

Aug. 7, 2017

Re: [PATCH] ntdll: Fix wrong string size alloc when loading libraries

by Carlos Palminha

On 07-08-2017 18:14, Józef Kucia wrote: > On Mon, Aug 7, 2017 at 6:48 PM, Carlos Palminha > <CARLOS.PALMINHA(a)synopsys.com> wrote: >> Fixed some nasty unhandled exceptions when loading libraries >> that don't have .dll extension. >> >> Problem was caused by wrong string size calculation. >> >> Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> >> --- >> dlls/ntdll/loader.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c >> index dd1f74c0fc..8fc464bcd7 100644 >> --- a/dlls/ntdll/loader.c >> +++ b/dlls/ntdll/loader.c >> @@ -2141,7 +2141,7 @@ static NTSTATUS find_dll_file( const WCHAR *load_path, const WCHAR *libname, >> if (!(ext = strrchrW( libname, '.')) || strchrW( ext, '/' ) || strchrW( ext, '\\')) >> { >> if (!(dllname = RtlAllocateHeap( GetProcessHeap(), 0, >> - (strlenW(libname) * sizeof(WCHAR)) + sizeof(dllW) ))) >> + (strlenW(libname) * sizeof(WCHAR)) + strlenW(dllW) ))) > > This doesn't look right. After the change it allocates less memory > than before. Notice that strlenW(dllW) == 4 and sizeof(dllW) == 10. yep... just spot it. somehow like already fixes my issues. will send a v2. > >> return STATUS_NO_MEMORY; >> strcpyW( dllname, libname ); >> strcatW( dllname, dllW ); >> -- >> 2.11.0 >> >> >> > >

Aug. 7, 2017

Re: Invitations to WineConf

by André Hentschel

Am 07.08.2017 um 18:48 schrieb Rosanne DiMesio: > On Mon, 7 Aug 2017 09:50:45 -0500 > Jeremy White <jwhite(a)codeweavers.com> wrote: >> >> Roseanne, I'm particularly hoping you can reach out to the wine users in >> some way. A post on the forums? Could we / should we do a big news item >> so it's on the main page? >> > I'd do both. The forum announcement should come from you rather than me. Maybe make the main page announcement a WWN article? > > My big question is: what are you planning for users? Users who don't live near enough to just drop in will want to know what's on the agenda before deciding. > >> I've asked PlayOnLinux folks as well as the Wineskin folks to come. >> Anyone else? >> > AppDB admins and maintainers? Most won't be interested, but some long-time, very active ones might. It's very easy to send an email to all of them through the AppDB. > > > > > > > > > If someone supplies the text, i can make a WWN out of it

Aug. 7, 2017

Re: [PATCH] ntdll: Fix wrong string size alloc when loading libraries

by Józef Kucia

On Mon, Aug 7, 2017 at 6:48 PM, Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> wrote: > Fixed some nasty unhandled exceptions when loading libraries > that don't have .dll extension. > > Problem was caused by wrong string size calculation. > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > dlls/ntdll/loader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index dd1f74c0fc..8fc464bcd7 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2141,7 +2141,7 @@ static NTSTATUS find_dll_file( const WCHAR *load_path, const WCHAR *libname, > if (!(ext = strrchrW( libname, '.')) || strchrW( ext, '/' ) || strchrW( ext, '\\')) > { > if (!(dllname = RtlAllocateHeap( GetProcessHeap(), 0, > - (strlenW(libname) * sizeof(WCHAR)) + sizeof(dllW) ))) > + (strlenW(libname) * sizeof(WCHAR)) + strlenW(dllW) ))) This doesn't look right. After the change it allocates less memory than before. Notice that strlenW(dllW) == 4 and sizeof(dllW) == 10. > return STATUS_NO_MEMORY; > strcpyW( dllname, libname ); > strcatW( dllname, dllW ); > -- > 2.11.0 > > >

Aug. 7, 2017