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

Re: comctl32: treeview: Fix crash when deleting the first visible item while bRedraw == false

by Nikolay Sivov

On 01/30/2016 12:11 AM, Joachim Priesner wrote: > When bRedraw == false, TREEVIEW_DeleteItem returned early, leaving > firstVisible == NULL. This led to a crash when bRedraw was set to true > again. > > Signed-off-by: Joachim Priesner <joachim.priesner(a)web.de> > --- > dlls/comctl32/tests/treeview.c | 38 ++++++++++++++++++++++++++++++++++++++ > dlls/comctl32/treeview.c | 4 +++- > 2 files changed, 41 insertions(+), 1 deletion(-) > > diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c > index 92504c1..34d0674 100644 > --- a/dlls/comctl32/tests/treeview.c > +++ b/dlls/comctl32/tests/treeview.c > @@ -1903,6 +1903,43 @@ static void test_delete_items(void) > DestroyWindow(hTree); > } > > +static void test_delete_first_visible_setredraw_false(void) Please append new tests to test_delete_items(), after a comment line describing what's being tested. > +{ > + HWND hTree; > + INT ret; > + TVINSERTSTRUCTA ins; > + HTREEITEM hItem1; > + > + static CHAR item1[] = "Item 1"; > + static CHAR item2[] = "Item 2"; > + > + hTree = create_treeview_control(0); > + > + ins.hParent = TVI_ROOT; > + ins.hInsertAfter = TVI_ROOT; > + U(ins).item.mask = TVIF_TEXT; > + U(ins).item.pszText = item1; > + hItem1 = TreeView_InsertItemA(hTree, &ins); Just to make sure add a test for hItem != NULL. > + > + ins.hParent = TVI_ROOT; > + ins.hInsertAfter = hItem1; > + U(ins).item.mask = TVIF_TEXT; > + U(ins).item.pszText = item2; > + (void*) TreeView_InsertItemA(hTree, &ins); /* return value unused */ > + Same here, it'll also make a value used. > + ret = SendMessageA(hTree, WM_SETREDRAW, 0, 0); > + ok(ret == 0, "got %d\n", ret); > + > + ret = SendMessageA(hTree, TVM_DELETEITEM, 0, (LPARAM)hItem1); > + ok(ret == TRUE, "got %d\n", ret); > + > + /* this used to crash, test that it does not any more */ > + ret = SendMessageA(hTree, WM_SETREDRAW, 1, 0); > + ok(ret == 0, "got %d\n", ret); > + For WM_SETREDRAW wParam please use TRUE/FALSE instead. Otherwise looks good, thanks for fixing this.

Jan. 31, 2016

Re: [v2 PATCH 1/3] gdiplus: Implement GdipGetPenTransform

by Nikolay Sivov

On Sunday, 31 January 2016, Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com > <javascript:;>> > --- > dlls/gdiplus/gdiplus_private.h | 1 + > dlls/gdiplus/pen.c | 9 ++++----- > dlls/gdiplus/tests/pen.c | 6 +++--- > 3 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/dlls/gdiplus/gdiplus_private.h > b/dlls/gdiplus/gdiplus_private.h > index 1af0bd0..fd45a49 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -197,6 +197,7 @@ struct GpPen{ > REAL offset; /* dash offset */ > GpBrush *brush; > GpPenAlignment align; > + GpMatrix *transform; > }; Why does it have to be a separate allocation? It looks like GpMatrix field will work fine.

Jan. 31, 2016

Re: [PATCH 2/2] mscoree: call native DllEntryPoint when it is defined in COR header.

by Vincent Povirk

You seem to have some weird indentation? We should probably still call DisableThreadLibraryCalls on process attach if there's no native entry point.

Jan. 29, 2016

Re: jscript: Fixed tests on some old jscript versions.

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=20096 Your paranoid android. === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

Jan. 29, 2016

Re: [PATCH 3/6] d3d11/tests: Add a test for CheckMultisampleQualityLevels.

by Henri Verbeet

On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void test_checkmultisamplequalitylevels(void) The naming here is a bit different from the other tests. :) I guess it was inspired by the equivalent d3d9 test?

Jan. 29, 2016

Re: [PATCH 6/6] d3d10core/tests: Test the creation of textures with invalid multisample settings.

by Henri Verbeet

On 29 January 2016 at 11:15, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > This is fine by me but it could be considered to be merged into > test_create_texture2d(). > I do think that would be a good fit for this, although I don't feel particularly strongly about it either.

Jan. 29, 2016

Re: [PATCH 3/5] wined3d: Recognize SM4 dcl_immediateConstantBuffer.

by Henri Verbeet

On 29 January 2016 at 09:44, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + else if (ins.handler_idx == WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER) > + { > + struct wined3d_shader_immediate_constant_buffer *icb = ins.declaration.icb; > + if (reg_maps->icb) > + { > + ERR("Multiple immediate constant buffers.\n"); This would need to be a WARN or a FIXME, unless you ensure that it can never happen in the front-end. > + HeapFree(GetProcessHeap(), 0, reg_maps->icb); > + } > + if (!(reg_maps->icb = HeapAlloc(GetProcessHeap(), 0, icb->element_count * sizeof(*icb->data)))) > + { > + ERR("Failed to allocate immediate constant buffer.\n"); > + return E_OUTOFMEMORY; > + } > + memcpy(reg_maps->icb, icb->data, icb->element_count * sizeof(*icb->data)); > + reg_maps->icb_size = icb->element_count / 4; I think it shouldn't be necessary to copy the data, shader->frontend_data should stay alive until the shader is destroyed. > + FIXME("Unexpected size of immediate constant buffer %u.\n", len); "Unexpected immediate constant buffer size %u.\n" sounds more natural to me, but it's not a big deal.

Jan. 29, 2016

Re: [PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().

by Henri Verbeet

On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (sample_count > 32) > + return E_FAIL; I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT. > + if (sample_count > 16) > + { > + FIXME("sample_count %u not handled yet.\n", sample_count); > + return S_OK; > + } I think that belongs in wined3d_check_device_multisample_type(). > + hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device, > + wined3dformat_from_dxgi_format(format), sample_count, quality_level_count); > + if (hr == WINED3DERR_INVALIDCALL) > + return E_INVALIDARG; > + if (hr == WINED3DERR_NOTAVAILABLE) > + return S_OK; This is fine, but the d3d10+ API probably makes more sense in the long run. I.e., eventually we'd want to handle the difference in d3d8/9 instead. > +HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device, > + enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, > + DWORD *quality_level_count) I don't think we really want to introduce a new entry point for this. I guess the issue is that we can't get at the wined3d object that created the device from inside d3d11, but I think it would be preferable to do something about that instead. It seems likely that CheckFeatureSupport() and CheckFormatSupport() would run into this as well.

Jan. 29, 2016

Re: [PATCH v3] ntoskrnl.exe: Implement IoGetDeviceProperty for DevicePropertyPhysicalDeviceObjectName

by Aric Stewart

On 1/29/16 8:29 AM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> + case DevicePropertyPhysicalDeviceObjectName: >> + { >> + ULONG used_len; >> + OBJECT_NAME_INFORMATION *name = HeapAlloc(GetProcessHeap(), 0, buffer_length + (sizeof(OBJECT_NAME_INFORMATION))); >> + >> + status = NtQueryObject(device->Reserved, ObjectNameInformation, name, buffer_length + sizeof(OBJECT_NAME_INFORMATION), &used_len); >> + if (status == STATUS_SUCCESS) >> + { >> + memcpy(property_buffer, name->Name.Buffer, name->Name.Length); >> + *result_length = name->Name.Length; >> + } >> + else >> + *result_length = 0; > > Length is still not correct if the buffer is too small, and the string > needs to be null-terminated. > Sorry you are correct I am trying to focus on too many divergent things at once and my brain has stated to turn to mush. -aric

Jan. 29, 2016

Re: [PATCH v3] ntoskrnl.exe: Implement IoGetDeviceProperty for DevicePropertyPhysicalDeviceObjectName

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + case DevicePropertyPhysicalDeviceObjectName: > + { > + ULONG used_len; > + OBJECT_NAME_INFORMATION *name = HeapAlloc(GetProcessHeap(), 0, buffer_length + (sizeof(OBJECT_NAME_INFORMATION))); > + > + status = NtQueryObject(device->Reserved, ObjectNameInformation, name, buffer_length + sizeof(OBJECT_NAME_INFORMATION), &used_len); > + if (status == STATUS_SUCCESS) > + { > + memcpy(property_buffer, name->Name.Buffer, name->Name.Length); > + *result_length = name->Name.Length; > + } > + else > + *result_length = 0; Length is still not correct if the buffer is too small, and the string needs to be null-terminated. -- Alexandre Julliard julliard(a)winehq.org

Jan. 29, 2016

Re: shell32/tests: Add traces to the WaitForInputIdle() hooking process.

by Francois Gouget

On Fri, 29 Jan 2016, Henri Verbeet wrote: > On 29 January 2016 at 00:54, Francois Gouget <fgouget(a)codeweavers.com> wrote: > > * There is a set of traces showing WaitForInputIdle() being > > replaced with our own implementation: > > shlexec.c:2318: Hooked USER32.dll.WaitForInputIdle > > > > * And then traces showing our implementation being called: > > shlexec.c:2258: WaitForInputIdle() waiting for dde event > > > > Except that on Windows 10 we never get the second set of traces which > > means we failed to override WaitForInputIdle(). > > > I'm hardly an expert on shell32, but any chance the hooking worked > fine and WaitForInputIdle() is just not getting called? Would > explicitly specifying SEE_MASK_WAITFORINPUTIDLE make it any better? Thanks! I had not seen this option. Also it should really not be needed but it does solve the problem on Windows 10... and kinda breaks the tests on Vista to Windows 8. https://testbot.winehq.org/JobDetails.pl?Key=20082 To wit: * DDE implies doing a WaitForInputIdle(). So Windows 10 should really be doing it without being told, just like all the previous Windows versions before it. * But we also know that WaitForInputIdle() does not work on console applications like our confomance tests. So maybe Windows 10 detects the target executable is a console application and skips this call. It's either that or assuming DDE is totally broken on Windows 10 which seems unlikely (maybe I'll test it at some point). * On all versions from Vista to Windows 8.1, adding SEE_MASK_WAITFORINPUTIDLE causes WaitForInputIdle() to be called twice when DDE is involved. This further 'proves' that this flag should not be needed. * This is why the flag breaks our tests: unlike the real implementation our WaitForInputIdle() replacement blocks every time it is called. Fortunately that's a simple fix. * On Windows XP and 2003, even with the extra flag, WaitForInputIdle() is called only once. * It would really be better to do our DDE tests with a GUI target application. I have no idea how to do that though. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 29, 2016

Re: [PATCH 1/3] gdiplus: Implement GdipGetPenTransform

by Nikolay Sivov

On Friday, 29 January 2016, Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com > <javascript:;>> > --- > dlls/gdiplus/gdiplus_private.h | 6 ++++++ > dlls/gdiplus/pen.c | 9 ++++----- > dlls/gdiplus/tests/pen.c | 6 +++--- > 3 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/dlls/gdiplus/gdiplus_private.h > b/dlls/gdiplus/gdiplus_private.h > index 1af0bd0..1ed1e5e 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -71,6 +71,11 @@ static inline BOOL heap_free(void *mem) > return HeapFree(GetProcessHeap(), 0, mem); > } > > +static inline void copy_matrix(GpMatrix *in, GpMatrix *out) > +{ > + memcpy(out, in, 6 * sizeof(REAL)); > +} > + Simple assignment could be used instead of this helper.

Jan. 29, 2016

Re: [PATCH 6/6] d3d10core/tests: Test the creation of textures with invalid multisample settings.

by Józef Kucia

On Fri, Jan 29, 2016 at 12:51 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > dlls/d3d10core/tests/device.c | 48 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > diff --git a/dlls/d3d10core/tests/device.c b/dlls/d3d10core/tests/device.c > index ae755d3..de3b551 100644 > --- a/dlls/d3d10core/tests/device.c > +++ b/dlls/d3d10core/tests/device.c > @@ -5138,6 +5138,53 @@ done: > ok(!refcount, "Device has %u references left.\n", refcount); > } > > +static void test_invalid_multisample(void) > +{ > + D3D10_TEXTURE2D_DESC desc; > + ID3D10Texture2D *texture; > + UINT quality_level_count; > + ID3D10Device *device; > + ULONG refcount; > + HRESULT hr; > + > + if (!(device = create_device())) > + { > + skip("Failed to create device.\n"); > + return; > + } > + > + ID3D10Device_CheckMultisampleQualityLevels(device, DXGI_FORMAT_R8G8B8A8_UNORM, 2, &quality_level_count); > + desc.Width = 128; > + desc.Height = 128; > + desc.MipLevels = 1; > + desc.ArraySize = 1; > + desc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; > + desc.SampleDesc.Count = 2; > + desc.SampleDesc.Quality = 0; > + desc.Usage = D3D10_USAGE_DEFAULT; > + desc.BindFlags = D3D10_BIND_RENDER_TARGET; > + desc.CPUAccessFlags = 0; > + desc.MiscFlags = 0; > + hr = ID3D10Device_CreateTexture2D(device, &desc, NULL, &texture); > + if (quality_level_count) > + { > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > + ID3D10Texture2D_Release(texture); > + desc.SampleDesc.Quality = quality_level_count; > + hr = ID3D10Device_CreateTexture2D(device, &desc, NULL, &texture); > + } > + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); > + > + /* We assume 15 samples multisampling is never supported in practice. */ > + desc.SampleDesc.Count = 15; > + desc.SampleDesc.Quality = 0; > + hr = ID3D10Device_CreateTexture2D(device, &desc, NULL, &texture); > + ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr); > + > + refcount = ID3D10Device_Release(device); > + ok(!refcount, "Device has %u references left.\n", refcount); > +} > + > START_TEST(device) > { > test_feature_level(); > @@ -5168,4 +5215,5 @@ START_TEST(device) > test_copy_subresource_region(); > test_multisample_init(); > test_checkmultisamplequalitylevels(); > + test_invalid_multisample(); > } > -- > 2.4.10 > > > This is fine by me but it could be considered to be merged into test_create_texture2d().

Jan. 29, 2016

Re: [PATCH 2/6] d3d11: Implement d3d10_device_CheckMultisampleQualityLevels().

by Józef Kucia

On Fri, Jan 29, 2016 at 12:51 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > dlls/d3d10core/tests/device.c | 5 ++--- > dlls/d3d11/device.c | 33 +++++++++++++++++++++++++++++++-- > 2 files changed, 33 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3d10core/tests/device.c b/dlls/d3d10core/tests/device.c > index 92ae1cf..d267471 100644 > --- a/dlls/d3d10core/tests/device.c > +++ b/dlls/d3d10core/tests/device.c > @@ -5002,7 +5002,7 @@ static void test_multisample_init(void) > } > > hr = ID3D10Device_CheckMultisampleQualityLevels(device, DXGI_FORMAT_R8G8B8A8_UNORM, 2, &count); > - todo_wine ok(SUCCEEDED(hr), "Failed to get quality levels, hr %#x.\n", hr); > + ok(SUCCEEDED(hr), "Failed to get quality levels, hr %#x.\n", hr); > if (!count) > { > skip("Multisampling not supported for DXGI_FORMAT_R8G8B8A8_UNORM, skipping tests.\n"); > @@ -5032,7 +5032,6 @@ static void test_multisample_init(void) > hr = ID3D10Device_CreateTexture2D(device, &desc, NULL, &multi); > ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > > - ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > ID3D10Device_ResolveSubresource(device, (ID3D10Resource *)backbuffer, 0, > (ID3D10Resource *)multi, 0, DXGI_FORMAT_R8G8B8A8_UNORM); > > @@ -5052,7 +5051,7 @@ static void test_multisample_init(void) > break; > } > release_texture_readback(&rb); > - ok(all_zero, "Got unexpected color 0x%08x, position %ux%u.\n", color, x, y); > + todo_wine ok(all_zero, "Got unexpected color 0x%08x, position %ux%u.\n", color, x, y); > > ID3D10RenderTargetView_Release(rtview); > ID3D10Texture2D_Release(backbuffer); > diff --git a/dlls/d3d11/device.c b/dlls/d3d11/device.c > index 785e537..e7d2521 100644 > --- a/dlls/d3d11/device.c > +++ b/dlls/d3d11/device.c > @@ -4501,10 +4501,39 @@ static HRESULT STDMETHODCALLTYPE d3d10_device_CheckFormatSupport(ID3D10Device1 * > static HRESULT STDMETHODCALLTYPE d3d10_device_CheckMultisampleQualityLevels(ID3D10Device1 *iface, > DXGI_FORMAT format, UINT sample_count, UINT *quality_level_count) > { > - FIXME("iface %p, format %s, sample_count %u, quality_level_count %p stub!\n", > + struct d3d_device *device = impl_from_ID3D10Device(iface); > + HRESULT hr; > + > + TRACE("iface %p, format %s, sample_count %u, quality_level_count %p.\n", > iface, debug_dxgi_format(format), sample_count, quality_level_count); > > - return E_NOTIMPL; > + if (!quality_level_count) > + return E_INVALIDARG; > + > + *quality_level_count = 0; > + > + if (!sample_count) > + return E_FAIL; > + if (sample_count == 1) > + { > + *quality_level_count = 1; > + return S_OK; > + } > + if (sample_count > 32) > + return E_FAIL; > + > + if (sample_count > 16) > + { > + FIXME("sample_count %u not handled yet.\n", sample_count); > + return S_OK; > + } > + hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device, > + wined3dformat_from_dxgi_format(format), sample_count, quality_level_count); > + if (hr == WINED3DERR_INVALIDCALL) > + return E_INVALIDARG; > + if (hr == WINED3DERR_NOTAVAILABLE) > + return S_OK; > + return hr; > } I think you could simply call d3d11_device_CheckFormatSupport() from d3d10_device_CheckFormatSupport(). We do it that way for some ID3D10Device methods, e.g. d3d10_device_CreateBlendState1().

Jan. 29, 2016

RE: [PATCH] user32/tests: Add some expected WPARAM values to the SetFocusComboBox sequences

by Hugh McMaster

On Fri, 29 Jan 2016 03:27:13 -0600, 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=20077 > > Your paranoid android. > > > === w1064 (32 bit msg) === > msg.c:6290: Test failed: Update region shouldn't be empty > msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 > msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different These are unrelated failures. -- Hugh McMaster

Jan. 29, 2016

Re: [PATCH 4/7] ddraw/tests: Add tests for invalid render states.

by Józef Kucia

On Thu, Jan 28, 2016 at 2:51 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 January 2016 at 00:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> >> --- >> Tested on Windows 7 and 10. >> >> A similar test crashes in ddraw1. >> >> I'm also not sure if this test is safe for ddraw7 as it seems to crash >> with higher values. > > Yeah, it probably corrupts memory in ddraw7. What does GetRenderState() do? > GetRenderState() returns the expected values but it fails for some invalid state values with DDERR_INVALIDPARAMS. A ddraw7 device is also usable after setting invalid states (I was able to draw something after setting invalid states). Nevertheless, I doubt it's enough indication of anything.

Jan. 29, 2016

Re: [PATCH] user32/tests: Add some expected WPARAM values to the SetFocusComboBox sequences

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=20077 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

Jan. 29, 2016

Re: [PATCH 3/3] bcrypt: Added BCRYPT_ALGORITHM_NAME property implementation.

by Hans Leidekker

Hi Jacek, > --- a/dlls/bcrypt/bcrypt_main.c > +++ b/dlls/bcrypt/bcrypt_main.c > @@ -182,11 +182,12 @@ enum alg_id > > struct { > ULONG hash_length; > + WCHAR alg_name[16]; > } alg_props[] = { > - /* ALG_ID_SHA1 */ { 20 }, > - /* ALG_ID_SHA256 */ { 32 }, > - /* ALG_ID_SHA384 */ { 48 }, > - /* ALG_ID_SHA512 */ { 64 } > + /* ALG_ID_SHA1 */ { 20, {'S','H','A','1'} }, > + /* ALG_ID_SHA256 */ { 32, {'S','H','A','2','5','6'} }, > + /* ALG_ID_SHA384 */ { 48, {'S','H','A','3','8','4'} }, > + /* ALG_ID_SHA512 */ { 64, {'S','H','A','5','1','2'} } > }; I would use BCRYPT_SHA1_ALGORITHM, etc here and make alg_props static const.

Jan. 29, 2016

Re: shell32/tests: Add traces to the WaitForInputIdle() hooking process.

by Henri Verbeet

On 29 January 2016 at 00:54, Francois Gouget <fgouget(a)codeweavers.com> wrote: > * There is a set of traces showing WaitForInputIdle() being > replaced with our own implementation: > shlexec.c:2318: Hooked USER32.dll.WaitForInputIdle > > * And then traces showing our implementation being called: > shlexec.c:2258: WaitForInputIdle() waiting for dde event > > Except that on Windows 10 we never get the second set of traces which > means we failed to override WaitForInputIdle(). > I'm hardly an expert on shell32, but any chance the hooking worked fine and WaitForInputIdle() is just not getting called? Would explicitly specifying SEE_MASK_WAITFORINPUTIDLE make it any better?

Jan. 29, 2016

Re: [5/6] shell32/tests: Test environment variable inheritance with ShellExecute().

by Francois Gouget

On Thu, 28 Jan 2016, Marvin wrote: [...] > === wvistau64 (32 bit shlexec) === > shlexec.c:1666: Test failed: WaitForSingleObject returned 258 > shlexec.c:1695: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' > shlexec.c:1703: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\test file.noassoc.shlexec' > shlexec.c:1695: Test failed: argvA3 expected 'QuotedUpperL', got 'QuotedLowerL' > shlexec.c:1666: Test failed: ShlexecVar expected 'Present', but key not found or empty > shlexec.c:1695: Test failed: argvA3 expected 'Open', but key not found or empty > shlexec.c:1703: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\masked file.shlexec', but key not found or empty The usual occasional timeout-induced failures for this VM. > === w1064 (32 bit shlexec) === > shlexec.c:2426: Test failed: failed: rc=29 err=2 > shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty > shlexec.c:2426: Test failed: failed: rc=29 err=32 > shlexec.c:2426: Test failed: failed: rc=29 err=2 > shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty > shlexec.c:2426: Test failed: failed: rc=29 err=32 > > === w1064 (64 bit shlexec) === > shlexec.c:2426: Test failed: failed: rc=29 err=2 > shlexec.c:2426: Test failed: failed: rc=29 err=2 > shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty > shlexec.c:2426: Test failed: failed: rc=29 err=32 > shlexec.c:2438: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt9FCE.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt9FCE.tmp\test file.sde")]' > shlexec.c:2426: Test failed: failed: rc=29 err=2 > shlexec.c:2426: Test failed: failed: rc=29 err=2 So the ShlexecVar lines are new but in fact it's caused by the same DDE failures we have had all along on Windows 10. As explained in the email below the issue appears to be that hooking WaitForInputIdle() has not effect on Windows 10. So ShellExecute() does not wait for the child process to do the DDE exchange and returns too early. This results in a race between the parent and child process(es), both for the DDE exchange, and when checking the content of the child result file. https://www.winehq.org/pipermail/wine-devel/2016-January/111496.html -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 29, 2016

Re: [6/6] shell32/tests: Add server-side DDE checks.

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=20064 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 shlexec.c:2447: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt209B.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt209B.tmp\test file.sde")]' shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2435: Test failed: failed: rc=29 err=2

Jan. 29, 2016

Re: [5/6] shell32/tests: Test environment variable inheritance with ShellExecute().

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=20063 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1666: Test failed: WaitForSingleObject returned 258 shlexec.c:1695: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1703: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\test file.noassoc.shlexec' shlexec.c:1695: Test failed: argvA3 expected 'QuotedUpperL', got 'QuotedLowerL' shlexec.c:1666: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:1695: Test failed: argvA3 expected 'Open', but key not found or empty shlexec.c:1703: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD4FA.tmp\masked file.shlexec', but key not found or empty === w1064 (32 bit shlexec) === shlexec.c:2426: Test failed: failed: rc=29 err=2 shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2426: Test failed: failed: rc=29 err=32 shlexec.c:2426: Test failed: failed: rc=29 err=2 shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2426: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2426: Test failed: failed: rc=29 err=2 shlexec.c:2426: Test failed: failed: rc=29 err=2 shlexec.c:2424: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2426: Test failed: failed: rc=29 err=32 shlexec.c:2438: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt9FCE.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt9FCE.tmp\test file.sde")]' shlexec.c:2426: Test failed: failed: rc=29 err=2 shlexec.c:2426: Test failed: failed: rc=29 err=2

Jan. 29, 2016

Re: [4/6] shell32/tests: Check for failures in the child process.

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=20062 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2408: Test failed: failed: rc=29 err=2 shlexec.c:2408: Test failed: failed: rc=29 err=32 shlexec.c:2408: Test failed: failed: rc=29 err=2 shlexec.c:2408: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2408: Test failed: failed: rc=29 err=2 shlexec.c:2408: Test failed: failed: rc=29 err=32 shlexec.c:2408: Test failed: failed: rc=29 err=2 shlexec.c:2408: Test failed: failed: rc=29 err=32

Jan. 29, 2016

Re: [3/6] shell32/tests: Check the child process exit code and close the process handle.

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=20061 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2 shlexec.c:2394: Test failed: failed: rc=29 err=2

Jan. 28, 2016

Re: shell32/tests: Add traces to the WaitForInputIdle() hooking process.

by Francois Gouget

On Thu, 28 Jan 2016, Marvin wrote: [...] > === w1064 (32 bit shlexec) === > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2391: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]' > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 > > === w1064 (64 bit shlexec) === > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 > shlexec.c:2379: Test failed: failed: rc=29 err=2 These are the usual Windows 10 DDE ShellExecute() failures. What's interesting is that I think the extra traces point to the reason for these failures. Unfortunately I don't know how to fix it. The extra traces (and a bit more) can be seen here: https://testbot.winehq.org/JobDetails.pl?Key=20056&log_207=1#k207 * There is a set of traces showing WaitForInputIdle() being replaced with our own implementation: shlexec.c:2318: Hooked USER32.dll.WaitForInputIdle * And then traces showing our implementation being called: shlexec.c:2258: WaitForInputIdle() waiting for dde event Except that on Windows 10 we never get the second set of traces which means we failed to override WaitForInputIdle(). Why override WaitForInputIdle()? Here it is from the source: * WaitForInputIdle() will normally return immediately for console apps. * That's a problem for us because ShellExecute will assume that an app * is ready to receive DDE messages after it has called * WaitForInputIdle() on that app. To work around that we install our * own version of WaitForInputIdle() that will wait for the child to * explicitly tell us that it is ready. We do that by changing the * entry for WaitForInputIdle() in the shell32 import address table. Does anyone know why hooking WaitForInputIdle() had no effect on Windows 10? -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 28, 2016

Re: [2/6] shell32/tests: Declare childPrintf() as a printf-style function.

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=20060 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2401: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt8341.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt8341.tmp\test file.sde")]' shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2

Jan. 28, 2016

Re: [1/6] shell32/tests: Reorder the functions to avoid forward declarations.

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=20059 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2 shlexec.c:2389: Test failed: failed: rc=29 err=2

Jan. 28, 2016

Re: shell32/tests: Add traces to the WaitForInputIdle() hooking process.

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=20058 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2391: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]' shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2

Jan. 28, 2016

Re: [1/3] scrrun: Implement filesys_DriveExists. (resend)

by Joachim Priesner

Am Donnerstag, 28. Januar 2016 schrieb Alexandre Julliard: > Joachim Priesner <joachim.priesner(a)web.de> writes: > > > - return E_NOTIMPL; > > + if (!pfExists) return E_POINTER; > > + *pfExists = VARIANT_FALSE; > > + len = SysStringLen(DriveSpec); > > + if (len >= 1 && DriveSpec[0] >= 'A' && DriveSpec[0] <= 'Z' > > + && (len < 2 || DriveSpec[1] == ':') > > + && (len < 3 || DriveSpec[2] == '\\')) { > > Surely lower-case drives should work too. Of course. Resent, along with some minor fixes to the other patches in the series.

Jan. 28, 2016

Re: [PATCH 2/2] shell32: Set the stream and storage attributes where needed.

by Huw Davies

On 28 Jan 2016, at 15:41, 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=20039 > > Your paranoid android. > > > === w1064 (32 bit shlfolder) === > shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 This is an existing failure. Huw.

Jan. 28, 2016

Re: [PATCH 2/2] shell32: Set the stream and storage attributes where needed.

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=20039 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

Jan. 28, 2016

Re: ndis.sys: add NdisAllocateSpinLock stub

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > From 5450fedec076c6d2f2c10c2e5cfa8f79578803a0 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Tue, 5 Jan 2016 17:24:12 -0600 > Subject: [PATCH] ndis.sys: add NdisAllocateSpinLock stub > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/ndis.sys/main.c | 5 +++++ > include/ddk/ndis.h | 7 +++++++ > 2 files changed, 12 insertions(+) You forgot the spec file. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2016

Re: [1/3] scrrun: Implement filesys_DriveExists. (resend)

by Alexandre Julliard

Joachim Priesner <joachim.priesner(a)web.de> writes: > - return E_NOTIMPL; > + if (!pfExists) return E_POINTER; > + *pfExists = VARIANT_FALSE; > + len = SysStringLen(DriveSpec); > + if (len >= 1 && DriveSpec[0] >= 'A' && DriveSpec[0] <= 'Z' > + && (len < 2 || DriveSpec[1] == ':') > + && (len < 3 || DriveSpec[2] == '\\')) { Surely lower-case drives should work too. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2016

Re: [PATCH 4/7] ddraw/tests: Add tests for invalid render states.

by Henri Verbeet

On 28 January 2016 at 00:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > Tested on Windows 7 and 10. > > A similar test crashes in ddraw1. > > I'm also not sure if this test is safe for ddraw7 as it seems to crash > with higher values. Yeah, it probably corrupts memory in ddraw7. What does GetRenderState() do?

Jan. 28, 2016

Re: [PATCH 6/7] wined3d: Validate stream_idx in wined3d_device_set_stream_source_freq().

by Henri Verbeet

On 28 January 2016 at 00:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1412,6 +1412,12 @@ HRESULT CDECL wined3d_device_set_stream_source_freq(struct wined3d_device *devic > return WINED3DERR_INVALIDCALL; > } > > + if (stream_idx >= MAX_STREAMS) > + { > + FIXME("Stream index %u out of range.\n", stream_idx); > + return WINED3DERR_INVALIDCALL; > + } This would have to be a WARN instead of a FIXME, but in general we don't do this in wined3d unless we have to.

Jan. 28, 2016

Re: [PATCH 2/7] d3d9/tests: Add test for invalid render states.

by Henri Verbeet

On 28 January 2016 at 00:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > A similar test crashes in d3d8. > --- > dlls/d3d9/tests/device.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > This probably just corrupts memory on Windows, if e.g. SetTextureStageState() is any indication.

Jan. 28, 2016

Re: [PATCH 1/7] wined3d: Validate render state in wined3d_device_set_render_state().

by Henri Verbeet

On 28 January 2016 at 00:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (state > WINEHIGHEST_RENDER_STATE) > + { > + WARN("Unhandled render state %#x.\n", state); > + return; > + } It may make sense to do this for wined3d_device_get_render_state() as well.

Jan. 28, 2016

Re: [PATCH v2] ntoskrnl.exe: Implement IoGetDeviceProperty for DevicePropertyPhysicalDeviceObjectName

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + switch (device_property) > + { > + case DevicePropertyPhysicalDeviceObjectName: > + { > + OBJECT_NAME_INFORMATION *name = HeapAlloc(GetProcessHeap(), 0, buffer_length + (sizeof(OBJECT_NAME_INFORMATION))); > + > + status = NtQueryObject(device->Reserved, ObjectNameInformation, name, buffer_length + sizeof(OBJECT_NAME_INFORMATION), result_length); > + if (status == STATUS_SUCCESS) > + memcpy(property_buffer, name->Name.Buffer, name->Name.Length); > + HeapFree(GetProcessHeap(), 0, name); > + break; result_length is not handled correctly. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2016

Re: [PATCH] d3dx9: Signature isn't part of the DDS header

by Henri Verbeet

On 28 January 2016 at 00:20, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> @@ -437,8 +442,8 @@ static HRESULT load_surface_from_dds(IDirect3DSurface9 *dst_surface, const PALET >> { >> UINT size; >> UINT src_pitch; >> - const struct dds_header *header = src_data; >> - const BYTE *pixels = (BYTE *)(header + 1); >> + const struct DDS *dds = src_data; >> + const BYTE *pixels = (BYTE *)(dds + 1); > > I guess you could instead make the src_data parameter BYTE * and > compute "pixels" as src_data + sizeof(struct dds) (or however you want > to call the new struct). It's mostly a matter of taste though so it's > fine to me either way. > If you define struct dds as struct dds { DWORD signature; struct dds_header header; BYTE data[1]; }; you can just change load_surface_from_dds() to take "const struct dds *dds" as parameter instead of src_data, and pass dds->data to D3DXLoadSurfaceFromMemory(). Or just pass dds->data to load_surface_from_dds() and rename that function, since it doesn't do all that much with the information in the header. It also means you can do things like "return FIELD_OFFSET(struct dds, data[data_size]);" in calculate_dds_file_size(). You may also want to consider just merging surface.c and volume.c into texture.c. On 27 January 2016 at 10:29, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > + memset(dds, 0, sizeof(*dds)); > + dds->signature = MAKEFOURCC('D','D','S',' '); > + dds->header.size = sizeof(struct dds_header); + dds->header.size = sizeof(dds->header);

Jan. 28, 2016

Re: [PATCH 4/7] ddraw/tests: Add tests for invalid render states.

by Józef Kucia

On Thu, Jan 28, 2016 at 12:53 AM, Marvin <testbot(a)winehq.org> 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=20023 > > Your paranoid android. > > > === build (build) === > Missing build status line > The build timed out > > Actual test run: ddraw2 https://testbot.winehq.org/JobDetails.pl?Key=20031 ddraw4 https://testbot.winehq.org/JobDetails.pl?Key=20032 ddraw7 https://testbot.winehq.org/JobDetails.pl?Key=20033

Jan. 28, 2016

Re: [PATCH v2] winspool.drv: If the call to cupsPrintFile fails, print the cups error message.

by Huw Davies

On Wed, Jan 27, 2016 at 08:58:26AM -0600, Jeremy White wrote: > diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c > index cebf6f7..89966ce 100644 > --- a/dlls/winspool.drv/info.c > +++ b/dlls/winspool.drv/info.c > @@ -781,6 +781,7 @@ static void *cupshandle; > DO_FUNC(cupsPrintFile) > #define CUPS_OPT_FUNCS \ > DO_FUNC(cupsGetNamedDest); \ > + DO_FUNC(cupsLastErrorString); \ > DO_FUNC(cupsGetPPD3) Could we keep these in alphabetical order please? Otherwise, looks good. Huw.

Jan. 28, 2016

Re: [PATCH 5/7] ddraw/tests: Move other SetRenderState() tests to test_set_render_state().

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=20024 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2301: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2301: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2485: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2632: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2632: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

Jan. 28, 2016

Re: [PATCH 6/6] d3d8/tests: Test the creation of render targets with invalid multisample settings.

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=20021 Your paranoid android. === w1064 (32 bit device) === device.c:2727: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2732: Test failed: The focus window is active. device.c:2740: Test failed: Got unexpected hr 0x88760869. device.c:2746: Test failed: Got unexpect screen size 800x600. device.c:2761: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2770: Test failed: Got unexpect screen size 800x600. device.c:2783: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2791: Test failed: Got unexpect width 640. device.c:2792: Test failed: Got unexpect height 480.

Jan. 27, 2016

Re: [PATCH 5/6] d3d8/tests: Port test_checkdevicemultisampletype() from d3d9.

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=20020 Your paranoid android. === w1064 (32 bit device) === device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2673: Test failed: The focus window is active. device.c:2681: Test failed: Got unexpected hr 0x88760869. device.c:2687: Test failed: Got unexpect screen size 800x600. device.c:2702: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2711: Test failed: Got unexpect screen size 800x600. device.c:2724: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2732: Test failed: Got unexpect width 640. device.c:2733: Test failed: Got unexpect height 480.

Jan. 27, 2016

Re: [PATCH 4/7] ddraw/tests: Add tests for invalid render states.

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=20023 Your paranoid android. === build (build) === Missing build status line The build timed out

Jan. 27, 2016

Re: [PATCH] d3dx9: Signature isn't part of the DDS header

by Matteo Bruni

2016-01-27 10:29 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx9_36/surface.c | 78 ++++++++++++++++++++++++++----------------------- > 1 file changed, 41 insertions(+), 37 deletions(-) > > diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c > index 4fa2a76..a7bf9b7 100644 > --- a/dlls/d3dx9_36/surface.c > +++ b/dlls/d3dx9_36/surface.c > @@ -125,7 +125,6 @@ struct dds_pixel_format > > struct dds_header > { > - DWORD signature; > DWORD size; > DWORD flags; > DWORD height; > @@ -142,6 +141,12 @@ struct dds_header > DWORD reserved2; > }; > > +struct DDS Probably better to pick a lowercase struct name. > +{ > + DWORD signature; > + struct dds_header header; > +}; > + > static D3DFORMAT dds_fourcc_to_d3dformat(DWORD fourcc) > { > unsigned int i; > @@ -355,7 +360,7 @@ static UINT calculate_dds_file_size(D3DFORMAT format, UINT width, UINT height, U > } > > file_size *= faces; > - file_size += sizeof(struct dds_header); > + file_size += sizeof(struct DDS); > return file_size; > } > > @@ -379,37 +384,37 @@ static HRESULT get_image_info_from_dds(const void *buffer, UINT length, D3DXIMAG > { > UINT faces = 1; > UINT expected_length; > - const struct dds_header *header = buffer; > + const struct DDS *dds = buffer; I'd keep the *header variable, initializing it to &dds->header... > > - if (length < sizeof(*header) || !info) > + if (length < sizeof(*dds) || !info) > return D3DXERR_INVALIDDATA; > > - if (header->pixel_format.size != sizeof(header->pixel_format)) > + if (dds->header.pixel_format.size != sizeof(dds->header.pixel_format)) > return D3DXERR_INVALIDDATA; ... so that you can leave this and the other similar lines below unchanged. > > - info->Width = header->width; > - info->Height = header->height; > + info->Width = dds->header.width; > + info->Height = dds->header.height; > info->Depth = 1; > - info->MipLevels = header->miplevels ? header->miplevels : 1; > + info->MipLevels = dds->header.miplevels ? dds->header.miplevels : 1; > > - info->Format = dds_pixel_format_to_d3dformat(&header->pixel_format); > + info->Format = dds_pixel_format_to_d3dformat(&dds->header.pixel_format); > if (info->Format == D3DFMT_UNKNOWN) > return D3DXERR_INVALIDDATA; > > TRACE("Pixel format is %#x\n", info->Format); > > - if (header->caps2 & DDS_CAPS2_VOLUME) > + if (dds->header.caps2 & DDS_CAPS2_VOLUME) > { > - info->Depth = header->depth; > + info->Depth = dds->header.depth; > info->ResourceType = D3DRTYPE_VOLUMETEXTURE; > } > - else if (header->caps2 & DDS_CAPS2_CUBEMAP) > + else if (dds->header.caps2 & DDS_CAPS2_CUBEMAP) > { > DWORD face; > faces = 0; > for (face = DDS_CAPS2_CUBEMAP_POSITIVEX; face <= DDS_CAPS2_CUBEMAP_NEGATIVEZ; face <<= 1) > { > - if (header->caps2 & face) > + if (dds->header.caps2 & face) > faces++; > } > info->ResourceType = D3DRTYPE_CUBETEXTURE; > @@ -437,8 +442,8 @@ static HRESULT load_surface_from_dds(IDirect3DSurface9 *dst_surface, const PALET > { > UINT size; > UINT src_pitch; > - const struct dds_header *header = src_data; > - const BYTE *pixels = (BYTE *)(header + 1); > + const struct DDS *dds = src_data; > + const BYTE *pixels = (BYTE *)(dds + 1); I guess you could instead make the src_data parameter BYTE * and compute "pixels" as src_data + sizeof(struct dds) (or however you want to call the new struct). It's mostly a matter of taste though so it's fine to me either way.

Jan. 27, 2016

Re: [PATCH 6/6] jscript: Added JSON 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=20011 Your paranoid android. === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

Jan. 27, 2016

Re: [PATCH 3/6] jscript: Added JSON object stub implementation.

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=20010 Your paranoid android. === build (build) === Missing build status line The build timed out

Jan. 27, 2016

Re: [PATCH] cmd: Consistently wrap lines to 75 characters.

by Alex Henrie

2015-12-08 4:30 GMT-07:00 Francois Gouget <fgouget(a)free.fr>: > On Mon, 7 Dec 2015, Alex Henrie wrote: > >> 2015-12-07 4:56 GMT-07:00 Francois Gouget <fgouget(a)free.fr>: >> >> >> I removed Hebrew "translations" of cmd.rc that were just copies of >> >> >> the English strings, >> >> > >> >> > There was a reason for these. Has anything changed? >> >> >> >> What was the reason? >> > >> > See the discussion below with this email stating the Hebrew >> > translator's decision as far as command-line tools are concerned: >> > https://www.winehq.org/pipermail/wine-devel/2011-August/091771.html >> >> Thanks for the link, it was very enlightening. I think the real >> question is: Are we going to support complex scripts in wineconsole >> (Hebrew, Arabic, Hindi, Thai), even though Windows does not? > > Bug 28193 was las tconfirmed in June and while it's totally possible > someone added RTL support to wineconsole without me noticing since then > it seems unlikely. Similarly the situation of the various Unix terminal > emulators probably did not change. So I suspect the answer is not any > time soon, and most likely not in 1.8. I emailed Microsoft about complex scripts in the Command Prompt, and received the following reply from Yosef Durr: "We are tracking this issue and I don’t have an update at this time." I assume that this means Microsoft considers lack of complex script support to be a bug and they plan to fix it in a future version of Windows. So, there is no reason for us not to fully support these languages in Wine. We might even get it working before Microsoft does ;-) >> If the answer is "yes" then removing the copied English from he.po was >> the right thing to do, to make room for real translations in the >> future. If the answer is "no" then we should delete the existing >> Arabic command translations and replace them with English too. > > Removing the corresponding Arabic translation would probably make sense > and at least be consistent but it would be more correct to discuss it > with the translator first... I am CC'ing Mosaab Alzoubi, the Arabic translation's author. -Alex

Jan. 27, 2016

Re: New Wiki

by Alex Henrie

2016-01-19 20:59 GMT-07:00 Rosanne DiMesio <dimesio(a)earthlink.net>: > A couple of things I am not going to touch: > --Home pages: Users will need to recreate their own home pages. > --Translations: I'm not qualified. Translators should keep in mind that I have been editing content as needed as I go along, so please check that when porting your translation. Rosanne, thank you for dealing with the wiki :-) I've been meaning to tell you: Most of the translated wiki pages are old, obsolete, and have needed to be redone from scratch for a long time. -Alex

Jan. 27, 2016