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

Re: [PATCH] wined3d: Fix ATI1 buffer size, try 3
by Marvin 25 Aug '16

25 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25380 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH] ntdll: Use boot time to calculate tick count
by Ken Thomases 25 Aug '16

25 Aug '16

On Aug 25, 2016, at 2:55 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Two catches with the macOS behavior: First, this implementation is much > more expensive than one system call in a very frequently called > function. mach_absolute_time() isn't even a system call. It's implemented in user space. It reads the TSC from the CPU and applies adjustments read from the commpage. There's a potential for it to loop if the commpage is adjusted while it's running. > It's an open question whether fixing behavior on sleep is > worth the cost. Second, the boot time has precision only to the nearest > second. This could cause skew if the current time is updated in <~1 > second intervals. Actually, it will cause skew whenever the current time is updated by a delta that's not whole seconds. Another issue is the race between sysctl() and gettimeofday(). If a time adjustment occurs between them, you'll get an incorrect result. This could be detected by checking the boot time again after gettimeofday() and repeating if it changed. Unfortunately, that adds even more overhead. (Actually, if we track the last known boot time in a static, we could only check it after and loop if it changed. That requires interlocked updating of the static, though, to make it thread safe.) Unfortunately, I don't know a good solution. I think that it may be a bug that mach_absolute_time() doesn't count time spent sleeping, but that's of no comfort. -Ken

1 0

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try2)
by Piotr Caban 25 Aug '16

25 Aug '16

Hi Daniel, On 08/18/16 18:29, Daniel Lehman wrote: > + pass = 0; > + pRtlCaptureContext(&ctx); > + if (InterlockedIncrement(&pass) == 1) /* interlocked to prevent compiler from moving */ The patch looks good for me except one thing that I don't understand. Why there's no risk that compiler will move the pass=0 assignment after pRtlCaptureContext call? Maybe something like this will be more correct: pass = 0; InterlockedIncrement(&pass); pRtlCaptureContext(&ctx); if (InterlockedIncrement(&pass) == 2) ? Thanks, Piotr

2 1

Re: [PATCH] user32: Only use the driver for getting the position
by Alexandre Julliard 25 Aug '16

25 Aug '16

Max Qian <public(a)maxqia.com> writes: > This fixes bug 24951 and reverts GetCursorPos related > changes from commits 39c4e6d, f1a3480, and 6576703. This is going to break things that use low-level hooks, in particular dinput, since the cursor won't be in sync with the hardware events. We also have tests for that: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so input && touch input.ok input.c:1299: Test failed: Wrong new pos: (103,103) input.c:1302: Test failed: Wrong new pos: (106,106) input.c:1305: Test failed: Wrong new pos: (109,109) input.c:1308: Test failed: Wrong new pos: (112,112) make: *** [input.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] d3d8/tests: Prefer higher resolutions in test_reset().
by Marvin 25 Aug '16

25 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25373 Your paranoid android. === w8 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480.

1 0

Re: [PATCH v9 2/3] shell32: Implement FolderItems_Item.
by Sebastian Lackner 25 Aug '16

25 Aug '16

On 23.08.2016 06:02, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 136 +++++++++++++++++++++++++++++++++++-- > dlls/shell32/tests/shelldispatch.c | 13 ---- > 2 files changed, 130 insertions(+), 19 deletions(-) > Thanks for the updated version, this already looks much better. Nevertheless, I have two more small requests: * You decided to use StrDupW(), but there shouldn't be any need to use this shlwapi function. The only other place where it was used in shell32 was wrong and has been fixed with: http://source.winehq.org/git/wine.git/commit/a11fb74ffb15b60768c6fa49b07251… I would suggest to move the strdupW() function which is used in other parts of shell32 to the public header file and then use that instead. * You decided to use exponential growth for the filenames buffer which is better than allocating only one element at once. Nevertheless, it might still waste a lot of memory. I would suggest to use either linear growth or attempt to shrink the buffer size to release unnecessary space. Patch 1 should technically be fine, but the code still looks unnecessary complex to me. I will think about some ways to simplify it a bit more. Regards, Sebastian

2 1

Re: [PATCH v8 2/3] shell32: Implement FolderItems_Item.
by Sebastian Lackner 25 Aug '16

25 Aug '16

On 19.08.2016 11:43, Alex Henrie wrote: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 133 +++++++++++++++++++++++++++++++++++-- > dlls/shell32/tests/shelldispatch.c | 12 ---- > 2 files changed, 127 insertions(+), 18 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index ac79302..a456ad4 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -68,6 +68,9 @@ typedef struct { > typedef struct { > FolderItems3 FolderItems3_iface; > LONG ref; > + VARIANT dir; > + BSTR *item_paths; > + LONG item_count; > } FolderItemsImpl; > > typedef struct { > @@ -989,11 +992,18 @@ static ULONG WINAPI FolderItemsImpl_Release(FolderItems3 *iface) > { > FolderItemsImpl *This = impl_from_FolderItems(iface); > ULONG ref = InterlockedDecrement(&This->ref); > + int i; > > TRACE("(%p), new refcount=%i\n", iface, ref); > > if (!ref) > + { > + VariantClear(&This->dir); > + for (i = 0; i < This->item_count; i++) > + SysFreeString(This->item_paths[i]); > + HeapFree(GetProcessHeap(), 0, This->item_paths); > HeapFree(GetProcessHeap(), 0, This); > + } > return ref; > } > > @@ -1079,10 +1089,47 @@ static HRESULT WINAPI FolderItemsImpl_get_Parent(FolderItems3 *iface, IDispatch > > static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > { > - FIXME("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + VARIANT path; > + int i; > + > + TRACE("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > > *ppid = NULL; > - return E_NOTIMPL; > + > + switch (V_VT(&index)) > + { > + case VT_I2: > + VariantChangeType(&index, &index, 0, VT_I4); > + /* fall through */ > + case VT_I4: > + if (V_I4(&index) < 0 || V_I4(&index) >= This->item_count) > + return S_FALSE; > + > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = This->item_paths[V_I4(&index)]; > + return FolderItem_Constructor(&path, ppid); > + > + case VT_BSTR: > + for (i = 0; i < This->item_count; i++) > + { > + if (!lstrcmpW(V_BSTR(&index), PathFindFileNameW(This->item_paths[i]))) Usually strcmpW is preferred in Wine code. Its better to do NULL pointer checks explicitly. > + { > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = This->item_paths[i]; > + return FolderItem_Constructor(&path, ppid); > + } > + } > + return S_FALSE; > + > + case VT_ERROR: > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = V_BSTR(&This->dir); > + return FolderItem_Constructor(&path, ppid); You can also pass &This->dir directly to the constructor. > + > + default: > + return E_NOTIMPL; > + } > } > > static HRESULT WINAPI FolderItemsImpl__NewEnum(FolderItems3 *iface, IUnknown **ppunk) > @@ -1139,21 +1186,93 @@ static const FolderItems3Vtbl FolderItemsImpl_Vtbl = { > FolderItemsImpl_get_Verbs > }; > > -static HRESULT FolderItems_Constructor(FolderItems **ppfi) > +static HRESULT FolderItems_Constructor(VARIANT *dir, FolderItems **ppfi) > { > + static const WCHAR backslash_star[] = {'\\','*',0}; > + static const WCHAR dot[] = {'.',0}; > + static const WCHAR dot_dot[] = {'.','.',0}; > FolderItemsImpl *This; > + WCHAR path[MAX_PATH + 2]; > + HANDLE first_file; > + WIN32_FIND_DATAW file_info; > + BSTR *paths; > + HRESULT ret; > > TRACE("\n"); Not really an issue, but you could add a trace for the function arguments here. > > *ppfi = NULL; > > + if (V_VT(dir) == VT_I4) > + { > + FIXME("special folder constants are not supported\n"); > + return E_NOTIMPL; > + } > + > This = HeapAlloc(GetProcessHeap(), 0, sizeof(FolderItemsImpl)); > if (!This) return E_OUTOFMEMORY; > This->FolderItems3_iface.lpVtbl = &FolderItemsImpl_Vtbl; > This->ref = 1; > > + VariantInit(&This->dir); > + ret = VariantCopy(&This->dir, dir); > + if (FAILED(ret)) > + { > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + > + This->item_paths = HeapAlloc(GetProcessHeap(), 0, sizeof(BSTR)); > + if (!This->item_paths) > + { > + VariantClear(&This->dir); > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + This->item_count = 0; > + > + lstrcpyW(path, V_BSTR(dir)); > + lstrcatW(path, backslash_star); > + first_file = FindFirstFileW(path, &file_info); > + if (first_file != INVALID_HANDLE_VALUE) > + { > + do > + { > + if (!lstrcmpW(file_info.cFileName, dot) || !lstrcmpW(file_info.cFileName, dot_dot)) > + continue; Similar to above, strcmpW is usually preferred. > + > + if (!PathCombineW(path, V_BSTR(dir), file_info.cFileName)) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } I think it makes more sense to store the relative paths, there is no need to prepend the directory name in advance. FolderItemsImpl_Item also expects a relative path for example. > + > + paths = HeapReAlloc(GetProcessHeap(), 0, This->item_paths, (This->item_count + 1) * sizeof(BSTR)); It seems more reasonable to increase the buffer size in bigger chunks. Its better to have a few entries overhead than to do frequent reallocs. > + if (!paths) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } > + This->item_paths = paths; > + > + This->item_paths[This->item_count] = SysAllocString(path); > + if (!This->item_paths[This->item_count]) > + { > + ret = E_OUTOFMEMORY; > + goto fail; > + } > + This->item_count++; > + } > + while (FindNextFileW(first_file, &file_info)); > + > + FindClose(first_file); > + } > + > *ppfi = (FolderItems*)&This->FolderItems3_iface; > - return S_OK; > + return ret; It is better to return S_OK explicitly because !FAILED(ret) could still be any other value >= 0, like S_FALSE for example. > + > +fail: You are leaking the FindFirstFile handle here. > + FolderItems3_Release(&This->FolderItems3_iface); > + return ret; > } > > static HRESULT WINAPI FolderImpl_QueryInterface(Folder3 *iface, REFIID riid, > @@ -1308,9 +1427,11 @@ static HRESULT WINAPI FolderImpl_get_ParentFolder(Folder3 *iface, Folder **ppsf) > > static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) > { > - FIXME("(%p,%p)\n", iface, ppid); > + FolderImpl *This = impl_from_Folder(iface); > + > + TRACE("(%p,%p)\n", iface, ppid); > > - return FolderItems_Constructor(ppid); > + return FolderItems_Constructor(&This->dir, ppid); > } > > static HRESULT WINAPI FolderImpl_ParseName(Folder3 *iface, BSTR name, FolderItem **item) > diff --git a/dlls/shell32/tests/shelldispatch.c b/dlls/shell32/tests/shelldispatch.c > index 6715794..dc4fda4 100644 > --- a/dlls/shell32/tests/shelldispatch.c > +++ b/dlls/shell32/tests/shelldispatch.c > @@ -390,7 +390,6 @@ todo_wine > r = FolderItems_Item(items, var, NULL); > > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > > @@ -470,14 +469,11 @@ todo_wine > r = FolderItems_Item(items, var, &item); > if (i == VT_I2 || i == VT_I4 || i == VT_ERROR) > { > -todo_wine > ok(r == S_OK, "type %d: expected S_OK, got %08x\n", i, r); > -todo_wine > ok(!!item, "item is null\n"); > } > else if (i == VT_BSTR) > { > -todo_wine > ok(r == S_FALSE, "type %d: expected S_FALSE, got %08x\n", i, r); > ok(!item, "item is not null\n"); > } > @@ -495,11 +491,8 @@ todo_wine > V_VT(&var) = VT_ERROR; > V_ERROR(&var) = i; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_OK, "expected S_OK, got %08x\n", r); > -todo_wine > ok(!!item, "item is null\n"); > - if (!item) continue; > > bstr = NULL; > r = FolderItem_get_Path(item, &bstr); > @@ -518,7 +511,6 @@ todo_wine > V_I4(&var) = -1; > item = (FolderItem*)0xdeadbeef; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > > @@ -541,11 +533,8 @@ todo_wine > > item = NULL; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_OK, "file_defs[%d], %d: FolderItems::Item failed: %08x\n", i, j, r); > -todo_wine > ok(!!item, "file_defs[%d], %d: item is null\n", i, j); > - if (!item) continue; > > item2 = NULL; > r = FolderItems_Item(items, var, &item2); > @@ -572,7 +561,6 @@ todo_wine > V_I4(&var) = sizeof(file_defs)/sizeof(file_defs[0]); > item = (FolderItem*)0xdeadbeef; > r = FolderItems_Item(items, var, &item); > -todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!item, "item is not null\n"); > >

2 3

Re: [PATCH] kernel32: Improve tests for pUnregisterWait(0)
by Marvin 24 Aug '16

24 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25353 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH] dinput: Add the 16-bit DLL version on acmGetVersion
by Bruno Jesus 24 Aug '16

24 Aug '16

Sorry, wrong subject. Sent a new one. On Wed, Aug 24, 2016 at 8:09 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Remove the annoying message when Wine is configured as 3.11. The DLL version 2.1 number was tested on Windows 3.11. > > Source for test: > http://alexa.pro.br/~bruno/wine/acm.c > > Compiled 16-bit EXE: > http://alexa.pro.br/~bruno/wine/acm.exe > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/msacm32/msacm32_main.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/msacm32/msacm32_main.c b/dlls/msacm32/msacm32_main.c > index a47611c..efe58af 100644 > --- a/dlls/msacm32/msacm32_main.c > +++ b/dlls/msacm32/msacm32_main.c > @@ -84,6 +84,8 @@ DWORD WINAPI acmGetVersion(void) > switch (version.dwPlatformId) { > case VER_PLATFORM_WIN32_NT: > return 0x04000565; /* 4.0.1381 */ > + case VER_PLATFORM_WIN32s: > + return 0x02010000; /* 2.1 */ > default: > FIXME("%x not supported\n", version.dwPlatformId); > /* fall through */ > -- > 2.9.3 >

1 0

Re: [PATCH 4/4] msvcr90: Add _fpieee_flt tests
by Marvin 24 Aug '16

24 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25343 Your paranoid android. === wxppro (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w2003std (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === wvistau64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w2008s64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w7u (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w7pro64 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w8 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w864 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b === w1064 (32 bit msvcr90) === msvcr90.c:1784: Test failed: 1) Operand1.Format = b msvcr90.c:1784: Test failed: 3) Operand1.Format = b msvcr90.c:1784: Test failed: 4) Operand1.Format = b

1 0