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

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Sebastian Lackner Aug. 25, 2015

Aug. 25, 2015

I also think moving the tests to an existing test file would be better, but here a few additional comments: On 25.08.2015 15:08, Rodrigo Rivas wrote: > diff --git a/dlls/user32/tests/Makefile.in b/dlls/user32/tests/Makefile.in > index 7149dc8..982b0fe 100644 > --- a/dlls/user32/tests/Makefile.in > +++ b/dlls/user32/tests/Makefile.in > @@ -9,6 +9,7 @@ C_SRCS = \ > cursoricon.c \ > dce.c \ > dde.c \ > + defer.c \ > dialog.c \ > edit.c \ > generated.c \ > diff --git a/dlls/user32/tests/defer.c b/dlls/user32/tests/defer.c > new file mode 100644 > index 0000000..eb63384 > --- /dev/null > +++ b/dlls/user32/tests/defer.c > @@ -0,0 +1,168 @@ > +/* > + * Unit tests for DeferWindowPos > + * > + * Copyright 2015 Rodrigo Rivas Costa > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "windows.h" > + > +#include "wine/test.h" > + > + > +#define WIDTH_CHILDREN 50 > +#define NCHILDREN 3 > +#define IDX_FAIL 1 > + > +static HINSTANCE g_hInstance; This is not a DLL, so theoretically no need to use a static variable for that. The overhead of calling GetModuleHandle multiple times should be very small. > +static HWND hChildren[NCHILDREN]; > + > +static void ExpectY(HWND hwnd, int y) > +{ > + RECT r; > + POINT p; > + GetWindowRect(hwnd, &r); > + p.x = r.left; > + p.y = r.top; > + MapWindowPoints(NULL, GetParent(hwnd), &p, 1); > + ok(p.y == y, "Window has not been properly moved: %d != %d\n", (int)p.y, y); I didn't test it, but there should be no need to explicitly cast here. > +} Such a helper function will make it complicated to track down test failures. In this case the code doesn't look too long, so you could directly duplicate it into the individual test functions. The alternative would be to pass the line number to the function, and then use ok_(...) instead. You can take a look at existing tests how to do that. > + > +static void TestDeferWindowPos(int posY) You could split each test function into a separate patch (failing tests marked with "todo_wine"), and then send the fix as a forth patch at the end. It is not strictly necessary, but it would probably be easier for reviewing. > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HWND h = hChildren[i]; > + hdwp = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + ok(hdwp != NULL, "DeferWindowPos failed\n"); > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + ExpectY(hChildren[i], posY); > +} > + > +static void TestBogusDeferWindowPos(int posY) > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HDWP hnext; > + HWND h = hChildren[i]; > + if (i==IDX_FAIL) The style (missing spaces inbetween) is a bit inconsistent here, and also at a couple of places below. > + h = (HWND)0; //Insert an error. This is not a valid HWND. C++ Style comments are not allowed in Wine source. Also, you can use NULL instead of casting 0 to a HWND. > + hnext = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + if (i==IDX_FAIL) > + { > + DWORD err = GetLastError(); > + ok(hnext == NULL, "DeferWindowPos accepted a bogus HWND\n"); > + ok(err == ERROR_INVALID_WINDOW_HANDLE, "Bogus HWND should return ERROR_INVALID_WINDOW_HANDLE, got %d\n", (int)err); Also no need to explicitly cast here. > + } > + else > + { > + ok(hnext != NULL, "DeferWindowPos failed\n"); > + hdwp = hnext; > + } > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + if (i != IDX_FAIL) > + ExpectY(hChildren[i], posY); > + } > +} > + > +static void TestDestroyDeferWindowPos(int posY) > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HWND h = hChildren[i]; > + hdwp = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + ok(hdwp != NULL, "DeferWindowPos failed\n"); > + /* Destroying a window after DeferWindowPos but before EndDeferWindowPos should be silently ignored */ > + if (i == IDX_FAIL) > + DestroyWindow(h); > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + if (i != IDX_FAIL) > + ExpectY(hChildren[i], posY); > + } > +} > + > +static LRESULT CALLBACK TestWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) > +{ > + switch (msg) > + { > + case WM_CREATE: > + { > + int i; > + int posY = 0; > + for (i=0; i < NCHILDREN; ++i) > + { > + hChildren[i] = CreateWindowExA(0, "Button", NULL, WS_CHILD|WS_VISIBLE, > + i*WIDTH_CHILDREN, posY, WIDTH_CHILDREN, WIDTH_CHILDREN, > + hWnd, NULL, g_hInstance, NULL); > + } > + > + TestDeferWindowPos(++posY); > + TestBogusDeferWindowPos(++posY); > + TestDestroyDeferWindowPos(++posY); If possible you should move those calls outside of the TestWndProc. > + } > + break; > + } > + return DefWindowProcA(hWnd, msg, wParam, lParam); > +} > + > +START_TEST(defer) > +{ > + WNDCLASSEXA cls; > + ATOM acls; > + > + g_hInstance = GetModuleHandleA(NULL); > + memset(&cls, 0, sizeof(cls)); > + cls.cbSize = sizeof(cls); > + cls.lpfnWndProc = TestWndProc; > + cls.hInstance = g_hInstance; > + cls.lpszClassName = "TestWnd"; > + > + acls = RegisterClassExA(&cls); > + > + HWND hWnd = CreateWindowExA(0, MAKEINTRESOURCEA(acls), "TestWnd", WS_OVERLAPPEDWINDOW, You can't declare a variable in the middle of a function (should give you a warning while compiling). > + CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > + NULL, NULL, g_hInstance, NULL); > + ok(hWnd != NULL, "CreateWindowEx failed\n"); > +} > diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c > index f92a3dc..7cb3a4f 100644 > --- a/dlls/user32/winpos.c > +++ b/dlls/user32/winpos.c > @@ -2349,6 +2349,11 @@ HDWP WINAPI DeferWindowPos( HDWP hdwp, HWND hwnd, HWND hwndAfter, > > hwnd = WIN_GetFullHandle( hwnd ); > if (is_desktop_window( hwnd )) return 0; > + if (!IsWindow( hwnd )) > + { > + SetLastError( ERROR_INVALID_WINDOW_HANDLE ); > + return 0; > + } > > if (!(pDWP = get_user_handle_ptr( hdwp, USER_DWP ))) return 0; > if (pDWP == OBJ_OTHER_PROCESS) > @@ -2418,7 +2423,6 @@ BOOL WINAPI EndDeferWindowPos( HDWP hdwp ) > { > DWP *pDWP; > WINDOWPOS *winpos; > - BOOL res = TRUE; > int i; > > TRACE("%p\n", hdwp); > @@ -2430,20 +2434,20 @@ BOOL WINAPI EndDeferWindowPos( HDWP hdwp ) > return FALSE; > } > > - for (i = 0, winpos = pDWP->winPos; res && i < pDWP->actualCount; i++, winpos++) > + for (i = 0, winpos = pDWP->winPos; i < pDWP->actualCount; i++, winpos++) > { > TRACE("hwnd %p, after %p, %d,%d (%dx%d), flags %08x\n", > winpos->hwnd, winpos->hwndInsertAfter, winpos->x, winpos->y, > winpos->cx, winpos->cy, winpos->flags); > > if (WIN_IsCurrentThread( winpos->hwnd )) > - res = USER_SetWindowPos( winpos ); > + USER_SetWindowPos( winpos ); > else > - res = SendMessageW( winpos->hwnd, WM_WINE_SETWINDOWPOS, 0, (LPARAM)winpos ); > + SendMessageW( winpos->hwnd, WM_WINE_SETWINDOWPOS, 0, (LPARAM)winpos ); > } > HeapFree( GetProcessHeap(), 0, pDWP->winPos ); > HeapFree( GetProcessHeap(), 0, pDWP ); > - return res; > + return TRUE; > }

2 1

comdlg32: itemdlg split button implementation
by Vincent Povirk Aug. 25, 2015

Aug. 25, 2015

These patches apply on top of my series that implements the open dropdown menu in the common item dialog, based on BS_SPLITBUTTON. They work in my testing on Windows, but they do not yet work on Wine because BS_SPLITBUTTON is unimplemented. This is mostly to show how to do this properly (and hopefully make the case that the deficiency won't hinder development in the mean time), but if I'm not around when BS_SPLITBUTTON is implemented, I consider this a contribution to Wine under the LGPL just like anything I send to wine-patches. I'm interested in feedback in terms of whether this is as correct and clean as it could be, but it's sort of academic until Wine has the necessary architecture to support it.

1 0

Re: [3/3] ddraw: Implement DDENUMSURFACES_CANBECREATED flag in ddraw7_EnumSurfaces.
by Stefan Dösinger Aug. 25, 2015

Aug. 25, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-25 um 11:17 schrieb Sebastian Lackner: > + if (match_flags != DDENUMSURFACES_MATCH) > + return DDERR_INVALIDPARAMS; Personally I prefer if the code writes WARN messages if it returns an error. > + memcpy(&testdesc, DDSD, sizeof(testdesc)); Technically you should honor DDSD.dwSize. Most likely the correct behavior is to return an error if the size doesn't match sizeof(DDSURFACEDESC) in IDirectDraw and IDirectDraw2 or sizeof(DDSURFACEDESC2) in IDirectDraw4 and 7. > + if (!(testdesc.dwFlags & DDSD_WIDTH)) > + { > + testdesc.dwFlags |= DDSD_WIDTH; > + testdesc.dwWidth = 512; > + } > + if (!(testdesc.dwFlags & DDSD_HEIGHT)) > + { > + testdesc.dwFlags |= DDSD_HEIGHT; > + testdesc.dwHeight = 512; > + } Does it inject any caps or pixelformat if they aren't set? Does it fall back to DDSCAPS_SYSTEMMEMORY if you don't request a location and whatever pixel format or size you request isn't supported? > + hr = IDirectDraw7_CreateSurface(iface, &testdesc, &surface, NULL); > + if (SUCCEEDED(hr)) > { > ... > + surf = unsafe_impl_from_IDirectDrawSurface7(surface); > + Callback(NULL, &surf->surface_desc, Context); > + IDirectDrawSurface7_Release(surface); > } > + else > + ERR("Failed to create surface, hr %#x.\n", hr); I don't think that's an ERR. It may be a legitimate case where the surface requested by the application isn't supported. A question that should be answered by the tests is if EnumSurfaces just enumerates 0 descs with success, or if it returns a failure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3NFlAAoJEN0/YqbEcdMwRm0P/jajJLkLdEd4gjVCm/siaccO UmNvomXKOhkrh9kLI7LWZQ2B4fvuc5pma0K6klngRhaoa3+ZIAC59q9eTGzQieWB ibE9LXRU9FHFNThjprkGyHZtYu0MHRTTrYfgsRtOVhpfBTkxPYtKPsxJqEDqi9ug xyRNzuRxz+bsG+4DFocwKXHQtbq/dXndHC5i2VyWh3uUX7HI1QJ1klIbaNf8kBGn w+Hm09qzWU0uudNKNRUTqvulUgd/OPn133h1/IkB27OhdDe0jexVl5hFc+7fyQFG dZ6kdQEimJ1jz9eRIItfOWLYvOKC0J3x7H8kQnQeoeDNJVnoK0rYS5mAz+p4gWLY 3eeuhKeq2iQ1P6851x9KnywZ/wEwSabg6ZqgCrQUCVdIVQNb+s6b5e5BEip/C3BG oSXgO/7ONj682c3S0GoiYFx6eMUPPGS7xbMqhHDJqfQneUEGUXU8VGgT+snTxsS/ JJ0NzQOlmwZm0wx7zCPwjs9173Vz25tCMuAm18CvkRLoXygZeUzU7PbfXE2qqO6j iNsfkUCP7rA+XhCV/vMFdzThI8j0YEDFPliZumQCJ5qN/Yz/6dhls+3J0IHMZexa iGjHFsTlI/yXc01+865tZZQaFEFZEJ0rfE7RChMFsY9LTGe2bzc6P49gdjuhm1em zLhWBw58Jqx2LoY/wAFR =1rMk -----END PGP SIGNATURE-----

1 0

Re: [1/3] ddraw/tests: Add more tests for IDirectDraw7::EnumSurfaces.
by Stefan Dösinger Aug. 25, 2015

Aug. 25, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-25 um 11:15 schrieb Sebastian Lackner: > dlls/ddraw/ddraw.c | 3 > dlls/ddraw/tests/d3d.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++--- Please add the test to ddraw{1-7}.c, testing each interface version. This is the preferred place for new tests. Feel free to remove the lone EnumSurfaces test from CreateDirect3D. Arguably it's poorly placed there because CreateDirect3D is more of a helper function than a real test function. > +typedef struct > +{ > + int found; > + int surfaces; > +} EnumSurfaceTest; You shouldn't need the typedef, and the counters can be unsigned. In ddraw*.c enum_surfaces_test matches the naming convention. > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 256; > + ddsd2.dwHeight = 256; The test will be more meaningful if there are more than 2 surfaces that can be enumerated, and if they have different sizes. > + count.found = count.surfaces = 0; > + rc = IDirectDraw7_EnumSurfaces(lpDD, DDENUMSURFACES_CANBECREATED | DDENUMSURFACES_MATCH, > + &ddsd, &count, SurfaceCounter); > + ok(rc == DD_OK, "Expected DD_OK, got %x\n", rc); > + todo_wine ok(count.found == 1, "Has %d surface descriptions, expected 1\n", count.found); > + ok(count.surfaces == 0, "Has %d surfaces, expected 0\n", count.surfaces); What does the enumerated surface description look like? Is it just your input description, or does ddraw set additional flags like DDSCAPS_OFFSCREENPLAIN? If it looks like it is your surface desc you can try to set some nonsense fields before the call, e.g. set lpSurface = (void *)0xdeadbeef without setting DDSD_LPSURFACE. If ddraw adds extra flags please check for them. If you call CreateSurface inside the callback with the enumerated desc, does it successfully create a surface? Another thing to test is DDSCAPS_PRIMARYSURFACE, both without an existing primary and without one that's already created. This should show if calling CreateSurface to try to create a test surface is the right solution. There are a few more things you could check to satisfy my curiosity, but I don't think we necessarily need this: In your implementation calling EnumSurfaces with DDENUMSURFACES_ALL | DDENUMSURFACES_DOESEXIST from the enumeration callback will find the temporary surface and you could e.g. AddRef it and keep it. I doubt this is the case with Microsoft's implementation, otherwise they could give you their test surface in the callback. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3M6jAAoJEN0/YqbEcdMw4BcP/Rc/D6f3d2KoEG9mqftIxsGO TaO7KAeclV2ctUUYCXQ9kuUamDblNtyFebhb6p/zr7i1I9dymiN1EMgpUs7DUU2Y IJB3QJVvG1csFporvAkqNm1ERN12YbNPcmCL7nSuT8/X0uP3c4Mcjr2MQphz6Ng5 CyZPp5fKah7xrQrfEqQ7FGTpuXPickkTm710JerjZr4UNP+LrW38WTMxgH3a/McW ucuvRF+D2qc/Ml+fbHMBrO0gUlmLCKWvyPAAM5LU9b4lpMSBvVM0avbDP1BfV68e W18pj3ZBjGsbPCIGQWV4YqyiEtdQgvJPYvmbLTwSWxfOn1hXDdqgzOX6xtuGw93G jVu7D8FZduLDwlG8k3KWWZVQKZ6Cd0RuaGUOztNXXkFIzyH57MWGaJOsAr7RVB1T 81JANe7pq4wcs6eA2yJo7vEoGqdR13waV13Em44aR7sp8hNZod05vlAlS//zViNU 0zkisY70ceaQNug22BlyFxdJ67mLHxNduseQ2oAZLQj3c/W2kpu9sAG09bJTaj3p FfgW1+oCq4bIt2lkdTewuPHcIylhvBc46EGpSmU6Tq4Rip4MmVZEsK8bFXQyZUrL Dn+oGMdOwTPIvv1bKIx36SXGqr3Q7wV4k8Ai10eHVjygWj1cnX5BSBH3zf2ZRSa5 A4YR+nFRZkEdr8rvO37C =jk68 -----END PGP SIGNATURE-----

1 0

Re: wevtapi: implement EvtClose()
by Nikolay Sivov Aug. 25, 2015

Aug. 25, 2015

On 25.08.2015 21:20, Austin English wrote: > +BOOL WINAPI EvtClose(EVT_HANDLE handle) > +{ > + BOOL ret; > + > + TRACE("(%p)\n", handle); > + ret = HeapFree(GetProcessHeap(), 0, handle); > + return ret; > +} It makes no sense to free it like that.

1 0

Re: mscoree: Implement semi-stub for _CorValidateImage.
by Vincent Povirk Aug. 25, 2015

Aug. 25, 2015

Why do we set the entry point to 0 on 64-bit and _CorDllMain or _CorExeMain on 32-bit?

2 1

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Nikolay Sivov Aug. 25, 2015

Aug. 25, 2015

On 25.08.2015 17:01, Rodrigo Rivas wrote: > [Sorry for the double post, I forgot to reply to the list] > > On Tue, Aug 25, 2015 at 3:35 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> On 25.08.2015 16:08, Rodrigo Rivas wrote: >>> >>> I sent this on July 15th, but it went through the cracks. Maybe the >>> mail text was not detailed enough, so I will try and explain it better >>> this time. >>> >>> The error behaviour of functions BeginDeferWindowPos(), >>> DeferWindowPos() and EndDeferWindowPos() in Wine is different than in >>> Windows. >>> >>> In Windows, when DeferWindowPos() is used with an invalid HWND, this >>> function fails, but the eventual EndDeferWindowPos() will succeed and >>> move all the other windows in the set. >>> In Wine, however, DeferWindowPos() does not check the HWND, so it >>> never fails. But then, it fails in EndDeferWindowPos(), moving only >>> the windows passed before the invalid HWND and leaving the windows >>> after the invalid HWND unmoved. >>> >>> The Windows behaviour is consistent in every version I tested (XP and 7). >>> >>> The attached patch makes the Wine error behaviour the same as the Windows >>> one. >>> It also considers the case where the HWND is valid when calling >>> DeferWindowPos() but is destroyed before calling EndDeferWindowPos(): >>> The error is simply ignored. >>> >>> It fixes bug #23187. >>> >>> --- >>> dlls/user32/tests/Makefile.in | 1 + >>> dlls/user32/tests/defer.c | 168 >>> ++++++++++++++++++++++++++++++++++++++++++ >>> dlls/user32/winpos.c | 14 ++-- >>> 3 files changed, 178 insertions(+), 5 deletions(-) >>> create mode 100644 dlls/user32/tests/defer.c >>> >> >> I don't think you need a new file for that, how about moving this to win.c? > > It may make sense in win.c. I assumed that user32/tests/win.c is > related to user32/win.c. And since the affected functions are in > user32/winpos.c... maybe I should have named it user32/tests/winpos.c? > But I don't have a strong preference > If you really want it, would you like me to do the merge and resend > the patch? Or is it not necessary? > We try to avoid adding new files for every new test, to keep number of files under reasonable limit. So yes, I think it's better to have that moved to win.c, and no, renaming it is not necessary. >> Regarding fix itself, it's probably better to split it to two - fix >> DeferWindowPos() in first + related tests, and End* one in the second. > > In this I disagree. Changing DeferWindowPos() without changing > EndDeferWindowPos() would make little sense, because the error > checking is moving from EDWP to DWP. > The special case of the window being destroyed between DWP and EDWP is > just a consequence of EDWP not having any error checking left. > You could have one patch that adds the check to DWP and another that > removes it from EDWP, but what's the point? The intermediate step will > not even pass the test case, it will fail at > TestDestroyDeferWindowPos(). > > So to fair you would have to split in: a) fix DWP + tess1+test2; b) > fix EDWP + test3. > Sure, that's what I meant, to have one fix + its tests in first patch, followed by second fix + its own tests. But let's see if someone else has anything to add to this, it might be okay to have it they way you did.

1 0

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Nikolay Sivov Aug. 25, 2015

Aug. 25, 2015

On 25.08.2015 16:08, Rodrigo Rivas wrote: > I sent this on July 15th, but it went through the cracks. Maybe the > mail text was not detailed enough, so I will try and explain it better > this time. > > The error behaviour of functions BeginDeferWindowPos(), > DeferWindowPos() and EndDeferWindowPos() in Wine is different than in > Windows. > > In Windows, when DeferWindowPos() is used with an invalid HWND, this > function fails, but the eventual EndDeferWindowPos() will succeed and > move all the other windows in the set. > In Wine, however, DeferWindowPos() does not check the HWND, so it > never fails. But then, it fails in EndDeferWindowPos(), moving only > the windows passed before the invalid HWND and leaving the windows > after the invalid HWND unmoved. > > The Windows behaviour is consistent in every version I tested (XP and 7). > > The attached patch makes the Wine error behaviour the same as the Windows one. > It also considers the case where the HWND is valid when calling > DeferWindowPos() but is destroyed before calling EndDeferWindowPos(): > The error is simply ignored. > > It fixes bug #23187. > > --- > dlls/user32/tests/Makefile.in | 1 + > dlls/user32/tests/defer.c | 168 ++++++++++++++++++++++++++++++++++++++++++ > dlls/user32/winpos.c | 14 ++-- > 3 files changed, 178 insertions(+), 5 deletions(-) > create mode 100644 dlls/user32/tests/defer.c > I don't think you need a new file for that, how about moving this to win.c? Regarding fix itself, it's probably better to split it to two - fix DeferWindowPos() in first + related tests, and End* one in the second.

1 0

Re: [PATCH 4/6] d3drm: Fix spelling mistake in Set/GetDecalTransparentColor macros.
by Stefan Dösinger Aug. 25, 2015

Aug. 25, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I noticed that Microsoft's headers don't define these C interface macros at all. Technically we should remove them from our headers (and write obj->lpVtbl->Method(obj, param1, param2) in the code). However, given that it's quite unlikely that anyone wants to compile a d3drm application against our headers I don't think this needs to be a priorit y. This also means our tests (and implementation) won't compile against Microsoft's headers, but this is also something that is nice to have but not generally supported (e.g. Microsoft's d3d9ex C interfaces are broken, so our d3d9ex tests only compile with our header). Stefan Am 2015-08-24 um 15:58 schrieb Aaryaman Vasishta: > --- include/d3drmobj.h | 12 ++++++------ 1 file changed, 6 > insertions(+), 6 deletions(-) > > diff --git a/include/d3drmobj.h b/include/d3drmobj.h index > 942c69a..28340fb 100644 --- a/include/d3drmobj.h +++ > b/include/d3drmobj.h @@ -3284,7 +3284,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture, IDirect3DRMVisual) #define > IDirect3DRMTexture_SetDecalOrigin(p,a,b) (p)->SetDecalOrigin(a,b) > #define IDirect3DRMTexture_SetDecalScale(p,a) (p)->SetDecalScale(a) > #define IDirect3DRMTexture_SetDecalTransparency(p,a) > (p)->SetDecalTransparency(a) -#define > IDirect3DRMTexture_SetDecalTransparencyColor(p,a) > (p)->SetDecalTransparentColor(a) +#define > IDirect3DRMTexture_SetDecalTransparentColor(p,a) > (p)->SetDecalTransparentColor(a) #define > IDirect3DRMTexture_GetDecalSize(p,a,b) (p)->GetDecalSize(a,b) > #define IDirect3DRMTexture_GetDecalOrigin(p,a,b) > (p)->GetDecalOrigin(a,b) #define IDirect3DRMTexture_GetImage(p) > (p)->GetImage() @@ -3292,7 +3292,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture, IDirect3DRMVisual) #define > IDirect3DRMTexture_GetColors(p) (p)->GetColors() #define > IDirect3DRMTexture_GetDecalScale(p) (p)->GetDecalScale() #define > IDirect3DRMTexture_GetDecalTransparency(p) > (p)->GetDecalTransparency() -#define > IDirect3DRMTexture_GetDecalTransparencyColor(p) > (p)->GetDecalTransparencyColor() +#define > IDirect3DRMTexture_GetDecalTransparentColor(p) > (p)->GetDecalTransparentColor() #endif > > /********************************************************************* ******** > > > @@ -3404,7 +3404,7 @@ DECLARE_INTERFACE_(IDirect3DRMTexture2, IDirect3DRMTexture) > #define IDirect3DRMTexture2_SetDecalOrigin(p,a,b) > (p)->SetDecalOrigin(a,b) #define > IDirect3DRMTexture2_SetDecalScale(p,a) (p)->SetDecalScale(a) > #define IDirect3DRMTexture2_SetDecalTransparency(p,a) > (p)->SetDecalTransparency(a) -#define > IDirect3DRMTexture2_SetDecalTransparencyColor(p,a) > (p)->SetDecalTransparentColor(a) +#define > IDirect3DRMTexture2_SetDecalTransparentColor(p,a) > (p)->SetDecalTransparentColor(a) #define > IDirect3DRMTexture2_GetDecalSize(p,a,b) (p)->GetDecalSize(a,b) > #define IDirect3DRMTexture2_GetDecalOrigin(p,a,b) > (p)->GetDecalOrigin(a,b) #define IDirect3DRMTexture2_GetImage(p) > (p)->GetImage() @@ -3412,7 +3412,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture2, IDirect3DRMTexture) > #define IDirect3DRMTexture2_GetColors(p) (p)->GetColors() #define > IDirect3DRMTexture2_GetDecalScale(p) (p)->GetDecalScale() #define > IDirect3DRMTexture2_GetDecalTransparency(p) > (p)->GetDecalTransparency() -#define > IDirect3DRMTexture2_GetDecalTransparencyColor(p) > (p)->GetDecalTransparencyColor() +#define > IDirect3DRMTexture2_GetDecalTransparentColor(p) > (p)->GetDecalTransparentColor() /*** IDirect3DRMTexture2 methods > ***/ #define IDirect3DRMTexture2_InitFromImage(p,a) > (p)->InitFromImage(a) #define > IDirect3DRMTexture2_InitFromResource2(p,a,b,c) > (p)->InitFromResource2(a,b,c) @@ -3494,7 +3494,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture3, IDirect3DRMVisual) #define > IDirect3DRMTexture3_SetDecalOrigin(p,a,b) > (p)->lpVtbl->SetDecalOrigin(p,a,b) #define > IDirect3DRMTexture3_SetDecalScale(p,a) > (p)->lpVtbl->SetDecalScale(p,a) #define > IDirect3DRMTexture3_SetDecalTransparency(p,a) > (p)->lpVtbl->SetDecalTransparency(p,a) -#define > IDirect3DRMTexture3_SetDecalTransparencyColor(p,a) > (p)->lpVtbl->SetDecalTransparentColor(p,a) +#define > IDirect3DRMTexture3_SetDecalTransparentColor(p,a) > (p)->lpVtbl->SetDecalTransparentColor(p,a) #define > IDirect3DRMTexture3_GetDecalSize(p,a,b) > (p)->lpVtbl->GetDecalSize(p,a,b) #define > IDirect3DRMTexture3_GetDecalOrigin(p,a,b) > (p)->lpVtbl->GetDecalOrigin(p,a,b) #define > IDirect3DRMTexture3_GetImage(p) (p)->lpVtbl->GetImage(p) @@ -3502,7 > +3502,7 @@ DECLARE_INTERFACE_(IDirect3DRMTexture3, > IDirect3DRMVisual) #define IDirect3DRMTexture3_GetColors(p) > (p)->lpVtbl->GetColors(p) #define > IDirect3DRMTexture3_GetDecalScale(p) (p)->lpVtbl->GetDecalScale(p) > #define IDirect3DRMTexture3_GetDecalTransparency(p) > (p)->lpVtbl->GetDecalTransparency(p) -#define > IDirect3DRMTexture3_GetDecalTransparencyColor(p) > (p)->lpVtbl->GetDecalTransparencyColor(p) +#define > IDirect3DRMTexture3_GetDecalTransparentColor(p) > (p)->lpVtbl->GetDecalTransparentColor(p) #define > IDirect3DRMTexture3_InitFromImage(p,a) > (p)->lpVtbl->InitFromImage(p,a) #define > IDirect3DRMTexture3_InitFromResource2(p,a,b,c) > (p)->lpVtbl->InitFromResource2(p,a,b,c) #define > IDirect3DRMTexture3_GenerateMIPMap(p,a) > (p)->lpVtbl->GenerateMIPMap(p,a) > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3EhqAAoJEN0/YqbEcdMw2R8QAJMTA2LoM42LSV4mZUNH1oe/ TrErVK3o2VRiRlBlQL1CLrv6178p01GmIoRmlkXyYgrvmM7Z7mGIEFfhD7g4irVr Cw1M6WnrTFyWgu0DfOw6qaYqknjLcGJTukQ97R1nd8wgQ0/dfDVmB8SWl7V6KWO9 F0UyY3P05B20hbeKhUouoxfhdEO0pkVDgvFffe9A5+01uP/uTzFFYWVhacmoY9nl VYhyDFhCM+Fut/I8RhDzZfRA+VmvxRBTQyEdlH93GMhov4Tf50bSdu41pd3WZL6g bf2WW/vIAhwsIpoSe6GUPEkqjq9hc4a5TXVyUZhStergGeEiy3USuSbXSRRbLc+w yu/jLr/BLm/nVOicP/BmWVspEt1z9ksjfcVYdXgpQEoeS7NLn0gyihLn7lnbl2dv pSVgfVLUMsWcO0IzlTruARHEelEZV9DFKnLkQpe1U1nKqw27M9J7L+bE5euWHj9L ZSXjip4Yf9wSENVNqyeZK9I+kXpOs1i3TVquY9tvFgwjoXtj+F3ZyGCETRFXcPti dCX0xmIl9M1jwxdJn9rSlVr8w0ZSuYZHGjsxGBZDFWPVMDUNql5HTD5Tbe47iTXg 8ZiB6qzrcuTdXS4DaQjVvKVmiv0lqvrKPaKWg7u2Q5wBlUr0ITXSfq5vam4uMHIf C36Co9yOt+tapC7y73gU =1Eea -----END PGP SIGNATURE-----

2 1

Re: [PATCH 5/5] d3d11: Add ID3D11Texture2D stub interface.
by Henri Verbeet Aug. 24, 2015

Aug. 24, 2015

On 24 August 2015 at 01:04, Józef Kucia <jkucia(a)codeweavers.com> wrote: > struct d3d10_texture2d > { > ID3D10Texture2D ID3D10Texture2D_iface; > + ID3D11Texture2D ID3D11Texture2D_iface; We usually put the newest interface version first. > +static HRESULT texture2d_query_interface(struct d3d10_texture2d *texture, REFIID riid, void **object) > { > - struct d3d10_texture2d *This = impl_from_ID3D10Texture2D(iface); > - > - TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); > - > if (IsEqualGUID(riid, &IID_ID3D10Texture2D) > || IsEqualGUID(riid, &IID_ID3D10Resource) > || IsEqualGUID(riid, &IID_ID3D10DeviceChild) > || IsEqualGUID(riid, &IID_IUnknown)) > { > - IUnknown_AddRef(iface); > - *object = iface; > + *object = &texture->ID3D10Texture2D_iface; > + IUnknown_AddRef((IUnknown *)*object); > + return S_OK; > + } > + else if (IsEqualGUID(riid, &IID_ID3D11Texture2D) > + || IsEqualGUID(riid, &IID_ID3D11Resource) > + || IsEqualGUID(riid, &IID_ID3D11DeviceChild)) > + { > + *object = &texture->ID3D11Texture2D_iface; > + IUnknown_AddRef((IUnknown *)*object); > return S_OK; > } > Here too. > +static HRESULT STDMETHODCALLTYPE d3d10_texture2d_QueryInterface(ID3D10Texture2D *iface, REFIID riid, void **object) > +{ > + struct d3d10_texture2d *This = impl_from_ID3D10Texture2D(iface); > + > + TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); > + > + return texture2d_query_interface(This, riid, object); > +} There's something to say for this approach, but what we usually do is to just forward to the newest interface version (where possible, practical, etc.) I.e. "return d3d11_texture2d_queryInterface(&texture->ID3D11Texture2d_iface, iid, out);". > +HRESULT STDMETHODCALLTYPE d3d11_texture2d_QueryInterface(ID3D11Texture2D *iface, REFIID riid, void **object) These should be static.

1 0

IDirect3DRMTexture stub patches.
by Aaryaman Vasishta Aug. 24, 2015

Aug. 24, 2015

These patches will be needed before I can add tests for, and implement version 1 of Create/LoadTexture. Please provide feedback on any modifications required. (Patches 0000-0006 are already in wine-patches but not committed yet). Cheers, Jam

2 2

Re: [PATCH] ucrtbase: Add the new universal CRT DLL.
by Alexandre Julliard Aug. 24, 2015

Aug. 24, 2015

Martin Storsjo <martin(a)martin.st> writes: > +@ stub -arch=win32 ?_set_new_handler@@YAP6AHI(a)ZH@Z # int(__cdecl*__cdecl _set_new_handler(int))(unsigned int) > +@ stub -arch=win64 ?_set_new_handler@@YAP6AH_K(a)ZH@Z # int(__cdecl*__cdecl _set_new_handler(int))(unsigned __int64) > +@ stub _set_new_mode > +@ cdecl _set_printf_count_output(long) MSVCRT__set_printf_count_output > +@ cdecl _set_purecall_handler(ptr) > +@ stub -arch=win32 ?_set_se_translator@@YAP6AXIPAU_EXCEPTION_POINTERS@@@ZH(a)Z # void(__cdecl*__cdecl _set_se_translator(int))(unsigned int,struct _EXCEPTION_POINTERS *) > +@ stub -arch=win64 ?_set_se_translator@@YAP6AXIPEAU_EXCEPTION_POINTERS@@@ZH(a)Z # void(__cdecl*__cdecl _set_se_translator(int))(unsigned int,struct _EXCEPTION_POINTERS * __ptr64) I don't see any mangled names in my version. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winhttp: Add support for WinHttpRequestOption_URLCodePage.
by Hans Leidekker Aug. 24, 2015

Aug. 24, 2015

On Mon, 2015-08-24 at 15:03 +0800, Dmitry Timoshkov wrote: > @@ -3071,6 +3072,7 @@ static void initialize_request( struct winhttp_request *request ) > request->connect_timeout = 60000; > request->send_timeout = 30000; > request->receive_timeout = 30000; > + request->url_codepage = CP_ACP; MSDN says that it defaults to CP_UTF8 and my tests confirm that.

1 0

Re: ieframe: Added more test traces to diagnose some test failures.
by Marvin Aug. 23, 2015

Aug. 23, 2015

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=16243 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE

1 0

Re: [3/4] ntdll/tests: Add additional tests for calling NtOpenFile with file object as RootDirectory.
by Marvin Aug. 23, 2015

Aug. 23, 2015

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=16238 Your paranoid android. === w8 (32 bit file) === file.c:410: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: gdi32/tests: 64 bit GetFontFileInfo may fail with error ERROR_NOACCESS.
by Marvin Aug. 22, 2015

Aug. 22, 2015

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=16214 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Re: different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung Aug. 22, 2015

Aug. 22, 2015

------------------------------ On Sat, Aug 22, 2015 5:07 PM BST Vincent Povirk wrote: >> Is it possible to enable win32 mono's mixed mode support at runtime, >> or does it requires a re-compile? > >I'm not sure, but I think there is a switch to mono.exe. > Hmm, I just read the linux mono man pages... don't know where the win32-specfic features of mono might be documented. I'll try to find out. >> The two ldarg.s look invalid to me, but it is possible that Cecil is getting >> confused in the same way as mono. > >The solution is probably to modify the JIT compiler in wine-mono to >accept this code. If you feel like looking into this issue, the application concerned is Microsoft's font validator: https://www.microsoft.com/typography/FontValidator.mspx The LTSH and hdmx, vdmx table tests and the rasterization test (on a different tab) throws illegal IL code exception captured in its report. You can de-select the other tests which don't matter. To use, click "add font" under the options, load up any truetype font, and click the 'tick" symbol to start. The XML viewer doesn't work under wine - COM/ActiveX and IE - so you probably want to save the report and read it as text. The exceptions are thrown in the truetype.dll as: Invalid IL code in Avalon.Media.Text.TrueType.RasterInterf:CalcDevMetrics (int,int,int,uint16,byte[],uint16,byte,byte,uint16[],uint16[],uint16,Avalon.Media.Text.TrueType.RasterInterf/UpdateProgressDelegate): IL_039a: ldarg.s Invalid IL code in Avalon.Media.Text.TrueType.RasterInterf:RastTest (int,int,int[],single,single,single,single,single[2],Avalon.Media.Text.TrueType.RasterInterf/RastTestErrorDelegate,Avalon.Media.Text.TrueType.RasterInterf/UpdateProgressDelegate): IL_0098: ldarg.s if you don't even want to run it :-). As I said it works correctly under wine + .net 2, and throws the "correct" error under linux mono and win32 mono about not being able to initialize the constructor of an object around native code, so both behaviors are "expected". I have a command-line wrapper around the Font Validator to make batch testing easier, though I don't expect it is of any use for looking at the IL code issue?

1 2

Re: [3/3] ntdll: Implement FileRenameInformation support. (try 2)
by Marvin Aug. 22, 2015

Aug. 22, 2015

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=16212 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung Aug. 22, 2015

Aug. 22, 2015

------------------------------ On Fri, Aug 21, 2015 8:20 PM BST Vincent Povirk wrote: >> So I have a specific question - how do I go about finding >> out how the IL code exception comes about? >> (I have had a couple of patches in either camp so >> I am not against patching wine or mono, or wine-mono for that matter) > >You can set the WINE_MONO_VERBOSE environment variable to a single >digit greater than 0 to get debugging information related to JIT >compilation. This should at least tell you exactly which method's IL >is being rejected. > Actually I don't need that - the applicatin itself records the stack trace in its normal xml output as: Invalid IL code in method1 (int,int,int,uint16,byte[],uint16,byte,byte,uint16[],uint16[],uint16, delegate type1): IL_039a: ldarg.s 12

 and Invalid IL code in method2 (int,int,int[],single,single,single,single,single[2],delegate type1, delegate2): IL_0098: ldarg.s 8

 The first one is doing "ldarg.s <the delegate>", while the other is doing "ldarg.s <the single[2]>". I just noticed one anomaly - the single[2] type should be a single[,] type; These are according to monodevelop's assembly browser. >Setting MONO_VERBOSE_METHOD will show debugging information for the >JIT compilation of a specific method, unfortunately Mono crashes >trying to parse many of the mangled names that appear in Managed C++ >assemblies, so often this approach does not work for me. I've often >had to hack the code that checks MONO_VERBOSE_METHOD to special-case a >specific method name. > monodis somehow doesn't show either of those. >> And a general question: are mixed mode assemblies supposed >> to work under win32 mono at all, or wine-mono definitely needed? >> I saw some wine + mono discussions a while ago and >> I got the impression that mixed mode assemblies are supposed to >> work with win32 mono somewhat? > >There is some support for mixed-mode in win32 mono, but it is disabled >by default. They are different enough that I would not use win32 mono >on Windows to learn anything about how well wine-mono "should" work. > Is it possible to enable win32 mono's mixed mode support at runtime, or does it requires a re-compile? >> The application itself is available as a public download in binary form. >> But since it mostly works - correctly under .net, and even the >> illegal IL exception was caught, just not the null constructor. >> Editing the IL code to put a try+catch around the constructor >> makes it largely operational too under linux mono, so there is >> not much of a bug to file; mostly a curiosity why >> wine-mono doesn't behave like it support mixed-mode fully, or >> not at all, but something between. > >Microsoft's managed C++ compiler has been known to generate IL that >technically violates ecma 335, or otherwise gives Mono trouble. We >have hacks in wine-mono for a few of these cases, but it's likely we >have not addressed all of them. > >There are also features used by managed C++, such as "thiscall" >reverse-pinvokes, which are technically independent of mixed-mode, but >which are not implemented in wine-mono. The two ldarg.s look invalid to me, but it is possible that Cecil is getting confused in the same way as mono.

2 1

Re: [2/4] ntdll/tests: Add additional tests for FileRenameInformation.
by Marvin Aug. 21, 2015

Aug. 21, 2015

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=16200 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung Aug. 21, 2015

Aug. 21, 2015

Hi, I am trying to look into a somewhat curious issue about mixed mode assembly under wine-mono. The application works correctly under wine + MS .net 2. With native mono on the explicit command line, either win32 mono + wine, or x86_64 linux mono on x86_64 linux, the win32 native constructor of a class returns a null. That's fair enough. But with wine-mono, the application does not behave either like .net 2 or win32 mono on the command line. It throws illegal IL code exception. So I have a specific question - how do I go about finding out how the IL code exception comes about? (I have had a couple of patches in either camp so I am not against patching wine or mono, or wine-mono for that matter) And a general question: are mixed mode assemblies supposed to work under win32 mono at all, or wine-mono definitely needed? I saw some wine + mono discussions a while ago and I got the impression that mixed mode assemblies are supposed to work with win32 mono somewhat? The application itself is available as a public download in binary form. But since it mostly works - correctly under .net, and even the illegal IL exception was caught, just not the null constructor. Editing the IL code to put a try+catch around the constructor makes it largely operational too under linux mono, so there is not much of a bug to file; mostly a curiosity why wine-mono doesn't behave like it support mixed-mode fully, or not at all, but something between. Hin-Tak

2 1

Re: [PATCH 7/7] d3d11/tests: Add test for device interfaces.
by Marvin Aug. 21, 2015

Aug. 21, 2015

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=16187 Your paranoid android. === wvistau64 (32 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 00401721 === w2008s64 (32 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 00401721 === wvistau64 (64 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 000000000040168C === w2008s64 (64 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 000000000040168C

1 0

Re: [PATCH 2/3] xaudio2: Add stub IXAudio2MasteringVoice implementation
by Henri Verbeet Aug. 21, 2015

Aug. 21, 2015

On 20 August 2015 at 22:06, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > +struct IXAudio2MasteringVoiceVtbl XAudio2MasteringVoice_Vtbl = { Should that have been "static const"?

2 1

Re: [PATCH 2/3] xaudio2: Implement IXAudio2::GetDeviceDetails
by Marvin Aug. 21, 2015

Aug. 21, 2015

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

1 0

Re: [PATCH] po: Update Finnish translation.
by Nikolay Sivov Aug. 21, 2015

Aug. 21, 2015

On 21.08.2015 16:02, Lauri Kenttä wrote: > #: uninstaller.rc:33 > -#, fuzzy > -#| msgid "Error: Invalid option '%c'.\n" > msgid "uninstaller: Invalid option [%1]\n" > -msgstr "Virhe: Viallinen vaihtoehto '%c'.\n" > +msgstr "unistaller: Virheellinen valitsin [%1]\n" Hi, Lauri. Is this a typo in "uninstaller" ?

1 0