- wine-devel - winehq.org

Re: [PATCH 1/4] d3dx9/tests: Add test for GetPassDesc() function.
by Marvin 03 May '17

03 May '17

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=30753 Your paranoid android. === build (build) === Make failed

1 0

Wine native fps overlay
by CARLOS RODRIGUEZ 03 May '17

03 May '17

Hi Could be possible add native fps overlay, maybe can usefull for many apps and without forget steam overlay give performance issues in certain apps (steam overlay dont work since wine 2.6) Thanks

3 2

pulse/alsa option in wine cfg audio tab
by CARLOS RODRIGUEZ 03 May '17

03 May '17

Hi Seeking donat enikeev patch for add csmt option to graphics tab Could be possible add option for select which audio driver can be used aka alsa o pulse in winecfg audio tab ? Because various apps still needed alsa case tales of zestiria, alan wake and many others Thanks

2 1

Re: [PATCH 01/10] d3dx9/tests: Use compare_float() in D3DXFresnelTest().
by Alexandre Julliard 03 May '17

03 May '17

Matteo Bruni <mbruni(a)codeweavers.com> writes: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> Could you please try to send the signoff mail as a reply to the original patch, instead of a reply to your previous signoff? This way the tracker can find the appropriate patch automatically. Thanks. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/5] wsdapi: Implement WSD LinkedMemory functions [try 4]
by Alexandre Julliard 03 May '17

03 May '17

Owen Rudge <orudge(a)codeweavers.com> writes: > + ptr = HeapAlloc(procHeap, HEAP_ZERO_MEMORY, MEMORY_ALLOCATION_SIZE + cbSize); Are all allocations supposed to be zeroed? This is a little surprising, it would need a test too. > + > + srand((unsigned)time(NULL)); Please don't do that, test results need to be reproducible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz 03 May '17

03 May '17

> >> I've not tested the version, but recent commit 45a632ee81c9c5c58309426de5aadbd8dbbba0f5 >> introduces SYS_mmap2 system call which doesn't exist before 2.3.31. >> So, should we update the requirement? Is 2.3.31 valid enough? > >I'm not sure that we know what the minimum version is these days. If >mmap2 is really the only new dependency, adding a workaround is easy >enough. Is anybody able to test this? > >-- >Alexandre Julliard >julliard(a)winehq.org > Hmmm, no answers... It seems to me like crazy project, which nobody on Earth would ever undergo. To promote it from crazy to totally insane I could give a drive to one of my oldies. Like - 486DX - 386DX + 387 / 32MB RAM - 386DX / 4MB RAM with ISA Trident 512KB (no 386SX / 486SX;) just to see, how deep we can sink with those old ships :-)) I would let Pentium and Pentium MMX docked for being too modern. So when testing old kernels (Debian distributions) – If that ever compile what else could be interesting? GCC version? Libc version? X version? How to interpret successful test - compilation? (pre-compiled in VM) - Running winecfg?? - Running MS Paint???

3 3

Re: [PATCH resend] comctl32: When adding a scrollbar to a listview, update the other one.
by Nikolay Sivov 03 May '17

03 May '17

On 03.05.2017 7:53, Alex Henrie wrote: > Cc: Nikolay Sivov <nsivov(a)codeweavers.com> > > Fixes https://bugs.winehq.org/show_bug.cgi?id=35529 > > Adding a vertical scrollbar can necessitate adding a horizontal > scrollbar just as easily as adding a horizontal scrollbar can > necessitate adding a vertical scrollbar. (And in the same way, removing > either of the scrollbars can necessitate removing the other scrollbar.) > > This patch was previously assigned to Nikolay, but I never received any > feedback about it. Sorry about that. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/comctl32/listview.c | 78 +++++++++++++++++++++++++++++++----------------- > 1 file changed, 50 insertions(+), 28 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index c01d816c46..c3c89d08dc 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -2016,23 +2016,10 @@ static void LISTVIEW_UpdateHeaderSize(const LISTVIEW_INFO *infoPtr, INT nNewScro > SWP_NOZORDER | SWP_NOACTIVATE); > } > > -/*** > - * DESCRIPTION: > - * Update the scrollbars. This functions should be called whenever > - * the content, size or view changes. > - * > - * PARAMETER(S): > - * [I] infoPtr : valid pointer to the listview structure > - * > - * RETURN: > - * None > - */ > -static void LISTVIEW_UpdateScroll(const LISTVIEW_INFO *infoPtr) > +static INT LISTVIEW_UpdateHScroll(LISTVIEW_INFO *infoPtr) > { > - SCROLLINFO horzInfo, vertInfo; > - INT dx, dy; > - > - if ((infoPtr->dwStyle & LVS_NOSCROLL) || !is_redrawing(infoPtr)) return; > + SCROLLINFO horzInfo; > + INT dx; > > ZeroMemory(&horzInfo, sizeof(SCROLLINFO)); > horzInfo.cbSize = sizeof(SCROLLINFO); > @@ -2084,10 +2071,22 @@ static void LISTVIEW_UpdateScroll(const LISTVIEW_INFO *infoPtr) > dx -= SetScrollInfo(infoPtr->hwndSelf, SB_HORZ, &horzInfo, TRUE); > TRACE("horzInfo=%s\n", debugscrollinfo(&horzInfo)); > > - /* Setting the horizontal scroll can change the listview size > - * (and potentially everything else) so we need to recompute > - * everything again for the vertical scroll > - */ > + /* Update the Header Control */ > + if (infoPtr->hwndHeader) > + { > + horzInfo.fMask = SIF_POS; > + GetScrollInfo(infoPtr->hwndSelf, SB_HORZ, &horzInfo); > + LISTVIEW_UpdateHeaderSize(infoPtr, horzInfo.nPos); > + } > + > + LISTVIEW_UpdateSize(infoPtr); > + return dx; > +} > + > +static INT LISTVIEW_UpdateVScroll(LISTVIEW_INFO *infoPtr) > +{ > + SCROLLINFO vertInfo; > + INT dy; > > ZeroMemory(&vertInfo, sizeof(SCROLLINFO)); > vertInfo.cbSize = sizeof(SCROLLINFO); > @@ -2117,6 +2116,37 @@ static void LISTVIEW_UpdateScroll(const LISTVIEW_INFO *infoPtr) > dy -= SetScrollInfo(infoPtr->hwndSelf, SB_VERT, &vertInfo, TRUE); > TRACE("vertInfo=%s\n", debugscrollinfo(&vertInfo)); > > + LISTVIEW_UpdateSize(infoPtr); > + return dy; > +} > + > +/*** > + * DESCRIPTION: > + * Update the scrollbars. This function should be called whenever > + * the content, size or view changes. > + * > + * PARAMETER(S): > + * [I] infoPtr : valid pointer to the listview structure > + * > + * RETURN: > + * None > + */ > +static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *infoPtr) > +{ > + INT dx, dy; > + > + if ((infoPtr->dwStyle & LVS_NOSCROLL) || !is_redrawing(infoPtr)) return; > + > + /* Setting the horizontal scroll can change the listview size > + * (and potentially everything else) so we need to recompute > + * everything again for the vertical scroll and vice-versa > + */ > + > + dx = LISTVIEW_UpdateHScroll(infoPtr); > + dy = LISTVIEW_UpdateVScroll(infoPtr); > + dx += LISTVIEW_UpdateHScroll(infoPtr); > + dy += LISTVIEW_UpdateVScroll(infoPtr); > + This certainly doesn't look pretty, but I see what you mean. I'll take a look, thanks for reminding me. > /* Change of the range may have changed the scroll pos. If so move the content */ > if (dx != 0 || dy != 0) > { > @@ -2125,14 +2155,6 @@ static void LISTVIEW_UpdateScroll(const LISTVIEW_INFO *infoPtr) > ScrollWindowEx(infoPtr->hwndSelf, dx, dy, &listRect, &listRect, 0, 0, > SW_ERASE | SW_INVALIDATE); > } > - > - /* Update the Header Control */ > - if (infoPtr->hwndHeader) > - { > - horzInfo.fMask = SIF_POS; > - GetScrollInfo(infoPtr->hwndSelf, SB_HORZ, &horzInfo); > - LISTVIEW_UpdateHeaderSize(infoPtr, horzInfo.nPos); > - } > } > > >

1 0

Re: [2/4] ole32: Implement DataCache_InitCache
by Huw Davies 03 May '17

03 May '17

On Tue, May 02, 2017 at 06:11:22PM +0800, Wei Xie wrote: > diff --git a/dlls/ole32/datacache.c b/dlls/ole32/datacache.c > index 441a874..51a67e2 100644 > --- a/dlls/ole32/datacache.c > +++ b/dlls/ole32/datacache.c > @@ -2052,8 +2052,45 @@ static HRESULT WINAPI DataCache_InitCache( > IOleCache2* iface, > IDataObject* pDataObject) > { > - FIXME("stub\n"); > - return E_NOTIMPL; > + HRESULT hr; > + FORMATETC fmt; > + STGMEDIUM med; > + > + FIXME("semi-stub\n"); > + > + hr = IDataObject_GetData(pDataObject, &fmt, &med); > + if (FAILED(hr)) > + { > + return CACHE_E_NOCACHE_UPDATED; > + } > + > + if (!fmt.cfFormat || !fmt.tymed || > + (check_valid_clipformat_and_tymed(fmt.cfFormat, fmt.tymed, FALSE) > + && TYMED_NULL != med.tymed)) > + { > + switch(med.tymed) > + { > + case TYMED_GDI: > + { > + fmt.cfFormat = CF_BITMAP; > + fmt.ptd = NULL; > + fmt.dwAspect = DVASPECT_CONTENT; > + fmt.lindex = -1; > + fmt.tymed = TYMED_GDI; > + } > + break; > + default: > + FIXME("Fill formatetc\n"); > + } > + } > + > + hr = IOleCache2_SetData(iface, &fmt, &med, FALSE); > + if (FAILED(hr)) > + { > + return CACHE_E_NOCACHE_UPDATED; > + } > + > + return hr; > } This isn't correct. What I think the tests will show you is that it looks something like the pseudo-code: for_each_cached_format( &fmt ) /* some function that returns the fmt of each cache entry */ { IDataObject_GetData(pDataObject, &fmt, &med); IOleCache2_SetData(iface, &fmt, &med); } Of course there needs to be error handling, tests if the cache has already been initialized, etc. However for now I suggest you just concerntrate on getting the tests in, and come back to this and the subsequent patches later on. Huw.

1 0

Re: [1/4] ole32/test: Add InitCache test
by Huw Davies 03 May '17

03 May '17

On Tue, May 02, 2017 at 06:10:44PM +0800, Wei Xie wrote: > From 4f8b94b5a8c7739901eae8f19317ca6255911d20 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Tue, 2 May 2017 18:07:22 +0800 > Subject: [PATCH 1/4] ole32/test: Add InitCache test ole32/test: -> ole32/tests: > +static HRESULT WINAPI DataObject2_QueryInterface( > + IDataObject* iface, > + REFIID riid, > + void** ppvObject) > +{ > + CHECK_EXPECTED_METHOD("DataObject2_QueryInterface"); > + > + if (IsEqualIID(riid, &IID_IDataObject) || IsEqualIID(riid, &IID_IUnknown)) > + { > + *ppvObject = iface; > + return S_OK; > + } > + *ppvObject = NULL; > + return S_OK; > +} There's no need to create a new IDataObject implementation. Use the existing one and add a file-scope variable to control what _GetData does (which is all you really care about for this test). > +static HRESULT WINAPI DataObject2_GetData( > + IDataObject* iface, > + LPFORMATETC pformatetcIn, > + STGMEDIUM* pmedium) > +{ > + *pformatetcIn = FormatEtc; > + *pmedium = StgMedium; > + return S_OK; > +} You're not checking this method is called, which should be one of the goals of this test! pfomratetcIn is an [in] variable, so assigning things to it is useless. > @@ -1838,10 +1994,23 @@ todo_wine { > > DeleteDC(hdcMem); > > - todo_wine { You remove a todo_wine here and yet this patch doesn't change Wine's implementation, so this will produce a failure. The test must run cleanly on Wine (and Windows) after just this patch is applied. If you fix the implementation later on in the series, then remove the todo_wine in that patch, not this one. > + /* IDataObject_GetData Invalid */ I don't understand how this comment relates to the code. > hr = IOleCache2_InitCache(pOleCache, &DataObject); > ok(hr == CACHE_E_NOCACHE_UPDATED, "IOleCache_InitCache should have returned CACHE_E_NOCACHE_UPDATED instead of 0x%08x\n", hr); > - } > + > + fmtetc.ptd = NULL; > + fmtetc.dwAspect = DVASPECT_CONTENT; > + fmtetc.lindex = -1; > + fmtetc.cfFormat = CF_BITMAP; > + fmtetc.tymed = TYMED_GDI; > + stgmedium.tymed = TYMED_GDI; > + stgmedium.hBitmap = CreateCompatibleBitmap(hdcMem, 100, 100); > + stgmedium.pUnkForRelease = NULL; > + IDataObject_SetData(&DataObject2, &fmtetc, &stgmedium, FALSE); > + > + /* IOleCache2_InitCache not need IOleCache2_Cache first */ > + hr = IOleCache2_InitCache(pOleCache, &DataObject2); > + ok(hr == CACHE_E_NOCACHE_UPDATED, "IOleCache2_InitCache should have returned CACHE_E_NOCACHE_UPDATED instead of 0x%08x\n", hr); Why is the hunk even necessary, you're just calling InitCache again below a test that shows it fails. > > IPersistStorage_Release(pPS); > IViewObject_Release(pViewObject); > @@ -1851,6 +2020,44 @@ todo_wine { > CHECK_NO_EXTRA_METHODS(); > } > > + hdcMem = CreateCompatibleDC(NULL); > + fmtetc.ptd = NULL; > + fmtetc.dwAspect = DVASPECT_CONTENT; > + fmtetc.lindex = -1; > + fmtetc.cfFormat = CF_BITMAP; > + fmtetc.tymed = TYMED_GDI; > + stgmedium.tymed = TYMED_GDI; > + stgmedium.hBitmap = CreateCompatibleBitmap(hdcMem, 100, 100); > + stgmedium.pUnkForRelease = NULL; > + IDataObject_SetData(&DataObject2, &fmtetc, &stgmedium, FALSE); > + > + expected_method_list = methods_cacheinit; > + > + hr = CreateDataCache(NULL, &CLSID_NULL, &IID_IOleCache2, (LPVOID *)&pOleCache); > + ok_ole_success(hr, "CreateDataCache"); > + > + hr = IOleCache2_QueryInterface(pOleCache, &IID_IViewObject2, (LPVOID *)&pViewObject2); > + ok_ole_success(hr, "IOleCache_QueryInterface(IID_IViewObject2)"); > + > + hr = IOleCache2_Cache(pOleCache, &fmtetc, 0, &dwConnection); > + ok_ole_success(hr, "IOleCache2_Cache"); > + hr = IOleCache2_InitCache(pOleCache, &DataObject2); > + ok_ole_success(hr, "IOleCache2_InitCache"); > + > + hr = IViewObject2_SetAdvise(pViewObject2, DVASPECT_CONTENT, ADVF_PRIMEFIRST, &AdviseSink); > + ok_ole_success(hr, "IViewObject2_SetAdvise"); > + > + hr = IViewObject2_GetExtent(pViewObject2, DVASPECT_CONTENT, -1, NULL, &sz ); > + ok_ole_success(hr, "IViewObject2_GetExtent"); > + > + hr = IViewObject2_Draw(pViewObject2, DVASPECT_CONTENT, -1, NULL, NULL, NULL, hdcMem, &rcBounds, NULL, draw_continue, 0xdeadbeef); > + ok_ole_success(hr, "IViewObject2_GetExtent"); > + > + IViewObject2_Release(pViewObject2); > + IOleCache2_Release(pOleCache); > + > + DeleteDC(hdcMem); For this bit of the test, drop the IViewObject calls. What we care about is testing InitCache(). Then I suggest calling _Cache twice with two different formats and checking that _InitCache calls DataObject_GetData for those two formats. You'll need to make DataObject_GetData respond to these two different formats. It's a bit more complicated than that however because in the CF_BITMAP case _InitCache apparently calls _GetData with CF_DIB (this is part of the cache's ability to use dibs instead of bitmaps and vice-versa). You may want to avoid using CF_BITMAP to test this at this stage (we can add CF_BITMAP <-> CF_DIB tests later). Huw.

1 0

Re: [PATCH resend] comctl32: When adding a scrollbar to a listview, update the other one.
by Alistair Leslie-Hughes 03 May '17

03 May '17

Hi Alex, On 03/05/17 14:53, Alex Henrie wrote: > Cc: Nikolay Sivov <nsivov(a)codeweavers.com> > +static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *infoPtr) > +{ > + INT dx, dy; > + > + if ((infoPtr->dwStyle & LVS_NOSCROLL) || !is_redrawing(infoPtr)) return; > + > + /* Setting the horizontal scroll can change the listview size > + * (and potentially everything else) so we need to recompute > + * everything again for the vertical scroll and vice-versa > + */ > + > + dx = LISTVIEW_UpdateHScroll(infoPtr); > + dy = LISTVIEW_UpdateVScroll(infoPtr); > + dx += LISTVIEW_UpdateHScroll(infoPtr); > + dy += LISTVIEW_UpdateVScroll(infoPtr); > + Is there any reason your calling update twice for each control? Best Regards Alistair Leslie-Hughes

2 1

Re: [PATCH resend] comctl32: When adding a scrollbar to a listview, update the other one.
by Alistair Leslie-Hughes 03 May '17

03 May '17

Hi Alex, On 03/05/17 14:53, Alex Henrie wrote: > Cc: Nikolay Sivov <nsivov(a)codeweavers.com> > +static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *infoPtr) > +{ > + INT dx, dy; > + > + if ((infoPtr->dwStyle & LVS_NOSCROLL) || !is_redrawing(infoPtr)) return; > + > + /* Setting the horizontal scroll can change the listview size > + * (and potentially everything else) so we need to recompute > + * everything again for the vertical scroll and vice-versa > + */ > + > + dx = LISTVIEW_UpdateHScroll(infoPtr); > + dy = LISTVIEW_UpdateVScroll(infoPtr); > + dx += LISTVIEW_UpdateHScroll(infoPtr); > + dy += LISTVIEW_UpdateVScroll(infoPtr); > + Is there any reason your calling update twice for each control? Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH v3 4/6] user32: Fix the calculation of system metrics icon sizes.
by Marvin 02 May '17

02 May '17

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=30726 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit sysparams) === sysparams.c:206: Test failed: Unexpected WM_DISPLAYCHANGE message sysparams.c:206: Test failed: Unexpected WM_DISPLAYCHANGE message

2 1

Re: [PATCH v3 6/6] user32: Change IsProcessDPIAware() to always return TRUE.
by Marvin 02 May '17

02 May '17

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=30727 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [PATCH v2 6/6] user32: Change IsProcessDPIAware() to always return TRUE.
by Marvin 02 May '17

02 May '17

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=30723 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit sysparams) === sysparams.c:206: Test failed: Unexpected WM_DISPLAYCHANGE message

1 0

Re: [PATCH v2 2/2] ddraw: Validate that non-fill blits have a source surface in ddraw_surface7_Blt().
by Marvin 02 May '17

02 May '17

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=30715 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:1686: Test failed: Got unexpected color 0x000000ff.

1 0

Re: [PATCH v2 4/6] user32: Fix the calculation of system metrics icon sizes.
by Marvin 02 May '17

02 May '17

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=30722 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 4/6] user32: Fix the calculation of system metrics icon sizes.
by Marvin 02 May '17

02 May '17

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=30703 Your paranoid android. === wxppro (32 bit sysparams) === sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 20 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 20 === wvistau64 (32 bit sysparams) === sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 18 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 18 === w7u (32 bit sysparams) === sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 6 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 6 === w8 (32 bit sysparams) === sysparams.c:2517: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2528: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16 === w1064 (32 bit sysparams) === sysparams.c:204: Test failed: Unexpected WM_DISPLAYCHANGE message sysparams.c:2523: Test failed: WM_DISPLAYCHANGE was sent with wParam 32 despite mode change failure sysparams.c:2528: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:204: Test failed: Unexpected WM_DISPLAYCHANGE message sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16 === wvistau64 (64 bit sysparams) === sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 18 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 18 === w1064 (64 bit sysparams) === sysparams.c:2825: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2826: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16

2 1

Re: [PATCH 6/6] user32: Change IsProcessDPIAware() to always return TRUE.
by Marvin 02 May '17

02 May '17

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=30704 Your paranoid android. === wxppro (32 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 20 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 20 === wvistau64 (32 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 18 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 18 === w7u (32 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 6 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 6 === w8 (32 bit sysparams) === sysparams.c:2519: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2530: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16 sysparams.c:2975: Test failed: got 96, dpi 96, real_dpi 0 === w1064 (32 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16 sysparams.c:2975: Test failed: got 96, dpi 96, real_dpi 0 === wvistau64 (64 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 16 actual 18 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 16 actual 18 === w1064 (64 bit sysparams) === sysparams.c:2827: Test failed: GetSystemMetrics(SM_CXSMICON): expected 4 actual 16 sysparams.c:2828: Test failed: GetSystemMetrics(SM_CYSMICON): expected 4 actual 16 sysparams.c:2975: Test failed: got 96, dpi 96, real_dpi 0

1 0

Re: [PATCH 2/5] ddraw: Validate that non-fill blits have a source surface in ddraw_surface7_Blt().
by Marvin 02 May '17

02 May '17

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=30698 Your paranoid android. === wxppro (32 bit ddraw4) === 0a24:ddraw4: unhandled exception c0000005 at 0000FFFF === w2003std (32 bit ddraw4) === 05f0:ddraw4: unhandled exception c0000005 at 0049CE7A === wvistau64 (32 bit ddraw4) === 0970:ddraw4: unhandled exception c0000005 at 0049CE7A === w2008s64 (32 bit ddraw4) === 0b30:ddraw4: unhandled exception c0000005 at 0049CE7F === w7u (32 bit ddraw4) === 0ca4:ddraw4: unhandled exception c0000005 at 0049CE7A === w7pro64 (32 bit ddraw4) === 00c0:ddraw4: unhandled exception c0000005 at 0049CE7F === wvistau64 (64 bit ddraw4) === 01b0:ddraw4: unhandled exception c0000005 at 00000000004865E2 === w2008s64 (64 bit ddraw4) === 08c4:ddraw4: unhandled exception c0000005 at 00000000004865E2 === w7pro64 (64 bit ddraw4) === 07e0:ddraw4: unhandled exception c0000005 at 00000000004865E2 === w864 (64 bit ddraw4) === 0fc8:ddraw4: unhandled exception c0000005 at 00000000004865E2 === w1064 (64 bit ddraw4) === 0f3c:ddraw4: unhandled exception c0000005 at 00000000004865E2 === w864 (32 bit ddraw1) === ddraw1.c:10272: Test failed: Got unexpected color 0x00ffffff.

1 0

Re: [PATCH 1/5] ddraw/tests: Port test_texturemapblend() to ddraw4.c as well.
by Marvin 02 May '17

02 May '17

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=30697 Your paranoid android. === wxppro (32 bit ddraw4) === 09f8:ddraw4: unhandled exception c0000005 at 0000FFFF === w2003std (32 bit ddraw4) === 05f0:ddraw4: unhandled exception c0000005 at 0049CB5A === wvistau64 (32 bit ddraw4) === 0744:ddraw4: unhandled exception c0000005 at 0049CB5A === w2008s64 (32 bit ddraw4) === 0bf4:ddraw4: unhandled exception c0000005 at 0049CB5F === w7u (32 bit ddraw4) === 0fbc:ddraw4: unhandled exception c0000005 at 0049CB5A === w7pro64 (32 bit ddraw4) === 0338:ddraw4: unhandled exception c0000005 at 0049CB5F === wvistau64 (64 bit ddraw4) === 072c:ddraw4: unhandled exception c0000005 at 00000000004863E2 === w2008s64 (64 bit ddraw4) === 0b30:ddraw4: unhandled exception c0000005 at 00000000004863E2 === w7pro64 (64 bit ddraw4) === 0854:ddraw4: unhandled exception c0000005 at 00000000004863E2 === w864 (64 bit ddraw4) === 0fac:ddraw4: unhandled exception c0000005 at 00000000004863E2 === w1064 (64 bit ddraw4) === 0c84:ddraw4: unhandled exception c0000005 at 00000000004863E2

1 0

Wine native fps overlay
by CARLOS RODRIGUEZ 02 May '17

02 May '17

Hi Almost forget maybe can improve WINEDEBUG=+fps for only display fps (actually gives priority to errors than fps information) Thanks

2 1

Re: [PATCH v3 1/2] mountmgr: Create devices and registry entries for serial ports.
by Bruno Jesus 02 May '17

02 May '17

On Wed, Apr 26, 2017 at 12:18 AM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=11811 > > This patch also autodetects USB serial ports, making them "just work". > > The user may override the port autodetection by creating entries in > HKLM\Software\Wine\Ports. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> Although I don't feel qualified to sign this patch I can say that I tested it with real hardware and it works fine for both real and USB serial ports in Linux. Hyper Terminal recognizes all ports without any manual registry workaround.

1 0

Re: [v3 PATCH 1/4] mfplat: Implement MFTRegister
by Alexandre Julliard 01 May '17

01 May '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +static HRESULT register_category(CLSID *clsid, GUID *category) > +{ > + HKEY hcategory, htmp1, htmp2; > + WCHAR buffer[64]; > + DWORD ret; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, category); > + ret = RegCreateKeyW(hcategory, buffer, &htmp1); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; You should create the entire path if needed instead of failing. > @@ -650,6 +650,10 @@ HKLM,Software\Borland\Database Engine\Settings\SYSTEM\INIT,SHAREDMEMLOCATION,,90 > HKLM,Software\Clients\Mail,,2,"Native Mail Client" > HKLM,Software\Clients\Mail\Native Mail Client,,2,"Native Mail Client" > HKLM,Software\Clients\Mail\Native Mail Client,"DLLPath",2,"%11%\winemapi.dll" > +HKLM,Software\Classes\MediaFoundation,,16 > +HKLM,Software\Classes\MediaFoundation\MediaSources,,16 > +HKLM,Software\Classes\MediaFoundation\Transforms,,16 > +HKLM,Software\Classes\MediaFoundation\Transforms\Categories,,16 ...and then you no longer need this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: regedit: Read registry lines through a single function
by Alexandre Julliard 01 May '17

01 May '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > +static WCHAR *get_line(struct reg_info *reg_info) > +{ > + WCHAR *line; > + > + if (!reg_info->is_unicode) > + { > + char *lineA = get_lineA(reg_info->file); > + line = GetWideString(lineA); > + } > + else > + { > + line = get_lineW(reg_info->file); > + } > + > + return line; > +} That's fairly ugly. If you want to use common code, you should probably pass a function pointer for getting lines. Also you'd have to do it in a way that doesn't require freeing the buffer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] user32: Do not call SendMessage() to show a window that is already visible.
by Dmitry Timoshkov 01 May '17

01 May '17

Kimmo Myllyvirta <kimmo.myllyvirta(a)gmail.com> wrote: > diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c > index c2b35ec..64fdfe0 100644 > --- a/dlls/user32/winpos.c > +++ b/dlls/user32/winpos.c > @@ -1239,6 +1239,9 @@ BOOL WINAPI ShowWindow( HWND hwnd, INT cmd ) > if ((cmd == SW_HIDE) && !(GetWindowLongW( hwnd, GWL_STYLE ) & WS_VISIBLE)) > return FALSE; > > + if ((cmd == SW_SHOW) && (GetWindowLongW( hwnd, GWL_STYLE ) & WS_VISIBLE)) > + return TRUE; > + > return SendMessageW( hwnd, WM_WINE_SHOWWINDOW, cmd, 0 ); > } Please have a look at the show_window() implementation and try to cover all cases that trigger SWP_SHOWWINDOW flag passed to SetWindowPos() in order to actually show a window. In fact it's only SW_HIDE that leads to that, so perhaps just adding an 'else' to the SW_HIDE case is enough? -- Dmitry.

2 1

Re: [1/5] wsdapi: Implement WSD LinkedMemory functions [try 3]
by Alexandre Julliard 01 May '17

01 May '17

Owen Rudge <orudge(a)codeweavers.com> writes: > +struct memory_allocation > +{ > + int magic; > + struct list entry; > + > + struct list children; > +}; You'd probably want to preserve the heap block alignment. Some test cases would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine native fps overlay
by CARLOS RODRIGUEZ 01 May '17

01 May '17

Gallium HUD provides various features but have same problem Only works in certain hardware and only on linux meanwhile if wine could provide native fps overlay must be works in all hardware and all type drivers (closed and opensource) and all operating system supported Thanks

1 0

Re: dmusic: Implement IDirectMusicBuffer::PackUnstructured().
by Henri Verbeet 01 May '17

01 May '17

On 1 May 2017 at 02:05, Michael Stefaniuc <mstefani(a)winehq.org> wrote: > -static HRESULT WINAPI IDirectMusicBufferImpl_PackUnstructured(LPDIRECTMUSICBUFFER iface, REFERENCE_TIME rt, DWORD dwChannelGroup, DWORD cb, LPBYTE lpb) > +static HRESULT WINAPI IDirectMusicBufferImpl_PackUnstructured(IDirectMusicBuffer *iface, > + REFERENCE_TIME ref_time, DWORD channel_group, DWORD len, BYTE *data) > { > IDirectMusicBufferImpl *This = impl_from_IDirectMusicBuffer(iface); > + DWORD new_write_pos = This->write_pos + DMUS_EVENT_SIZE(len); > + DMUS_EVENTHEADER header; > + > + TRACE("(%p, 0x%s, %d, %d, %p)\n", This, wine_dbgstr_longlong(ref_time), channel_group, len, data); > > - FIXME("(%p, 0x%s, %d, %d, %p): stub\n", This, wine_dbgstr_longlong(rt), dwChannelGroup, cb, lpb); > + if (new_write_pos > This->size) > + return DMUS_E_BUFFER_FULL; > + > + if (!This->write_pos) > + This->start_time = ref_time; > + > + header.cbEvent = len; > + header.dwChannelGroup = channel_group; > + header.rtDelta = ref_time - This->start_time; > + header.dwFlags = 0; > + > + memcpy(This->data + This->write_pos, &header, sizeof(header)); > + memcpy(This->data + This->write_pos + sizeof(header), data, len); The difference is of course largely stylistic, but note that you could also do something like the following: DMUS_EVENTHEADER *header; ... header = (DMUS_EVENTHEADER *)&This->data[This->write_pos]; ... memcpy(&header[1], data, len);

1 0

Wine native fps overlay
by CARLOS RODRIGUEZ 01 May '17

01 May '17

Hi Yes +fps option works but not all time, many times wine gives priority to some errors messages than fps counter However native fps overlay will be better because overlay appears independent wine message errors Without forget will be better for new users but need to some option for enable in winecfg Thanks

2 1

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by Alexandre Julliard 01 May '17

01 May '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > I've not tested the version, but recent commit 45a632ee81c9c5c58309426de5aadbd8dbbba0f5 > introduces SYS_mmap2 system call which doesn't exist before 2.3.31. > So, should we update the requirement? Is 2.3.31 valid enough? I'm not sure that we know what the minimum version is these days. If mmap2 is really the only new dependency, adding a workaround is easy enough. Is anybody able to test this? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: version: Fix error in win 9x mode when a file was not found in GetFileVersionInfoSize.
by Nikolay Sivov 30 Apr '17

30 Apr '17

On 28.04.2017 18:03, Sebastian Lackner wrote: > From: Michael Müller <michael(a)fds-team.de> > > Signed-off-by: Michael Müller <michael(a)fds-team.de> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/version/version.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/dlls/version/version.c b/dlls/version/version.c > index ed060c82b6..3ab53026e8 100644 > --- a/dlls/version/version.c > +++ b/dlls/version/version.c > @@ -705,7 +705,12 @@ DWORD WINAPI GetFileVersionInfoSizeExW( DWORD flags, LPCWSTR filename, LPDWORD h > return (len * 2) + 4; > > default: > - SetLastError( lzfd == HFILE_ERROR ? ofs.nErrCode : ERROR_RESOURCE_DATA_NOT_FOUND ); > + if (lzfd == HFILE_ERROR) > + SetLastError(ofs.nErrCode); > + else if (GetVersion() & 0x80000000) > + SetLastError(ERROR_FILE_NOT_FOUND); > + else > + SetLastError(ERROR_RESOURCE_DATA_NOT_FOUND); > return 0; > } > } > What depends on this? Is this function actually exported on Win9x? If not this fixup should happen in actual affected export I think.

2 1

Re: [PATCH v2] taskmgr/endproc.c: Implement ProcessPage_OnEndProcessTree()
by Bruno Jesus 30 Apr '17

30 Apr '17

Hi, just a variable type change and minor style suggestions, some you can accept or ignore. > ... > > +static BOOL process_list_append(process_list *list, DWORD id) > +{ > + INT *temp; > + if (list->count == list->size) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > - return; > + list->size *= 2; > + temp = HeapReAlloc(GetProcessHeap(), 0, list->pid, list->size * sizeof(*list->pid)); > + if(!temp) > + return FALSE; > + > + list->pid = temp; > } > + list->pid[list->count++] = id; > + return TRUE; > +} Please use an empty line to separate variable declaration from code. Change "INT *temp" to "DWORD *temp" so it matches the same type from list->pid. You can also reduce the scope of the temp variable. There are 4 uses of "if(", please change to "if (". > - if (!TerminateProcess(hProcess, 0)) > +static void free_process_list(process_list *list) > +{ > + HeapFree(GetProcessHeap(), 0, list->pid); > +} > + > +static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) > +{ > + PROCESSENTRY32 entry; > + SIZE_T start, end, i; > + > + start = list->count; > + entry.dwSize = sizeof(entry); > + > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + { > + if(!process_list_append(list, entry.th32ProcessID)) > + { > + free_process_list(list); > + return; > + } > + } > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + for (i = start; i < end; ++i) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + enum_process_children(snapshot, list, list->pid[i]); > } You can drop the { } since there is a single line now, but it is just a suggestion. Other style suggestion is to merge the end attribution inside the for like "for (i = start, end = list-> count; ...". > - > - CloseHandle(hProcess); > } > > void ProcessPage_OnEndProcessTree(void) > @@ -100,11 +171,14 @@ void ProcessPage_OnEndProcessTree(void) > DWORD dwProcessId; > HANDLE hProcess; > WCHAR wstrErrorText[256]; > + process_list list; > + SIZE_T i; > + HANDLE snapshot; > > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index = 0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -116,7 +190,6 @@ void ProcessPage_OnEndProcessTree(void) > if (lvitem.state & LVIS_SELECTED) > break; > } > - > Count = SendMessageW(hProcessPageListCtrl, LVM_GETSELECTEDCOUNT, 0, 0); Please don't remove the empty line to separate the code from the "for" block. > ... On Sat, Apr 29, 2017 at 7:08 PM, Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39640 > > Implemented ProcessPage_OnEndProcessTree(). It now kills all the child processes along with the specified process. > > Signed-off-by: Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> > --- > programs/taskmgr/endproc.c | 125 +++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 105 insertions(+), 20 deletions(-) > > diff --git a/programs/taskmgr/endproc.c b/programs/taskmgr/endproc.c > index 89c2d7b..60df0d7 100644 > --- a/programs/taskmgr/endproc.c > +++ b/programs/taskmgr/endproc.c > @@ -31,11 +31,18 @@ > #include "wine/unicode.h" > #include "taskmgr.h" > #include "perfdata.h" > +#include "tlhelp32.h" > > static WCHAR wszWarnMsg[511]; > static WCHAR wszWarnTitle[255]; > static WCHAR wszUnable2Terminate[255]; > > +typedef struct process_list { > + DWORD *pid; > + SIZE_T count; /* index to maintain the last entry of the array */ > + SIZE_T size; > +} process_list; > + > static void load_message_strings(void) > { > LoadStringW(hInst, IDS_TERMINATE_MESSAGE, wszWarnMsg, sizeof(wszWarnMsg)/sizeof(WCHAR)); > @@ -43,6 +50,22 @@ static void load_message_strings(void) > LoadStringW(hInst, IDS_WARNING_TITLE, wszWarnTitle, sizeof(wszWarnTitle)/sizeof(WCHAR)); > } > > +static void kill_process(HANDLE hProcess, WCHAR *wstrErrorText) > +{ > + if (!hProcess) > + { > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > + MessageBoxW(hMainWnd, wstrErrorText, wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + return; > + } > + > + if (!TerminateProcess(hProcess, 0)) > + { > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > + MessageBoxW(hMainWnd, wstrErrorText, wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + } > +} > + > void ProcessPage_OnEndProcess(void) > { > LVITEMW lvitem; > @@ -54,7 +77,7 @@ void ProcessPage_OnEndProcess(void) > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index=0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -77,20 +100,68 @@ void ProcessPage_OnEndProcess(void) > > hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwProcessId); > > - if (!hProcess) > + kill_process(hProcess, wstrErrorText); > + CloseHandle(hProcess); > +} > + > +static BOOL init_process_list(process_list *list) > +{ > + list->size = 4; /* initialise size with 4. Will increase if necessary */ > + list->pid = HeapAlloc(GetProcessHeap(), 0, list->size * sizeof(*list->pid)); > + list->count = 0; > + > + return list->pid != NULL; > +} > + > +static BOOL process_list_append(process_list *list, DWORD id) > +{ > + INT *temp; > + if (list->count == list->size) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > - return; > + list->size *= 2; > + temp = HeapReAlloc(GetProcessHeap(), 0, list->pid, list->size * sizeof(*list->pid)); > + if(!temp) > + return FALSE; > + > + list->pid = temp; > } > + list->pid[list->count++] = id; > + return TRUE; > +} > > - if (!TerminateProcess(hProcess, 0)) > +static void free_process_list(process_list *list) > +{ > + HeapFree(GetProcessHeap(), 0, list->pid); > +} > + > +static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) > +{ > + PROCESSENTRY32 entry; > + SIZE_T start, end, i; > + > + start = list->count; > + entry.dwSize = sizeof(entry); > + > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + { > + if(!process_list_append(list, entry.th32ProcessID)) > + { > + free_process_list(list); > + return; > + } > + } > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + for (i = start; i < end; ++i) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + enum_process_children(snapshot, list, list->pid[i]); > } > - > - CloseHandle(hProcess); > } > > void ProcessPage_OnEndProcessTree(void) > @@ -100,11 +171,14 @@ void ProcessPage_OnEndProcessTree(void) > DWORD dwProcessId; > HANDLE hProcess; > WCHAR wstrErrorText[256]; > + process_list list; > + SIZE_T i; > + HANDLE snapshot; > > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index = 0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -116,7 +190,6 @@ void ProcessPage_OnEndProcessTree(void) > if (lvitem.state & LVIS_SELECTED) > break; > } > - > Count = SendMessageW(hProcessPageListCtrl, LVM_GETSELECTEDCOUNT, 0, 0); > dwProcessId = PerfDataGetProcessId(Index); > if ((Count != 1) || (dwProcessId == 0)) > @@ -125,20 +198,32 @@ void ProcessPage_OnEndProcessTree(void) > if (MessageBoxW(hMainWnd, wszWarnMsg, wszWarnTitle, MB_YESNO|MB_ICONWARNING) != IDYES) > return; > > - hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwProcessId); > + if (!init_process_list(&list)) > + return; > > - if (!hProcess) > + if (!process_list_append(&list, dwProcessId)) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + free_process_list(&list); > return; > } > > - if (!TerminateProcess(hProcess, 0)) > + snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); > + > + if (snapshot == INVALID_HANDLE_VALUE) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + free_process_list(&list); > + return; > } > + enum_process_children(snapshot, &list, dwProcessId); > + > + CloseHandle(snapshot); > > - CloseHandle(hProcess); > + for (i = 0; i < list.count; ++i) > + { > + hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list.pid[i]); > + > + kill_process(hProcess, wstrErrorText); > + CloseHandle(hProcess); > + } > + free_process_list(&list); > } > -- > 2.9.3 > > >

1 0

Re: [v2 PATCH 1/4] mfplat: Implement MFTRegister
by Nikolay Sivov 30 Apr '17

30 Apr '17

On 30.04.2017 6:29, Alistair Leslie-Hughes wrote: > + for (i = 0; i < cinput; i++) > + { > + memcpy(&types[2 * i], &input_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &input_types[i].guidSubtype, sizeof(GUID)); > + } This probably could be simplified even more, you can use MFT_REGISTER_TYPE_INFO for 'types' (that would make it 'type' actually), and do types[i] = input_types[i];, or even copy whole input_types array at once. Same applies to MFTEnum().

1 0

Re: [v2 PATCH 3/4] mfplat: Implement MFTEnum.
by Nikolay Sivov 30 Apr '17

30 Apr '17

On 30.04.2017 6:29, Alistair Leslie-Hughes wrote: > + for (i = 0; i < size / sizeof(GUID); i += 2) > + { > + if (!IsEqualGUID(&guids[i], &type->guidMajorType) && > + !IsEqualGUID(&guids[i+1], &type->guidSubtype)) > + { > + ret = TRUE; > + break; > + } > + } This is confusing. Shouldn't it look for a match?

1 0

Re: [PATCH] user32: Do not call SendMessage() to show a window that is already visible.
by Marvin 29 Apr '17

29 Apr '17

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=30597 Your paranoid android. === w7pro64 (32 bit msg) === msg.c:5274: Test failed: RedrawWindow:show_popup_extreme_location: 12: the msg 0x001c was expected, but got msg 0x0085 instead

2 1

Re: [PATCH] glu32: avoid assert side effect (Coverity)
by Nikolay Sivov 29 Apr '17

29 Apr '17

On 29.04.2017 20:34, Marcus Meissner wrote: > CID 401313 > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/glu32/sweep.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/glu32/sweep.c b/dlls/glu32/sweep.c > index a909e2be33..1248e9f050 100644 > --- a/dlls/glu32/sweep.c > +++ b/dlls/glu32/sweep.c > @@ -1287,7 +1287,8 @@ static void DoneEdgeDict( GLUtesselator *tess ) > */ > if( ! reg->sentinel ) { > assert( reg->fixUpperEdge ); > - assert( ++fixedEdges == 1 ); > + ++fixedEdges; > + assert( fixedEdges == 1 ); > } > assert( reg->windingNumber == 0 ); > DeleteRegion( tess, reg ); > This particular one has no side effects. I don't know what's the plan for glu, maybe it's a better idea to report/fix anything the comes up in mesa, and then import again.

2 1

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)
by Michael Müller 29 Apr '17

29 Apr '17

This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: schannel_gnutls.c: In function schannel_get_mac_algid: schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use in this function) schannel_gnutls.c:329:10: note: each undeclared identifier is reported only once for each function it appears in Build overview: https://dev.wine-staging.com/builder/group/60/ (Click Downloads for build logs) Debian Wheezy build log: https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log Regards, Michael

5 5

Re: [PATCH 4/4] dmloader/tests: Add some IDirectMusicLoader directory tests.
by Sebastian Lackner 28 Apr '17

28 Apr '17

On 27.04.2017 19:15, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org> > --- > dlls/dmloader/tests/loader.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > Your patch introduced a bunch of test failures here: loader.c:69: Test succeeded inside todo block: SetSearchDirectory failed with 0 loader.c:71: Test failed: Second SetSearchDirectory failed with 0 loader.c:73: Test failed: SetSearchDirectory failed with 0x1

2 1

Re: Review | endproc.c: Implement ProcessPage_OnEndProcessTree
by Aaryaman Vasishta 28 Apr '17

28 Apr '17

Forgot to CC wine-devel.. On Fri, Apr 21, 2017 at 12:47 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > Hi, > > On Thu, Apr 20, 2017 at 6:51 AM, Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> > wrote: > >> Hi >> Could someone take out a little time to review the code once? >> Bug I intend to solve: https://bugs.winehq.org/show_bug.cgi?id=39640 >> >> I am new to wine. So, I would appreciate suggestions regarding my coding >> style if that's not-so-perfect according to wine standards. Or any other >> problems with the code I have written. I apologize for submitting an >> untested code earlier. I hope now it works fine. >> > No worries! your efforts in contributing is always appreciated :) > > > /*-------------------------------------------CODE----------- >> ---------------------------------------*/ >> > Try using diffs/patches instead of manually copying them in this format. > Diffs are easier to apply and test with using git. That's how Stefan was > able to detect compilation errors in the patches you sent over on > wine-patches. I suggest sending another email with the changes in a diif > format if possible. > >> *//DOUBT: *Would sizeof(list->pid) be better or sizeof(int)? >> //Since in the former case, since list->pid is actually a pointer to >> DWORD, so //sizeof(list->pid) would return 8 bytes and not 4 bytes. >> >> } >> > Probably sizeof(DWORD) would be fine as well. In general, try following > what the surrounding, previously committed code is doing. > FWIW, pointers don't necessarily have to be 8 bytes in size. The size of a > pointer depends on whether your application is compiled as 32 or 64 bit. > It's possible to e.g. compile a program as 32 bit on a 64 bit machine. > For wine in 64 bit: https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F > > Cheers, > Aaryaman >

4 5

Re: [PATCH 4/4] mfplat/tests: Add tests.
by Andrew Eikum 28 Apr '17

28 Apr '17

On Fri, Apr 28, 2017 at 04:29:07AM +0000, Alistair Leslie-Hughes wrote: > +static void test_register(void) > +{ > + static WCHAR name[] = {'W','i','n','e',' ','t','e','s','t',0}; > + MFT_REGISTER_TYPE_INFO input; > + MFT_REGISTER_TYPE_INFO output; > + CLSID *clsids; > + UINT32 count; > + HRESULT ret; > + > + memcpy(&input.guidMajorType, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&input.guidMajorType, &DUMMY_GUID2, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID3, sizeof(GUID)); > + Looks like some copy-paste errors here. Andrew

1 0

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.
by Ralf Habacker 28 Apr '17

28 Apr '17

Am 07.03.2017 um 15:20 schrieb Sebastian Lackner: > Was it intentional that you did not CC the wine-devel mailing list? no, I Just replyed to all; fixed that > > On 07.03.2017 10:22, Ralf Habacker wrote: >> In the opposite having wineserver environment variable set in users >> environment will make it sure to always starts wineserver with the >> requested settings. > Well, you could also change $PATH globally to let "wine" point to your > special wrapper executable. This would not really be different from using > a global WINESERVER variable. Really ? Adding an additional path looks more invasive in terms of security and maintenance as using a dedicated environment variable affecting only one executable. > > I think there is a misunderstanding here, each wineprefix uses its own > wineserver instance. Wineservers started for other prefixes will never > inherit any timeout settings. Thanks for this pointer, I wasn't aware of that. >> [...] >> >> With the mentioned patch applied to a local wine build (or with a >> renamed wineserver) the site now runs about two weeks and one noticable >> change is that the initial >> mentioned communication issue did not happens. This let me think that >> there may be a long time running issue with wineserver, which affects >> the dde interface. > It is nice that you have found a workaround, however we would also like > to fix such issues of course. If you find any way to trigger this issue, > please file a bug report. I will do but unfortunally I'm not at this point yet. Observations from the last weeks shows that the error happened two times: 1. wineserver is running 12 days and not restarted because one application showed a message box, therefore did not quit and blocked wineserver restart, which let other wine applications dde communication fail 20170309-061102.523831920: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last wineserver restart 20170321-150057.967117185: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> manual restarted because of application freeze 2. wineserver is running 3 days and applications dde communications fails because wineserver has been restarted immediatly 20170322-061003.064358739: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last restart .... 20170325-220751 -> print job starts 20170325-220753.202518273: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> wineserver has been restarted by timeout 20170325-220805 applications dde communication fails and wine reports wine: chdir to /tmp/.wine-37002/server-fd0a-9602cwine: : No such file or directory chdir to /tmp/.wine-37002/server-fd0a-9602c : No such file or directoryThis is expected and not a bug. It can happen when multiple wine > instances try to start up wineserver at the same time. Only the first > wineserver instance will be able to acquire the lock, all others will > exit and then connect to the existing wineserver. Sound reasonable Best regards Ralf

1 1

Re: [1/5] wsdapi: Implement WSD LinkedMemory functions [try 2]
by Alexandre Julliard 28 Apr '17

28 Apr '17

Owen Rudge <orudge(a)codeweavers.com> writes: > +struct memory_allocation > +{ > + struct list entry; > + void *ptr; > + > + struct list children; > +}; > + > +static struct list memory_allocations = LIST_INIT(memory_allocations); > + > +static struct memory_allocation *find_allocation(struct list *searchList, void *parent) > +{ > + struct memory_allocation *allocation, *childAllocation; > + > + LIST_FOR_EACH_ENTRY(allocation, searchList, struct memory_allocation, entry) > + { > + if (allocation->ptr == parent) > + { > + return allocation; > + } > + > + /* Search the children */ > + childAllocation = find_allocation(&allocation->children, parent); > + > + if (childAllocation != NULL) > + { > + return childAllocation; > + } > + } > + > + return NULL; > +} You should probably store the child list at the start of the allocated block or something like that, you don't want to go through the entire list on every operation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] mfplat/tests: Add tests.
by Nikolay Sivov 28 Apr '17

28 Apr '17

On 28.04.2017 7:29, Alistair Leslie-Hughes wrote: > +BOOL init_function_ptrs(void) > +{ > + HMODULE mfplat = LoadLibraryA("mfplat.dll"); > + if (!mfplat) > + { > + win_skip("Could not load mfplat.dll\n"); > + return FALSE; > + } > + > + #define LOAD_FUNCPTR(f) p##f = (void*)GetProcAddress(mfplat, #f) > + LOAD_FUNCPTR(MFTEnum); > + LOAD_FUNCPTR(MFTRegister); > + LOAD_FUNCPTR(MFTUnregister); > + #undef LOAD_FUNCPTR > + > + return TRUE; > +} This looks redundant, why is it not statically linked?

1 0

Re: [PATCH 3/4] mfplat: Implement MFTEnum.
by Nikolay Sivov 28 Apr '17

28 Apr '17

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + for (i = 0; i < size / sizeof(GUID); i += 2) > + { > + if (!memcmp(&guids[i], &type->guidMajorType, sizeof(GUID)) && > + !memcmp(&guids[i+1], &type->guidSubtype, sizeof(GUID))) > + { > + ret = TRUE; > + break; > + } > + } IsEqualGUID could be used instead. > +HRESULT WINAPI MFTEnum(GUID category, UINT32 flags, MFT_REGISTER_TYPE_INFO *input_type, > + MFT_REGISTER_TYPE_INFO *output_type, IMFAttributes *attributes, > + CLSID **pclsids, UINT32 *pcount) I think it's better to print a fixme for non-zero flags and attributes, and use TRACE otherwise. > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, &category); > + > + ret = RegOpenKeyW(hcategory, buffer, &hlist); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; This probably could be replaced with a single RegOpenKeyW(). > + PVOID tmp; Why void*?

1 0

Re: [PATCH 2/4] mfplat: Implement MFTUnregister.
by Nikolay Sivov 28 Apr '17

28 Apr '17

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + FIXME("(%s)\n", debugstr_guid(&clsid)); Same, why fixme?

1 0

Re: [PATCH 1/4] mfplat: Implement MFTRegister
by Nikolay Sivov 28 Apr '17

28 Apr '17

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > From: Michael Müller <michael(a)fds-team.de> > > Changes > - Added pointer check output_types, input_types > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/mfplat/Makefile.in | 1 + > dlls/mfplat/main.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/mfplat/mfplat.spec | 2 +- > loader/wine.inf.in | 4 ++ > 4 files changed, 150 insertions(+), 1 deletion(-) > > diff --git a/dlls/mfplat/Makefile.in b/dlls/mfplat/Makefile.in > index 2b5bd24..9679f53 100644 > --- a/dlls/mfplat/Makefile.in > +++ b/dlls/mfplat/Makefile.in > @@ -1,4 +1,5 @@ > MODULE = mfplat.dll > +IMPORTS = user32 advapi32 > > C_SRCS = \ > main.c > diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c > index aae81f8..424c7f4 100644 > --- a/dlls/mfplat/main.c > +++ b/dlls/mfplat/main.c > @@ -23,15 +23,44 @@ > > #include "windef.h" > #include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > > #include "initguid.h" > #include "mfapi.h" > #include "mferror.h" > > #include "wine/debug.h" > +#include "wine/unicode.h" > > WINE_DEFAULT_DEBUG_CHANNEL(mfplat); > > +static WCHAR transform_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s',0}; > +static WCHAR categories_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s','\\', > + 'C','a','t','e','g','o','r','i','e','s',0}; > +static WCHAR inputtypesW[] = {'I','n','p','u','t','T','y','p','e','s',0}; > +static WCHAR outputtypesW[] = {'O','u','t','p','u','t','T','y','p','e','s',0}; Shouldn't those be constants too? > +static const WCHAR szGUIDFmt[] = > +{ > + '%','0','8','x','-','%','0','4','x','-','%','0','4','x','-','%','0', > + '2','x','%','0','2','x','-','%','0','2','x','%','0','2','x','%','0','2', > + 'x','%','0','2','x','%','0','2','x','%','0','2','x',0 > +}; > + > +static LPWSTR GUIDToString(LPWSTR lpwstr, REFGUID lpcguid) > +{ > + wsprintfW(lpwstr, szGUIDFmt, lpcguid->Data1, lpcguid->Data2, > + lpcguid->Data3, lpcguid->Data4[0], lpcguid->Data4[1], > + lpcguid->Data4[2], lpcguid->Data4[3], lpcguid->Data4[4], > + lpcguid->Data4[5], lpcguid->Data4[6], lpcguid->Data4[7]); > + > + return lpwstr; > +} It's easier to use sprintfW() here. Please for consistency remove the rest of LP* types and prefixed names. > + > BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > { > switch (reason) > @@ -46,6 +75,121 @@ BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > return TRUE; > } > > +static HRESULT register_transform(CLSID *clsid, WCHAR *name, > + UINT32 cinput, MFT_REGISTER_TYPE_INFO *input_types, > + UINT32 coutput, MFT_REGISTER_TYPE_INFO *output_types) > +{ > + HKEY htransform, hclsid = 0; > + WCHAR buffer[64]; > + GUID *types; > + DWORD size; > + LONG ret; > + UINT32 i; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, transform_keyW, &htransform)) > + return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htransform, buffer, &hclsid); > + RegCloseKey(htransform); > + if (ret) return E_FAIL; > + > + size = (strlenW(name) + 1) * sizeof(WCHAR); > + if (RegSetValueExW(hclsid, NULL, 0, REG_SZ, (BYTE *)name, size)) > + goto err; > + > + if (cinput && input_types) > + { > + size = 2 * cinput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < cinput; i++) > + { > + memcpy(&types[2 * i], &input_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &input_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + if (coutput && output_types) > + { > + size = 2 * coutput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < coutput; i++) > + { > + memcpy(&types[2 * i], &output_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &output_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, outputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + RegCloseKey(hclsid); > + return S_OK; > + > +err: > + RegCloseKey(hclsid); > + return E_FAIL; > +} > + > +static HRESULT register_category(CLSID *clsid, GUID *category) > +{ > + HKEY hcategory, htmp1, htmp2; > + WCHAR buffer[64]; > + DWORD ret; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, category); > + ret = RegCreateKeyW(hcategory, buffer, &htmp1); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htmp1, buffer, &htmp2); > + RegCloseKey(htmp1); > + if (ret) return E_FAIL; > + > + RegCloseKey(htmp2); > + return S_OK; > +} > + > +/*********************************************************************** > + * MFTRegister (mfplat.@) > + */ > +HRESULT WINAPI MFTRegister(CLSID clsid, GUID category, LPWSTR name, UINT32 flags, UINT32 cinput, > + MFT_REGISTER_TYPE_INFO *input_types, UINT32 coutput, > + MFT_REGISTER_TYPE_INFO *output_types, void *attributes) This should use proper type for last argument. > +{ > + HRESULT hr; > + > + FIXME("(%s, %s, %s, %x, %u, %p, %u, %p, %p)\n", debugstr_guid(&clsid), debugstr_guid(&category), > + debugstr_w(name), flags, cinput, input_types, > + coutput, output_types, attributes); > + Why FIXME? > + if (attributes) > + FIXME("attributes not yet supported.\n"); > + > + if (flags) > + FIXME("flags not yet supported.\n"); > + > + hr = register_transform(&clsid, name, cinput, input_types, coutput, output_types); > + > + if (SUCCEEDED(hr)) > + hr = register_category(&clsid, &category); > + > + return hr; > +}

1 0

Re: [PATCH 5/9] d3dx9: Store effect creation flags in struct d3dx_base_effect.
by Matteo Bruni 27 Apr '17

27 Apr '17

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/effect.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index c2fb1d0..7885241 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -154,6 +154,7 @@ struct d3dx9_base_effect > struct d3dx_object *objects; > > struct d3dx_effect_pool *pool; > + DWORD flags; > }; > > struct ID3DXEffectImpl > @@ -169,7 +170,7 @@ struct ID3DXEffectImpl > struct d3dx_technique *active_technique; > struct d3dx_pass *active_pass; > BOOL started; > - DWORD flags; > + DWORD begin_flags; begin_flags is quite ugly IMO. If you really want to change it from just flags, maybe call it creation_flags.

2 2

Re: [PATCH 4/9] d3dx9/tests: Add test for D3DXFX_LARGEADDRESSAWARE effect creation flag.
by Matteo Bruni 27 Apr '17

27 Apr '17

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 997c1fc..a58352e 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -5743,6 +5743,30 @@ static void test_cross_effect_handle(IDirect3DDevice9 *device) > > effect2->lpVtbl->Release(effect2); > effect1->lpVtbl->Release(effect1); > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, D3DXFX_LARGEADDRESSAWARE, NULL, &effect1, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + param1 = effect1->lpVtbl->GetParameterByName(effect1, NULL, "g_iVect"); > + ok(!!param1, "GetParameterByName failed.\n"); > + > + hr = effect1->lpVtbl->SetValue(effect1, param1, expected_ivect, sizeof(expected_ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = effect1->lpVtbl->GetValue(effect1, param1, ivect, sizeof(ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + ok(!memcmp(ivect, expected_ivect, sizeof(expected_ivect)), "Vector value mismatch.\n"); > + > + if (0) > + { > + /* Native d3dx crashes in GetValue(). */ > + hr = effect1->lpVtbl->GetValue(effect1, "g_iVect", ivect, sizeof(ivect)); > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + } > + > + effect1->lpVtbl->Release(effect1); > } The test is okay but it doesn't feel right to put it in test_cross_effect_handle(). Probably just make a separate function.

1 0

Re: [PATCH 2/3] dwrite: Fix name section strings lookup
by Nikolay Sivov 27 Apr '17

27 Apr '17

On 27.04.2017 17:03, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/opentype.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > The problem with this patch is that we want to continue and add as many strings for different locales as possible. So the condition should set 'exists' to TRUE after first pair was added successfully and never touch it after.

2 3

Re: [PATCH 1/3] dwrite: Don't crash on uninitialized cached and factory fields in dwritefontface_Release
by Nikolay Sivov 27 Apr '17

27 Apr '17

On 27.04.2017 17:03, Piotr Caban wrote: > > The function may be called with the fields uninitialized from > create_fontface when init_font_data fails. > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/font.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > > - factory_release_cached_fontface(This->cached); > - IDWriteFactory4_Release(This->factory); > + if (This->cached) > + factory_release_cached_fontface(This->cached); > + if (This->factory) > + IDWriteFactory4_Release(This->factory); Yes, this makes sense. The problem with this change is that 'cached' and 'factory' are not necessarily NULL on this failure path. I think at this point it would be better to use heap_alloc_zero(), and remove all explicit 0 initialization from create_fontface(). By the way, did you check why init_font_data() fails? If it's because opentype_get_font_familyname() fails, I'm interested in a log, or font file that causes it.

2 3

Re: [PATCH 3/3] dwrite: Fix EUDC font collection use after free issue
by Nikolay Sivov 27 Apr '17

27 Apr '17

On 27.04.2017 17:04, Piotr Caban wrote: > > Without this patch factory_detach_fontcollection incorrectly releases > factory reference. > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/dwrite_private.h | 2 +- > dlls/dwrite/font.c | 6 ++++-- > dlls/dwrite/main.c | 15 ++++++++------- > 3 files changed, 13 insertions(+), 10 deletions(-) > This makes sense, thanks. Please add some test for that in test_GetEudc*, similar to what test_object_lifetime() does in the beginning - testing that collection gets factory reference, but only once.

1 0

Re: [PATCH 2/3] dwrite: Fix name section strings lookup
by Nikolay Sivov 27 Apr '17

27 Apr '17

On 27.04.2017 17:03, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/opentype.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > - if (!(exists = opentype_decode_namerecord(header, storage_area, i, *strings))) > - continue; > + if ((exists = opentype_decode_namerecord(header, storage_area, i, *strings))) > + break; What happens exactly? I guess I'll need a font file for that too.

1 0

Re: [PATCH 1/13] msidb: Add stub tool for manipulating MSI databases.
by Hans Leidekker 27 Apr '17

27 Apr '17

On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote: > +static int open_database( struct msidb_state *state ) > +{ > + LPCWSTR db_mode = state->create_database ? MSIDBOPEN_CREATEDIRECT : MSIDBOPEN_DIRECT; > + UINT ret; > + > + ret = MsiOpenDatabaseW( state->database_file, db_mode, &state->database_handle ); Databases opened in direct mode should always be committed. You should either do that in following patches, or open them in transacted mode.

2 2

Re: [4/4] ole32: Fix IDataObject_GetDataHere may not implement
by Huw Davies 27 Apr '17

27 Apr '17

On Wed, Apr 26, 2017 at 03:45:50PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From 2c5a9b4df394c6d50bcc24bcc7b489a864224155 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:24:00 +0800 > Subject: [PATCH 4/4] ole32: Fix IDataObject_GetDataHere may not implement > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/ole2impl.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/ole32/ole2impl.c b/dlls/ole32/ole2impl.c > index a0c4445..5ee031e 100644 > --- a/dlls/ole32/ole2impl.c > +++ b/dlls/ole32/ole2impl.c > @@ -115,6 +115,10 @@ static HRESULT get_storage(IDataObject *data, IStorage *stg, UINT *src_cf, BOOL > med.u.pstg = stg; > med.pUnkForRelease = NULL; > hr = IDataObject_GetDataHere(data, &fmt, &med); > + if (FAILED(hr)) > + { > + hr = IDataObject_GetData(data, &fmt, &med); > + } This can't work. The STGMEDIUM is an [out]-only parameter of _GetData(), meaning that the callee will return a new stg in the STGMEDIUM. If this is indeed called (we need tests to check), then you'd have to copy the returned stg into the original one. Huw.

1 0

Re: [3/4] ole32: Add init cache code after OleLoad in OleCreateFromDataEx
by Huw Davies 27 Apr '17

27 Apr '17

On Wed, Apr 26, 2017 at 03:46:23PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From a96e73f270745f0694ea340eb8119566d75f1117 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:14:36 +0800 > Subject: [PATCH 3/4] ole32: Add init cache code after OleLoad in > OleCreateFromDataEx > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/ole2impl.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/dlls/ole32/ole2impl.c b/dlls/ole32/ole2impl.c > index ccf31fa..a0c4445 100644 > --- a/dlls/ole32/ole2impl.c > +++ b/dlls/ole32/ole2impl.c > @@ -181,6 +181,7 @@ HRESULT WINAPI OleCreateFromDataEx(IDataObject *data, REFIID iid, DWORD flags, > { > HRESULT hr; > UINT src_cf; > + IOleCache* ole_cache; > > FIXME("(%p, %s, %08x, %08x, %d, %p, %p, %p, %p, %p, %p, %p): stub\n", > data, debugstr_guid(iid), flags, renderopt, num_cache_fmts, adv_flags, cache_fmts, > @@ -193,6 +194,11 @@ HRESULT WINAPI OleCreateFromDataEx(IDataObject *data, REFIID iid, DWORD flags, > if(FAILED(hr)) return hr; > > /* FIXME: Init cache */ > + hr = IUnknown_QueryInterface((IUnknown*)*obj, &IID_IOleCache, (void**)&ole_cache); > + if (SUCCEEDED(hr)) > + { > + hr = IOleCache_InitCache(ole_cache, data); > + } You'll need to release the ole_cache. Again we'll need some tests. Huw.

1 0

Re: [2/4] ole32: Support HBITMAP format in DataCache_GetExtent and DataCache_Draw
by Huw Davies 27 Apr '17

27 Apr '17

On Wed, Apr 26, 2017 at 03:44:01PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From 91b46bc9da357b76b8028d058a191743e9a31a32 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:05:59 +0800 > Subject: [PATCH 2/4] ole32: Support HBITMAP format in DataCache_GetExtent and > DataCache_Draw > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/datacache.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > @@ -1908,6 +1926,40 @@ static HRESULT WINAPI DataCache_GetExtent( > > return S_OK; > } > + case CF_BITMAP: > + { > + HDC hdc; > + char dst_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > + BITMAPINFO *dst_info = (BITMAPINFO *)dst_bmibuf; > + BITMAPINFOHEADER *info; > + LONG x_pels_m, y_pels_m; > + > + if (cache_entry->stgmedium.tymed != TYMED_GDI) > + continue; > + > + hdc = GetDC(NULL); > + memset(dst_info, 0, sizeof(char)*FIELD_OFFSET( BITMAPINFO, bmiColors[256] )); > + dst_info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + > + GetDIBits(hdc, cache_entry->stgmedium.u.hBitmap, 0, 1, NULL, dst_info, DIB_RGB_COLORS); > + > + info = &dst_info->bmiHeader; I'm not convinced adding the info variable helps here. Just use dst_info->bmiHeader throughout. Better still drop the 'dst_' and use BITMAPINFO *info = (BITMAPINFO *)bmibuf; > + x_pels_m = info->biXPelsPerMeter; > + y_pels_m = info->biYPelsPerMeter; > + > + /* Size in units of 0.01mm (ie. MM_HIMETRIC) */ > + if (x_pels_m != 0 && y_pels_m != 0) > + { > + lpsizel->cx = info->biWidth * 100000 / x_pels_m; > + lpsizel->cy = info->biHeight * 100000 / y_pels_m; > + } > + else > + { > + lpsizel->cx = info->biWidth * 2540 / GetDeviceCaps( hdc, LOGPIXELSX ); > + lpsizel->cy = info->biHeight * 2540 / GetDeviceCaps( hdc, LOGPIXELSY ); > + } You need a ReleaseDC(0, hdc); > + return S_OK; > + } > } > } > > -- > 2.10.2 > >

1 0

Re: [1/4] ole32: Implement DataCache_InitCache
by Huw Davies 27 Apr '17

27 Apr '17

On Wed, Apr 26, 2017 at 03:42:59PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control Hi, Thanks for working on this. In general this series in going to need some unit tests to be submitted along with it. There are already some for the data-cache in dlls/ole32/tests/ole2.c. The documentation for IOleCache_InitCache() implies that it supposed to be used after first calling IOleCache_Cache() to specify which formats are to be cached, rather than the way you have implemented it. I'd imagine that OleCache_InitCache() would call IDataObject_GetData() on each of the wanted formats and pass that off to IOleCache_SetData(). Anyway, some tests will confirm this. I'll add a couple of comments to the other patches, but the tests need writing first. [Note, it's "can't" or "cannot", not "cann't"]. Huw.

1 0

Re: [PATCH 5/5] user32/tests: Try to read the dpi from the user key first
by Marvin 27 Apr '17

27 Apr '17

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=30508 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2517: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2528: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit sysparams) === sysparams.c:204: Test failed: Unexpected WM_DISPLAYCHANGE message

2 1

Re: [PATCH v2 08/11] d3d11/tests: Add test for state refcounting.
by Marvin 27 Apr '17

27 Apr '17

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

1 0

Re: [PATCH 1/5] d3dx9/tests: Get rid of compare_rotation.
by Marvin 27 Apr '17

27 Apr '17

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

2 1

Re: [PATCH 5/5] d3dx9/tests: Get rid of compare_planes.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH 4/5] d3dx9/tests: Cleanup compare_vectors.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH 3/5] d3dx9/tests: Get rid of compare_translation.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH 2/5] d3dx9/tests: Get rid of compare_scale.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH] d3dx9: Support parameters sharing in effect.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH] d3dx9/tests: Cleanup expect_vec3.
by Marvin 26 Apr '17

26 Apr '17

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

1 0

Re: [PATCH 1/13] msidb: Add stub tool for manipulating MSI databases.
by Hans Leidekker 26 Apr '17

26 Apr '17

On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote: > + /* process and validate all the command line flags */ > + for (i = 1; n && i < argc; i += n) > + n = process_argument( &state, i, argc, argv ); > + if (!valid_state( &state )) > + return 1; > + > + /* perform the requested operations */ > + if (!open_database( &state )) > + { > + ERR( "Failed to open database '%s'.\n", wine_dbgstr_w(state.database_file) ); For programs it should be WINE_ERR, etc.

2 1

Re: po: Update Simplified Chinese translation.
by Alexandre Julliard 26 Apr '17

26 Apr '17

Jactry Zeng <jzeng(a)codeweavers.com> writes: > diff --git a/po/zh_CN.po b/po/zh_CN.po > index 45103bf3e4..f2addad1a5 100644 > --- a/po/zh_CN.po > +++ b/po/zh_CN.po > @@ -27,7 +27,7 @@ msgstr "Š»œçŒ¡ç®£çºŒ¯æ'®£'" > > #: appwiz.rc:62 > msgid "&Install..." > -msgstr "®£(&I)" > +msgstr "®£(&I)..." Is it really necessary to change all the ellipsis characters? They were changed the other way around not so long ago. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v4 PATCH] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Huw Davies 26 Apr '17

26 Apr '17

On Wed, Apr 26, 2017 at 12:46:49AM +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index f28d464..475b74e 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -65,6 +65,7 @@ static const WCHAR odbc_error_invalid_param_string[] = {'I','n','v','a','l','i', > static const WCHAR odbc_error_invalid_dsn[] = {'I','n','v','a','l','i','d',' ','D','S','N',0}; > static const WCHAR odbc_error_load_lib_failed[] = {'L','o','a','d',' ','L','i','b','r','a','r','y',' ','F','a','i','l','e','d',0}; > static const WCHAR odbc_error_request_failed[] = {'R','e','q','u','e','s','t',' ','F','a','i','l','e','d',0}; > +static const WCHAR odbc_error_invalid_keyword[] = {'I','n','v','a','l','i','d',' ','k','e','y','w','o','r','d',' ','v','a','l','u','e',0}; > > /* Push an error onto the error stack, taking care of ranges etc. */ > static void push_error(int code, LPCWSTR msg) > @@ -303,6 +304,64 @@ static HMODULE load_config_driver(const WCHAR *driver) > return hmod; > } > > +static BOOL write_config_value(const WCHAR *driver, const WCHAR *args) > +{ > + long ret; > + HKEY hkey, hkeydriver; > + WCHAR *name = NULL; > + > + if (!args) > + return FALSE; > + > + if ((ret = RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + WCHAR *divider, *value; > + > + name = heap_alloc( (strlenW(args) + 1) * sizeof(WCHAR)); > + if(!name) > + { > + push_error(ODBC_ERROR_OUT_OF_MEM, odbc_error_out_of_mem); > + goto fail; > + } > + lstrcpyW(name, args); > + > + divider = strchrW(name,'='); > + if(!divider) > + { > + push_error(ODBC_ERROR_INVALID_KEYWORD_VALUE, odbc_error_invalid_keyword); > + goto fail; > + } > + > + value = divider + 1; > + *divider = '\0'; > + > + TRACE("Write pair: %s = %s\n", debugstr_w(name), debugstr_w(value)); > + if(RegSetValueExW(hkeydriver, name, 0, REG_SZ, (BYTE*)value, > + strlenW(value) * sizeof(WCHAR)) != ERROR_SUCCESS) The length should be (strlenW(value) + 1) * sizeof(WCHAR). Sorry, I missed that last time. While you're at it, decide whether you're going to use a space after 'if' or not, and then be consistent. Otherwise, this looks good. Huw.

1 0

Re: [PATCH v2 1/2] mountmgr: Create devices and registry entries for serial ports.
by Alexandre Julliard 26 Apr '17

26 Apr '17

Alex Henrie <alexhenrie24(a)gmail.com> writes: > + if (driver == serial_driver) > + { > + dos_name_format = comW; > + nt_name_format = device_serialW; > + reg_value_format = comW; > + } > + else > + { > + /* TODO: support parallel ports */ > + } Please avoid introducing dead code. You can add the if() in the second patch. > + /* remove old symlinks */ > + for (n = 1; n <= MAX_PORTS; n++) > + { > + sprintf( p, "%u", n ); > + if (unlink( dosdevices_path ) != 0 && !errno) > + break; > + } Why would errno ever be 0 here? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dmscript/tests: Use a void* instead of void** outer IUnknown argument
by Marvin 25 Apr '17

25 Apr '17

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=30436 Your paranoid android. === wxppro (32 bit dmscript) === dmscript.c:146: Test failed: DirectMusicScriptTrack create failed: 80004003, expected CLASS_E_NOAGGREGATION === wvistau64 (32 bit dmscript) === 01f4:dmscript: unhandled exception c0000005 at 73E47D60 === w7u (32 bit dmscript) === 0ac8:dmscript: unhandled exception c0000005 at 72157EA8 === w7pro64 (32 bit dmscript) === 0978:dmscript: unhandled exception c0000005 at 73907EA8 === w8 (32 bit dmscript) === 0938:dmscript: unhandled exception c0000005 at 69E4804C === w864 (32 bit dmscript) === 0f8c:dmscript: unhandled exception c0000005 at 7451804C === w1064 (32 bit dmscript) === 02bc:dmscript: unhandled exception c0000005 at 7078945E

2 1

Re: [v2 6/6] d3dx9: Support parameters sharing in effect.
by Matteo Bruni 25 Apr '17

25 Apr '17

2017-04-24 13:36 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct d3dx_shared_data > +{ > + void *data; > + LONG refcount; > + struct d3dx_parameter **parameters; > + unsigned int table_size; > +}; A bit nitpicky but generally for those dynamic arrays we call "refcount" "count" and "table_size" "size". > + new_refcount = InterlockedIncrement(&pool->shared_data[i].refcount); I think you don't need the Interlocked functions for this count given that adding / removing multiple effects to a pool is expected to be racy. > + if (new_refcount >= pool->shared_data[i].table_size) > + { > + if (!pool->shared_data[i].table_size) > + { > + new_size = INITIAL_SHARED_DATA_TABLE_SIZE; > + pool->shared_data[i].parameters = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*pool->shared_data[i].parameters) * INITIAL_SHARED_DATA_TABLE_SIZE); > + } > + else > + { > + new_size = pool->shared_data[i].table_size * 2; > + pool->shared_data[i].parameters = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + pool->shared_data[i].parameters, > + sizeof(*pool->shared_data[i].parameters) * new_size); > + } > + pool->shared_data[i].table_size = new_size; > + } > + > + param->shared_data = &pool->shared_data[i]; > + pool->shared_data[i].parameters[new_refcount - 1] = param; > + > + TRACE("name %s, parameter idx %u, new refcount %u.\n", param->name, i, > + new_refcount); > + return; > +} Unnecessary return. > +static BOOL param_zero_data_func(void *dummy, struct d3dx_parameter *param) > +{ > + param->data = NULL; > + return FALSE; > +} > + > +static void d3dx_pool_release_shared_parameter(struct d3dx_parameter *param) > +{ > + LONG new_refcount; > + > + if (!(param->flags & PARAMETER_FLAG_SHARED) || !param->shared_data) > + return; No need to check for the PARAMETER_FLAG_SHARED flag. Maybe it makes sense to assert that the flag is there if param->shared_data is not NULL. > static void free_effect_pool(struct d3dx_effect_pool *pool) > { > + unsigned int i; > + > + for (i = 0; i < pool->table_size; ++i) > + { > + if (pool->shared_data[i].refcount) > + ERR("Releasing pool with referenced parameters, shared data is not freed.\n"); > + } This can be triggered by an application so it should be a WARN(). BTW, this probably needs a test. On pool destruction, the effects still using it might be "unshared" i.e. data from the pool might be moved back to the effects. Or maybe the effects still using the pool are simply broken and accessing parameter data after the pool is destroyed crashes.

2 6

Re: [PATCH 2/5] ddraw: Ignore unsupported blit flags.
by Matteo Bruni 25 Apr '17

25 Apr '17

2017-04-24 23:31 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/ddraw/surface.c | 24 +++++++++++++++++++++--- > dlls/ddraw/tests/ddraw1.c | 4 ++-- > dlls/ddraw/tests/ddraw2.c | 4 ++-- > dlls/ddraw/tests/ddraw4.c | 4 ++-- > dlls/ddraw/tests/ddraw7.c | 4 ++-- > 5 files changed, 29 insertions(+), 11 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 6c4ed11..90731f0 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -1570,6 +1570,7 @@ static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 * > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface7(iface); > struct ddraw_surface *src_impl = unsafe_impl_from_IDirectDrawSurface7(src_surface); > struct wined3d_blt_fx wined3d_fx; > + DWORD unsupported_flags; > DWORD fill_colour = 0; > HRESULT hr = DD_OK; > DDBLTFX rop_fx; > @@ -1577,9 +1578,26 @@ static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 * > TRACE("iface %p, dst_rect %s, src_surface %p, src_rect %s, flags %#x, fx %p.\n", > iface, wine_dbgstr_rect(dst_rect), src_surface, wine_dbgstr_rect(src_rect), flags, fx); > > - /* Check for validity of the flags here. WineD3D Has the software-opengl selection path and would have > - * to check at 2 places, and sometimes do double checks. This also saves the call to wined3d :-) > - */ > + unsupported_flags = DDBLT_ALPHADEST > + | DDBLT_ALPHADESTCONSTOVERRIDE > + | DDBLT_ALPHADESTNEG > + | DDBLT_ALPHADESTSURFACEOVERRIDE > + | DDBLT_ALPHAEDGEBLEND > + | DDBLT_ALPHASRC > + | DDBLT_ALPHASRCCONSTOVERRIDE > + | DDBLT_ALPHASRCNEG > + | DDBLT_ALPHASRCSURFACEOVERRIDE > + | DDBLT_ZBUFFER > + | DDBLT_ZBUFFERDESTCONSTOVERRIDE > + | DDBLT_ZBUFFERDESTOVERRIDE > + | DDBLT_ZBUFFERSRCCONSTOVERRIDE > + | DDBLT_ZBUFFERSRCOVERRIDE; Hardly going to matter but wouldn't it be better as a static const?

2 1

Re: [v4 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin 25 Apr '17

25 Apr '17

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

1 0

Re: [v2 4/6] d3dx9: Reference effect pool implementation in d3dx9_base_effect structure.
by Matteo Bruni 25 Apr '17

25 Apr '17

2017-04-24 13:36 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > /*** IUnknown methods ***/ > -static HRESULT WINAPI ID3DXEffectPoolImpl_QueryInterface(ID3DXEffectPool *iface, REFIID riid, void **object) > +static HRESULT WINAPI d3dx_effect_pool_QueryInterface(ID3DXEffectPool *iface, REFIID riid, void **object) > { > TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), object); Please update / cleanup this TRACE too. > -static ULONG WINAPI ID3DXEffectPoolImpl_AddRef(ID3DXEffectPool *iface) > +static ULONG WINAPI d3dx_effect_pool_AddRef(ID3DXEffectPool *iface) > { > - struct ID3DXEffectPoolImpl *This = impl_from_ID3DXEffectPool(iface); > + struct d3dx_effect_pool *pool = impl_from_ID3DXEffectPool(iface); > > - TRACE("(%p)->(): AddRef from %u\n", This, This->ref); > + TRACE("iface %p, pool %p, ref %u.\n", iface, pool, pool->ref); Tracing both iface and pool doesn't seem useful and I don't think I've ever seen it anywhere else. Also for AddRef() we usually go with a TRACE in the form: TRACE("%p increasing refcount to %u.\n", iface, refcount); Similarly for Release(). Have a look at recent implementations of the IUnknown functions like e.g. d3d11_hull_shader_* in dlls/d3d11/shader.c.

1 0

Re: [PATCH 1/4] comdlg32: Release the returned imagelist.
by Huw Davies 25 Apr '17

25 Apr '17

On Tue, Apr 25, 2017 at 09:04:56AM +0100, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/comdlg32/filedlg.c | 2 ++ > 1 file changed, 2 insertions(+) Actually, while this is correct, could you skip it for now? I'm going to have to make other changes to this area, so it would be better to hold off committing this one. The other patches in the series are still good. Huw.

1 0

Re: [PATCH 2/4] regedit: Simplify parseKeyName()
by Alexandre Julliard 25 Apr '17

25 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > - > - for (i = 0; i < ARRAY_SIZE(reg_class_keys); i++) { > - if (CompareStringW(LOCALE_USER_DEFAULT, 0, lpKeyName, len, reg_class_namesW[i], -1) == CSTR_EQUAL && > - len == lstrlenW(reg_class_namesW[i])) { > + num_class_keys = ARRAY_SIZE(reg_class_keys); > + for (i = 0; i < num_class_keys; i++) > + { > + if (!strncmpW(lpKeyName, reg_class_namesW[i], lstrlenW(reg_class_namesW[i]))) > + { You still need to check that the lengths match. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] wined3d: Check pointer before use
by Józef Kucia 25 Apr '17

25 Apr '17

On Tue, Apr 25, 2017 at 8:01 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Test was provided by Józef Kucia. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=42873 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3d11/tests/d3d11.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/context.c | 2 +- > 2 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c > index dfe50c6287..2961cc06cb 100644 > --- a/dlls/d3d11/tests/d3d11.c > +++ b/dlls/d3d11/tests/d3d11.c > @@ -17567,6 +17567,63 @@ done: > release_test_context(&test_context); > } > > +static void test_destroyed_wined3d_context_query_poll(void) FWIW, I'm not sure if we want to use this name for the test. I'm sorry that I haven't mentioned this earlier in the bug report. > --- a/dlls/wined3d/context.c > +++ b/dlls/wined3d/context.c > @@ -3968,7 +3968,7 @@ struct wined3d_context *context_reacquire(const struct wined3d_device *device, > { > struct wined3d_context *current_context; > > - if (context->tid != GetCurrentThreadId()) > + if (!context || context->tid != GetCurrentThreadId()) > return NULL; > > current_context = context_acquire(device, context->current_rt.texture, I think it's fine to do a NULL check in context_reacquire(), and it should be good enough in practice (i.e. this corner case shouldn't matter much). However we may want to handle this correctly in the future. I think it may be good idea to add a similar test for D3D11_QUERY_OCCLUSION (or replace this one). For the occlusion query we want to additionally test the result of the query which is expected to be incorrect (todo_wine).

1 0

Re: [PATCH] programs/winecfg: enable CSMT checkbox on Graphics tab
by Henri Verbeet 25 Apr '17

25 Apr '17

On 24 April 2017 at 23:01, Donat Enikeev <donat(a)enikeev.net> wrote: > @@ -181,6 +181,9 @@ BEGIN > EDITTEXT IDC_RES_DPIEDIT,188,105,23,13,ES_NUMBER|WS_TABSTOP > LTEXT "#msgctxt#unit: dots/inch#dpi",IDC_STATIC,215,107,30,8 > LTEXT "This is a sample text using 10 point Tahoma",IDC_RES_FONT_PREVIEW,15,124,230,49 > + > + GROUPBOX "CSMT",IDC_STATIC,8,186,244,32 > + CONTROL "Enable multi-threaded command stream in Direct3D",IDC_ENABLE_CSMT,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,15,202,230,8 > END > > IDD_DLLCFG DIALOG 0, 0, 260, 220 I don't think so, this is not a setting regular users should be modifying.

2 3

`setupapi` patch from staging
by Donat Enikeev 24 Apr '17

24 Apr '17

Hi Guys, Number of recent well-known games are based on Starling game engine (Adobe Air+Stage3D for gpu rendering), such as: The Banner Saga 2, Samorost 3, The Inner World, Angry Birds. They are are falling into Software rendering mode on plain Wine and thus barely playable (bug #41635) Thanks to Béla Gyebrószki finding @ bug #41653, Wine makes these games consider d3d9 rendering with the following single patch from wine-staging https://github.com/wine-compholio/wine-staging/blob/master/patches/setupapi… This patch implements support of the case when a full driver path is passed to SetupDiGetClassDevs (trace successfully reaching AddDeviceToSet for a game below [1]). I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests? I am asking this, because Adobe stopped Linux support for the Air years ago and we could never see such games ported, and therefore plain Wine's support of gpu acceleration for such games looks important. Thanks in advance Best regards, Donnie [1] 0009:trace:setupapi:SetupDiGetClassDevsExW {4d36e968-e325-11ce-bfc1-08002be10318} L"PCI\\VEN_0000&DEV_0000" (nil) 0x0000000a (nil) (null) (nil) 0009:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 0000000a 0009:trace:setupapi:SetupDiCreateDeviceInfoListExW {4d36e968-e325-11ce-bfc1-08002be10318} (nil) (null) (nil) 0009:trace:setupapi:SETUPDI_EnumerateDevices 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, L"PCI\\VEN_0000&DEV_0000", 0000000a 0009:trace:setupapi:SETUPDI_EnumerateMatchingDeviceInstances L"PCI" L"VEN_0000&DEV_0000" 0009:trace:setupapi:SETUPDI_AddDeviceToSet 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, 0, L"PCI\\VEN_0000&DEV_0000\\13&12345&0", 0

3 6

Re: [PATCH] wined3d: Add Nvidia TitanX (Pascal)
by Henri Verbeet 24 Apr '17

24 Apr '17

On 23 April 2017 at 21:12, Christopher Berner <christopherberner(a)gmail.com> wrote: > + {HW_VENDOR_NVIDIA, CARD_NVIDIA_TITANX_PASCAL, "NVIDIA TITAN X (Pascal)", DRIVER_NVIDIA_GEFORCE8, 12288}, Is that really what it's called by the Windows driver?

2 1

Re: [PATCH] shell32/ebrowser: Added IOleWindow stub for IExplorerBrowser
by Huw Davies 24 Apr '17

24 Apr '17

On Mon, Apr 24, 2017 at 08:50:09AM +0300, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/shell32/ebrowser.c | 56 +++++++++++++++++++++++++++++++++++++++++++ > dlls/shell32/tests/ebrowser.c | 2 +- > 2 files changed, 57 insertions(+), 1 deletion(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index bbccf88814..77c727a5ec 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -56,6 +56,7 @@ typedef struct _ExplorerBrowserImpl { > IShellBrowser IShellBrowser_iface; > ICommDlgBrowser3 ICommDlgBrowser3_iface; > IObjectWithSite IObjectWithSite_iface; > + IOleWindow IOleWindow_iface; > INameSpaceTreeControlEvents INameSpaceTreeControlEvents_iface; > IInputObject IInputObject_iface; > LONG ref; IShellBrowser inherits IOleWindow, so you don't need this. Huw.

2 1

Re: [PATCH] comctl32/taskdialog: Implement buttons.
by Nikolay Sivov 24 Apr '17

24 Apr '17

On 23.03.2017 21:22, Fabian Maurer wrote: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/comctl32/taskdialog.c | 224 ++++++++++++++++++++++++++++++++------------- > 1 file changed, 161 insertions(+), 63 deletions(-) > > diff --git a/dlls/comctl32/taskdialog.c b/dlls/comctl32/taskdialog.c > index 6b8bcfcae6..037b85e082 100644 > --- a/dlls/comctl32/taskdialog.c > +++ b/dlls/comctl32/taskdialog.c > @@ -41,10 +41,13 @@ WINE_DEFAULT_DEBUG_CHANNEL(taskdialog); > #define ALIGN_LENGTH(_Len, _Align) _Len = ALIGNED_LENGTH(_Len, _Align) > #define ALIGN_POINTER(_Ptr, _Align) _Ptr = ALIGNED_POINTER(_Ptr, _Align) > > -static const UINT DIALOG_MIN_WIDTH = 180; > +static const UINT DIALOG_MIN_WIDTH = 240; > static const UINT DIALOG_SPACING = 5; > -static const UINT DIALOG_BUTTON_WIDTH = 50; > -static const UINT DIALOG_BUTTON_HEIGHT = 14; > +static const UINT DIALOG_BUTTON_WIDTH_MIN = 45; > +static const UINT DIALOG_BUTTON_HEIGHT = 13; This was taken from MSGBOX template, what's a point in making it different? > +static const UINT DIALOG_SPACING_BUTTONS_LEFT = 30; /* minimum distance from the left dialog border */ > +static const UINT DIALOG_SPACING_BUTTON_H = 1; /* Distance between buttons */ > +static const UINT DIALOG_SPACING_BUTTON_W = 4; /* Distance between buttons */ > > static const UINT ID_MAIN_INSTRUCTION = 0xf000; > > @@ -67,6 +70,15 @@ struct taskdialog_template_desc > HFONT font; > }; > > +typedef struct > +{ > + int id; > + const WCHAR *text; > + UINT width; > + UINT x; > + UINT y; > +} button_info; > + > static void pixels_to_dialogunits(const struct taskdialog_template_desc *desc, LONG *width, LONG *height) > { > if (width) > @@ -83,6 +95,44 @@ static void dialogunits_to_pixels(const struct taskdialog_template_desc *desc, L > *height = MulDiv(*height, desc->y_baseunit, 8); > } > > +/* used to calculate size for the controls */ > +static RECT text_get_rect(const struct taskdialog_template_desc *desc, const WCHAR *text) > +{ > + const WCHAR *textW = NULL; > + unsigned int length; > + HFONT oldfont; > + HDC hdc; > + static const WCHAR nulW; > + RECT rect = { 0, 0, desc->dialog_width - DIALOG_SPACING * 2, 0}; /* padding left and right of the control */ > + > + if (IS_INTRESOURCE(text)) > + { > + if (!(length = LoadStringW(desc->taskconfig->hInstance, (UINT_PTR)text, (WCHAR *)&textW, 0))) > + { > + WARN("Failed to load text\n"); > + textW = &nulW; > + length = 0; > + } > + } > + else > + { > + textW = text; > + length = strlenW(textW); > + } > + > + hdc = GetDC(0); > + oldfont = SelectObject(hdc, desc->font); > + > + dialogunits_to_pixels(desc, &rect.right, NULL); > + DrawTextW(hdc, textW, length, &rect, DT_LEFT | DT_EXPANDTABS | DT_CALCRECT | DT_WORDBREAK); > + pixels_to_dialogunits(desc, &rect.right, &rect.bottom); > + > + SelectObject(hdc, oldfont); > + ReleaseDC(0, hdc); > + > + return rect; > +} > + Did you test that buttons are supposed to support multiple lines of text? > static void template_write_data(char **ptr, const void *src, unsigned int size) > { > memcpy(*ptr, src, size); > @@ -90,7 +140,7 @@ static void template_write_data(char **ptr, const void *src, unsigned int size) > } > > static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc, WORD id, const WCHAR *class, > - HINSTANCE hInstance, const WCHAR *text, short x, short y, short cx, short cy) > + DWORD style, HINSTANCE hInstance, const WCHAR *text, short x, short y, short cx, short cy) > { > struct taskdialog_control *control = Alloc(sizeof(*control)); > unsigned int size, class_size, text_size; > @@ -117,7 +167,7 @@ static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc > control->template = template = Alloc(size); > control->template_size = size; > > - template->style = WS_VISIBLE; > + template->style = WS_VISIBLE | WS_CHILD | style; You don't use styles in this patch, this is unnecessary change. > template->dwExtendedStyle = 0; > template->x = x; > template->y = y; > @@ -136,78 +186,126 @@ static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc > > static unsigned int taskdialog_add_main_instruction(struct taskdialog_template_desc *desc) > { > - RECT rect = { 0, 0, desc->dialog_width - DIALOG_SPACING * 2, 0}; /* padding left and right of the control */ > - const WCHAR *textW = NULL; > - unsigned int size, length; > - HFONT oldfont; > - HDC hdc; > + unsigned int size; > + RECT rect; > > if (!desc->taskconfig->pszMainInstruction) > return 0; > > - if (IS_INTRESOURCE(desc->taskconfig->pszMainInstruction)) > - { > - if (!(length = LoadStringW(desc->taskconfig->hInstance, (UINT_PTR)desc->taskconfig->pszMainInstruction, > - (WCHAR *)&textW, 0))) > - { > - WARN("Failed to load main instruction text\n"); > - return 0; > - } > - } > - else > - { > - textW = desc->taskconfig->pszMainInstruction; > - length = strlenW(textW); > - } > - > - hdc = GetDC(0); > - oldfont = SelectObject(hdc, desc->font); > - > - dialogunits_to_pixels(desc, &rect.right, NULL); > - DrawTextW(hdc, textW, length, &rect, DT_LEFT | DT_EXPANDTABS | DT_CALCRECT | DT_WORDBREAK); > - pixels_to_dialogunits(desc, &rect.right, &rect.bottom); > - > - SelectObject(hdc, oldfont); > - ReleaseDC(0, hdc); > + rect = text_get_rect(desc, desc->taskconfig->pszMainInstruction); > > - size = taskdialog_add_control(desc, ID_MAIN_INSTRUCTION, WC_STATICW, desc->taskconfig->hInstance, > + size = taskdialog_add_control(desc, ID_MAIN_INSTRUCTION, WC_STATICW, 0, desc->taskconfig->hInstance, > desc->taskconfig->pszMainInstruction, DIALOG_SPACING, desc->dialog_height, > rect.right, rect.bottom); > - desc->dialog_height += rect.bottom; > + desc->dialog_height += rect.bottom + DIALOG_SPACING; > return size; > } > > -static unsigned int taskdialog_add_common_buttons(struct taskdialog_template_desc *desc) > +static button_info make_button(struct taskdialog_template_desc *desc, int id, const WCHAR *text) > +{ > + RECT rect; > + button_info button; > + > + button.id = id; > + button.text = text; > + rect = text_get_rect(desc, text); > + button.width = rect.right + 10; > + if (button.width < DIALOG_BUTTON_WIDTH_MIN) > + button.width = DIALOG_BUTTON_WIDTH_MIN; > + > + return button; > +} This does not handle "text" correctly. > + > +static unsigned int taskdialog_add_buttons(struct taskdialog_template_desc *desc) > { > - short button_x = desc->dialog_width - DIALOG_BUTTON_WIDTH - DIALOG_SPACING; > DWORD flags = desc->taskconfig->dwCommonButtons; > + const TASKDIALOGCONFIG *taskconfig = desc->taskconfig; > + UINT alignment = DIALOG_SPACING_BUTTONS_LEFT; /* minimum distance from the left dialog border */ > + UINT location_x; > + BOOL first_row = TRUE; > + button_info *buttons; > + int count = 0; > + int i; > unsigned int size = 0; > > -#define TASKDIALOG_ADD_COMMON_BUTTON(id) \ > - do { \ > - size += taskdialog_add_control(desc, ID##id, WC_BUTTONW, COMCTL32_hModule, MAKEINTRESOURCEW(IDS_BUTTON_##id), \ > - button_x, desc->dialog_height + DIALOG_SPACING, DIALOG_BUTTON_WIDTH, DIALOG_BUTTON_HEIGHT); \ > - button_x -= DIALOG_BUTTON_WIDTH + DIALOG_SPACING; \ > - } while(0) > - if (flags & TDCBF_CLOSE_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(CLOSE); > - if (flags & TDCBF_CANCEL_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(CANCEL); > - if (flags & TDCBF_RETRY_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(RETRY); > - if (flags & TDCBF_NO_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(NO); > - if (flags & TDCBF_YES_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(YES); > + /* Allocate enough memory for the custom and the default buttons */ > + if (taskconfig->cButtons && taskconfig->pButtons) > + buttons = HeapAlloc(GetProcessHeap(), 0, (taskconfig->cButtons + 6) * sizeof(button_info)); > + else > + { > + buttons = HeapAlloc(GetProcessHeap(), 0, 6 * sizeof(button_info)); > + } > + > + /* Custom buttons */ > + if (taskconfig->cButtons && taskconfig->pButtons) > + { > + for (i = 0; i < taskconfig->cButtons; i++) > + { > + buttons[count++] = make_button(desc, taskconfig->pButtons[i].nButtonID, taskconfig->pButtons[i].pszButtonText); > + } > + } > + > + /* Default buttons */ > if (flags & TDCBF_OK_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > - /* Always add OK button */ > - if (list_empty(&desc->controls)) > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > -#undef TASKDIALOG_ADD_COMMON_BUTTON > - > - /* make room for common buttons row */ > - desc->dialog_height += DIALOG_BUTTON_HEIGHT + 2 * DIALOG_SPACING; > + buttons[count++] = make_button(desc, IDOK, MAKEINTRESOURCEW(IDS_BUTTON_OK)); > + if (flags & TDCBF_YES_BUTTON) > + buttons[count++] = make_button(desc, IDYES, MAKEINTRESOURCEW(IDS_BUTTON_YES)); > + if (flags & TDCBF_NO_BUTTON) > + buttons[count++] = make_button(desc, IDNO, MAKEINTRESOURCEW(IDS_BUTTON_NO)); > + if (flags & TDCBF_RETRY_BUTTON) > + buttons[count++] = make_button(desc, IDRETRY, MAKEINTRESOURCEW(IDS_BUTTON_RETRY)); > + if (flags & TDCBF_CANCEL_BUTTON) > + buttons[count++] = make_button(desc, IDCANCEL, MAKEINTRESOURCEW(IDS_BUTTON_CANCEL)); > + if (flags & TDCBF_CLOSE_BUTTON) > + buttons[count++] = make_button(desc, IDCLOSE, MAKEINTRESOURCEW(IDS_BUTTON_CLOSE)); > + > + /* There must be at least one button */ > + if (count == 0) > + buttons[count++] = make_button(desc, IDOK, MAKEINTRESOURCEW(IDS_BUTTON_OK)); > + > + /* Position buttons */ > + location_x = alignment; > + for (i = 0; i < count; i++) > + { > + /* When beginning new row, align the first */ > + if (location_x + buttons[i].width + DIALOG_SPACING_BUTTON_W > desc->dialog_width) > + { > + if (first_row) > + { > + int diff = desc->dialog_width - location_x; > + > + first_row = FALSE; > + for (int j = 0; j < i; j++) /* Align first row to the right */ > + buttons[j].x += diff; > + alignment = buttons[0].x; /* left-align all coming rows to the first row */ > + } > + location_x = alignment; > + desc->dialog_height += DIALOG_BUTTON_HEIGHT + DIALOG_SPACING_BUTTON_H; > + } > + > + buttons[i].x = location_x; > + buttons[i].y = desc->dialog_height; > + > + location_x += buttons[i].width + DIALOG_SPACING_BUTTON_W; > + } > + if (first_row) /* Always align first row to the right */ > + { > + int diff = desc->dialog_width - (buttons[count - 1].x + buttons[count - 1].width + DIALOG_SPACING_BUTTON_W); > + for (int i = 0; i < count; i++) > + buttons[i].x += diff; > + } I don't like this. Why do you need temporary array, and iterating twice seems excessive. > + > + /* Now that we got them all positioned, create all buttons */ > + for (i = 0; i < count; i++) > + { > + size += taskdialog_add_control(desc, buttons[i].id, WC_BUTTONW, BS_PUSHBUTTON, COMCTL32_hModule, > + buttons[i].text, buttons[i].x, buttons[i].y, buttons[i].width, DIALOG_BUTTON_HEIGHT); > + } This won't work for custom buttons. > + > + /* Add height for last row and spacing */ > + desc->dialog_height += DIALOG_BUTTON_HEIGHT + DIALOG_SPACING; > + > + HeapFree(GetProcessHeap(), 0, buttons); > return size; > } > > @@ -295,7 +393,7 @@ static DLGTEMPLATE *create_taskdialog_template(const TASKDIALOGCONFIG *taskconfi > desc.dialog_width = min(desc.dialog_width, screen_width); > > size += taskdialog_add_main_instruction(&desc); > - size += taskdialog_add_common_buttons(&desc); > + size += taskdialog_add_buttons(&desc); I'd rather have it separated if possible. I'll do some testing myself, before commenting further. > > template = Alloc(size); > if (!template) >

2 8

Build server and Staging patch submission
by Michael Müller 24 Apr '17

24 Apr '17

Hi all, I would like to announce some changes regarding the build server and the patch submission for Wine Staging. As already mentioned in the last email about the packaging changes, one of the main ideas was to implement an easy to use web interface, so that wine developers can create their own builds. As you can most probably imagine, such a system is quite complex (updating VMs, building packages, signing packages, updating repos, synchronizing files, ...) but I think we have now reached a state in which we can put the system into a public beta. There are some tasks left (like adding support for FreeBSD), but the main system works and was already used to create the 2.5, 2.6 and 2.0.1 WineHQ packages. I have created a wiki article which describes how to get access to the builder and basically everything else you need to know. You can find it at https://wiki.winehq.org/Build_Server. There is another change we would like to announce. Since Wine Staging was merged into WineHQ, there was no longer an official way to suggest patches. This lead to a non-transparent system of private emails, requests in bug reports etc. This is not something you would expect from an open source project, so we took the opportunity and also included a patch tracker into the website. Submissions and comments are now public for everyone and you can also subscribe to changes. For more information about the system and how to submit patches, take look at https://wiki.winehq.org/Wine-Staging_Patches. We have tested the patch tracker in a closed beta phase, so you can also find some older submissions there. Both systems are available at https://dev.wine-staging.com/. They use the same login system, so you don't need to registers two accounts. Alternatively, you can just use Github for the login, then just have to verify your email address. Everything else should be described in the corresponding Wiki articles. So, try it out and drop me an email if you find any issues! Regards, Michael

1 0

Re: a-m-w-c-processthreads-l1-1-0: Forward OpenThreadToken() to advapi32.
by Sebastian Lackner 23 Apr '17

23 Apr '17

On 24.04.2017 00:30, Olivier F. R. Dierick wrote: > Copy and paste of the stdcall from the 1.1.1 spec file. > > Application Psyprax needs this [1]. > > [1] https://forum.winehq.org/viewtopic.php?f=9&t=27888 > > Signed-off-by: Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> > --- > .../api-ms-win-core-processthreads-l1-1-0.spec > | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > It would be better to update tools/make_specfiles, so that advapi32 stuff is synchronized automatically for this dll. Best regards, Sebastian

1 0

Re: ntdll: Mark LDR data as initialized.
by Marvin 23 Apr '17

23 Apr '17

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=30362 Your paranoid android. === w7u (32 bit loader) === loader.c:2199: Test failed: expected WAIT_OBJECT_0, got 0x102 loader.c:2209: Test failed: expected thread exit code 196, got 259 loader.c:1713: Test failed: expected thread exit code 196, got 195

1 0

Re: [v3 PATCH 1/2] wined3d: Add dirty region tracking.
by Henri Verbeet 23 Apr '17

23 Apr '17

On 20 April 2017 at 16:01, Masanori Kakura <kakurasan(a)gmail.com> wrote: > v2 - Use array > - Regions are stored in struct wined3d_texture > - Reuse old region if possible > v3 - Update Wine d3d8 test > - Get rid of "Ignoring dirty_region" FIXME in wined3d_texture_add_dirty_region() > > Signed-off-by: Masanori Kakura <kakurasan(a)gmail.com> > --- > dlls/d3d8/tests/visual.c | 10 ++--- > dlls/d3d9/tests/visual.c | 10 ++--- > dlls/wined3d/cs.c | 51 +++++++++++++++++++++- > dlls/wined3d/device.c | 6 +++ > dlls/wined3d/texture.c | 97 ++++++++++++++++++++++++++++++++++++++++-- > dlls/wined3d/wined3d_private.h | 9 +++- > 6 files changed, 167 insertions(+), 16 deletions(-) > Do you have any thoughts on the interactions with the resource location management?

2 2

Re: [PATCH 5/5] ddraw/tests: Introduce a helper function to create windows.
by Marvin 23 Apr '17

23 Apr '17

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=30354 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:3724: Test failed: Lit quad without normals has color 0x00ff0000, expected 0x00000000. ddraw7.c:3728: Test failed: Lit quad with normals has color 0x00ff0000, expected 0x00000000. ddraw7.c:3752: Test failed: Lit quad with light has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with singular world matrix has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with transformation matrix has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with non-affine matrix has color 0x00ff0000.

1 0

Slow emulation of StretchBlt
by andrea 22 Apr '17

22 Apr '17

Hi, I am looking at the performance of AppleWin (a 32 bit app) in Wine and have come across this function StretchBlt which seems to be much slower in Wine that in Windows 10. The call looks like this StretchBlt( hFrameDC, xdest, ydest, wdest, hdest, g_hDeviceDC, xSrc, ySrc, FRAMEBUFFER_BORDERLESS_W, FRAMEBUFFER_BORDERLESS_H, SRCCOPY); With typical values xdest 0 int ydest 0 int wdest 1120 int hdest 768 int xSrc 22 int ySrc 17 int #define FRAMEBUFFER_BORDERLESS_W 560 #define FRAMEBUFFER_BORDERLESS_H 384 In Wine they take 20x the time in Windows 10 (running inside a VirtualBox). The consequence is CPU utilisation 20x higher in Wine than Windows. I am running wine 2.5 in a 64 bit Fedora 25 machine. Does this ring any bell? Andrea

5 6

Debian Download Page
by Stefan Leichter 22 Apr '17

22 Apr '17

Hi, when following the instruction at https://wiki.winehq.org/Debian the command "sudo apt-get update" gives me the error: -------------------------------------------------------------------- W: GPG error: https://dl.winehq.org jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 818A435C5FCBF54A -------------------------------------------------------------------- Does anyone else see the same error? Minor item: Any reason that "wine-stable" is not listed on the download page? Regards Stefan

2 2

Linux desktop integration: Fill StartupWMClass in .desktop menu entries
by Eike Hein 22 Apr '17

22 Apr '17

Hi, I maintain the taskbar in Plasma 5 and would like to poke folks about a desktop integration pain point we (and our friends at other DEs) face with apps run via wine. Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699 Let me give some broader context on this. Modern DEs have a swath of UX going on that relies on being able to identify the application owning a particular window in the windowing system. "Identify the application" in practice means "map the window to a .desktop file installed in the menu file system". We want to do this because: a) Many a taskbar/dock-like UI tries to form a smooth life cycle across "launcher button", "startup notification" and "window button(s)". For each of those we need to work out the app they are associated with to be able to match them up. If it fails, ugly things like co-existing task buttons or missing startup throbbers and similar happen. b) UI these days tends to prefer to load assets such as app icons via the values defined in .desktop files instead of using the window icon, to ensure consistent results (apps may load icon assets differently from the shell, leading to asset quality issues, inconsistent theming, the icon changing between the lifecycle states mentioned in 'a', etc.) Plus the Wayland windowing system we're all migrating towards currently doesn'ㅅ have window icons. c) DEs do things like track app starts/quits for things like "Most used apps" launcher lists. To match a window to a .desktop file we rely on window and process metadata. On X11, there's the WM_CLASS window property: https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS Ideally, the second part of a X11 window's WM_CLASS matches the name of a .desktop file installed on the system. Failing that, it matches the value of StartupWMClass in that .desktop file (this is the key part I'll get back to soon). Here's some more documentation by our friends at Gnome on this standard scheme: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased (Look for WM_CLASS / StartupWMClass.) In practice, we pull many other tricks to cope with broken meta data. We try to match things by names, we grab process command lines from /proc and check them against Exec keys in .desktop files in complicated ways, ... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome does that we don't do (because I think it's brittle) is to store the name of the .desktop file an app was launched with as a private window hint on the next window that comes up (which then doesn't work when the app was launched from CLI instead of shell UI). None of these things currently allow us to handle wine very well. As of now (perhaps thanks to the patch mentioned in the linked ticket), wine sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But the .desktop files it generates don't match this by name, and they don't contain a StartupWMClass key. The process command line is the Windows-like path to the .exe, which we also can't easily match up to the complicated Exec values in wine's .desktop files. (Aside: On Wayland, there's a more modern version of this: Windows have an appid property, which should be set to a .desktop file name. I don't know what the status of Wayland support in wine is -- currently the wine clients we encounter run over Xwayland, so we're back to WM_CLASS. We hope wine will set this property correctly when the time comes, or we're happy to work with you guys to find a way to support wine.) Long story short ... could this be picked up? The goal must be to have either .desktop file names or their StartupWMClass values match whatever is set as WM_CLASS. Currently, the easiest fix would be to set StartupWMClass to the executable name set as WM_CLASS. I assume the .desktop file generator has access to this, as the .lnk file referred to by Exec should presumably contain the name of the executable to be launched. Cheers, Eike

2 2

Re: [PATCH 3/4] d3d9/tests: Accept alpha channel differences in shadow_test.
by Marvin 21 Apr '17

21 Apr '17

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=30337 Your paranoid android. === w8 (32 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

2 1

Re: [PATCH 1/4] ddraw/tests: Don't use DDBLT_COLORFILL in test_flip (v2).
by Marvin 21 Apr '17

21 Apr '17

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=30335 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6945: Test failed: Got unexpected color 0x00000000. ddraw1.c:6949: Test failed: Got unexpected color 0x00000000. ddraw1.c:7012: Test failed: Got unexpected color 0x00000000. ddraw1.c:7014: Test failed: Got unexpected color 0x00000000.

2 1

Re: [Tools v2] winetest/dissect: Check the build id and get its details in one Git call.
by Alexandre Julliard 21 Apr '17

21 Apr '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > get_build_info() only returns an empty subject if the commit does not > exist. It may still exist but not be a proper commit SHA-1. I'm not sure it's a good idea to relax that test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/8] d3dx9: Support parameters sharing in effect.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 11 ++- > dlls/d3dx9_36/effect.c | 197 +++++++++++++++++++++++++++++++++++++++++- > dlls/d3dx9_36/tests/effect.c | 17 ++-- > 3 files changed, 211 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index da4564d..d6d4280 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -215,15 +215,22 @@ struct d3dx_parameter > struct d3dx_parameter *annotations; > struct d3dx_parameter *members; > > - struct d3dx_parameter *referenced_param; > struct d3dx_param_eval *param_eval; > > struct d3dx_parameter *top_level_param; > + union > + { > + struct d3dx_parameter *referenced_param; > + struct d3dx_parameter *shared_param; > + }; > + LONG shared_refcount; > }; I think you mentioned this before but it shouldn't be necessary to store the whole parameter structure in the pool. I guess it could be improved after the fact but it shouldn't be too complicated to do it right away. Probably it could just be shared_param_list[] from patch 8/8 and shared_refcount (which at that point won't need to be in struct d3dx_parameter anymore), in addition to data. You could access the other parameter fields through shared_param_list[0]. > +static void d3dx_pool_sync_shared_parameter(struct ID3DXEffectPoolImpl *pool, struct d3dx_parameter *param) > +{ > + unsigned int i, free_entry_index; > + LONG new_refcount; > + > + if (!(param->flags & PARAMETER_FLAG_SHARED) || !pool > + || is_param_type_sampler(param->type)) > + return; > + > + free_entry_index = pool->parameter_count; > + for (i = 0; i < pool->parameter_count; ++i) > + { > + if (!pool->parameters[i]->shared_refcount) > + free_entry_index = i; > + else if (is_same_parameter(param, pool->parameters[i])) > + break; > + } > + if (i == pool->parameter_count) > + { > + i = free_entry_index; > + if (i >= pool->table_size) > + { > + struct d3dx_parameter ** new_alloc; No whitespace after "**", please. > + else > + { > + new_size = pool->table_size * 2; > + new_alloc = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, pool->parameters, > + sizeof(*pool->parameters) * new_size); > + if (!new_alloc) > + { > + ERR("Out of memory.\n"); > + return; > + } > + } > + pool->parameters = new_alloc; > + pool->table_size = new_size; > + } > + pool->parameters[i] = HeapAlloc(GetProcessHeap(), > + HEAP_ZERO_MEMORY, sizeof(*pool->parameters[i])); > + copy_parameter_structure(param, pool->parameters[i], NULL, FALSE); > + param_set_data_pointer(pool->parameters[i], (unsigned char *)param->data, FALSE, FALSE); > + if (i == pool->parameter_count) > + pool->parameter_count++; > + } I don't think this works. HeapReAlloc might move the memory block and that would break the preexisting effects using the pool (and also the previous parameters of the new effect). HEAP_REALLOC_IN_PLACE_ONLY would avoid that but it also makes it easier for the reallocation to fail. I see two ways to fix this: - refresh all the parameters of the effects that are in the pool when you have to reallocate (shared_param_list[] might help here) - allocate the memory in chunks, keeping an array (or list) of chunks which you allocate (but never resize) as needed

2 1

Re: [Tools v2] winetest: Get rid of $gitdir.
by Alexandre Julliard 21 Apr '17

21 Apr '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > WineHQ appears to use /home/winehq/opt/source/git/wine.git as the Wine > checkout directory. After this patch the scripts will use > $workdir/wine.git so this should most likely symlink to the above > location. I'm not sure that's an improvement. > However any non-official site will actually need write access to it from > the scripts to ensure that wine.git is up to date before processing > reports. Otherwise the reports risk being rejected due to the not yet > known commit id. This could still work with a placement in tools/winehq: > one would just have to symlink that to a writable location but it does > imply placing it in $workdir may make more sense. I don't think it makes sense to put it in the website directory, it's not meant to be accessed from the web. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/8] d3dx9: Reference top level parameter instead of dirty flag.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > -static BOOL param_set_dirty_flag_ptr(void *dirty_flag_ptr, struct d3dx_parameter *param) > +static BOOL param_set_top_level_param(void *top_level_param, struct d3dx_parameter *param) > { > - param->dirty_flag_ptr = (DWORD *)dirty_flag_ptr; > + param->top_level_param = (struct d3dx_parameter *)top_level_param; > return FALSE; > } The cast is unnecessary (yeah, it was already unnecessary, I missed that earlier). It might make sense to store both? Avoiding the extra indirection in is_param_dirty() might help a tiny bit. It's fine to tackle this later on.

2 2

Re: [PATCH 8/8] d3dx9: Use local dirty flags for shared parameters.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: As I somewhat hinted at in the previous patch, this one should probably be merged with 7/8. It did help to keep them separated for the first review pass though :) > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index d6d4280..f9cbf7c 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -222,15 +222,14 @@ struct d3dx_parameter > { > struct d3dx_parameter *referenced_param; > struct d3dx_parameter *shared_param; > + struct d3dx_parameter **shared_param_list; This name is a bit confusing given that it is an array of (pointers to) matching parameters from different effects and shared_param is a pointer to the shared pool parameter. It becomes less of an issue if the new field moves to the separate shared parameter structure I mentioned. Maybe just call it "parameters"? > @@ -3193,7 +3196,16 @@ static void d3dx_pool_sync_shared_parameter(struct ID3DXEffectPoolImpl *pool, st > param_set_data_pointer(param, (unsigned char *)pool->parameters[i]->data, FALSE, TRUE); > } > new_refcount = InterlockedIncrement(&pool->parameters[i]->shared_refcount); > + if (new_refcount == 1) > + pool->parameters[i]->shared_param_list = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*pool->parameters[i]->shared_param_list)); > + else > + pool->parameters[i]->shared_param_list = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + pool->parameters[i]->shared_param_list, > + sizeof(*pool->parameters[i]->shared_param_list) * new_refcount); It's probably better to make an initial allocation for > 1 elements and then expand by doubling the size, as usual with this kind of stuff.

1 0

Re: [PATCH 6/8] d3dx9: Factor out free_parameter_data() function.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void free_parameter(struct d3dx_parameter *param, BOOL element, BOOL child) > +{ > + unsigned int i; > + > + TRACE("Free parameter %p, name %s, type %s, child %s\n", param, param->name, > + debug_d3dxparameter_type(param->type), child ? "yes" : "no"); Again, given that it's a chance for some cleanup, please add the period at the end of the message. Also I'd change the "child" part, either just using %#x or child ? "child" : "" (or something else, the point being that the current "child yes" vs "child no" looks pretty awkward). Maybe you can also trace the "element" parameter. > + if (param->param_eval) > + { > + d3dx_free_param_eval(param->param_eval); > + param->param_eval = NULL; Is setting the field to NULL necessary? Same for the others below.

1 0

Re: [PATCH 5/8] d3dx9: Reference effect pool implementation in d3dx9_base_effect structure.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct ID3DXEffectPoolImpl > +{ > + ID3DXEffectPool ID3DXEffectPool_iface; > + LONG ref; > +}; Please rename it to "d3dx_effect_pool" or similar, while you're at it. Same for the interface methods (d3dx_effect_pool_QueryInterface(), ...) We want to get rid of the MS-like names for our implementation and this seems like a good chance to clean this one up. > - TRACE("base %p, data %p, data_size %lu, effect %p\n", base, data, data_size, effect); > + TRACE("base %p, data %p, data_size %lu, effect %p, pool %p\n", base, data, data_size, effect, pool); Since you're touching it, please add a period at the end of the message.

1 0

Re: [PATCH 2/8] d3dx9/tests: Add more tests for IsParameterUsed() function.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + todo_wine > + ok(effect3->lpVtbl->IsParameterUsed(effect3, "vs_arr2", "tech0"), > + "Unexpected IsParameterUsed result FALSE.\n"); > + todo_wine > + ok(!effect3->lpVtbl->IsParameterUsed(effect3, "vs_arr2[0]", "tech0"), > + "Unexpected IsParameterUsed result FALSE.\n"); Typo. I'd just leave out the TRUE / FALSE from these messages, one has to look up the code anyway if there is a test failure.

1 0

Re: [2/2] [v2] secur32: Add support for SECPKG_ATTR_KEY_INFO.
by Jacek Caban 21 Apr '17

21 Apr '17

Hi Akihiro, The patch looks mostly good now, thanks. I have a few minor comments. On 20.04.2017 13:58, Akihiro Sagawa wrote: > +struct schan_alg_id_name { > + ALG_ID alg_id; > + const char* name; > + const WCHAR *nameW; > +}; Using an array here like const WCHAR nameW[8]; would make later initialization nicer by not requiring multiple string variables. > + > +static int comp_alg_id(const void *a, const void *b) > +{ > + const struct schan_alg_id_name *lhs = a; > + const struct schan_alg_id_name *rhs = b; > + return (int)lhs->alg_id - (int)rhs->alg_id; > +} > + > +static void* get_alg_name(ALG_ID id, BOOL wide) > +{ > + static const WCHAR ecdsaW[] = {'E','C','D','S','A',0}; > + static const WCHAR rsaW[] = {'R','S','A',0}; > + static const WCHAR desW[] = {'D','E','S',0}; > + static const WCHAR rc2W[] = {'R','C','2',0}; > + static const WCHAR triple_desW[] = {'3','D','E','S',0}; > + static const WCHAR aesW[] = {'A','E','S',0}; > + static const WCHAR rc4W[] = {'R','C','4',0}; > + static const struct schan_alg_id_name alg_name_map[] = { > + { CALG_ECDSA, "ECDSA", ecdsaW }, > + { CALG_RSA_SIGN, "RSA", rsaW }, > + { CALG_DES, "DES", desW }, > + { CALG_RC2, "RC2", rc2W }, > + { CALG_3DES, "3DES", triple_desW }, > + { CALG_AES_128, "AES", aesW }, > + { CALG_AES_192, "AES", aesW }, > + { CALG_AES_256, "AES", aesW }, > + { CALG_RC4, "RC4", rc4W }, > + }; > + const struct schan_alg_id_name *res; > + struct schan_alg_id_name key; > + > + key.alg_id = id; > + res = bsearch(&key, alg_name_map, > + sizeof(alg_name_map)/sizeof(alg_name_map[0]), sizeof(alg_name_map[0]), > + comp_alg_id); You could use id directly as a key. You don't need it to be of schan_alg_id_name* type, the key may be just ALG_ID. Thanks, Jacek

1 0

Re: [PATCH] tests: Don't evaluate the todo condition when not running on Wine.
by Sebastian Lackner 21 Apr '17

21 Apr '17

On 21.04.2017 15:01, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > This cropped up because I wanted to write a todo condition involving > IsProcessDPIAware(), since this doesn't exist in XP, its address is > loaded dynamically. I could have written the condition as > pIsProcessDPIAware && pIsProcessDPIAware(), but since I know the > function is always present in Wine, that's unnecessary. Perhaps > more to the point, I didn't expect the current behaviour. > > include/wine/test.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/wine/test.h b/include/wine/test.h > index af602c0fac..fa3f90c932 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -123,7 +123,7 @@ extern void __winetest_cdecl winetest_trace( const char *msg, ... ) WINETEST_PRI > winetest_loop_todo(); \ > winetest_end_todo()) > #define todo_wine todo_if(!strcmp(winetest_platform, "wine")) > -#define todo_wine_if(is_todo) todo_if((is_todo) && !strcmp(winetest_platform, "wine")) > +#define todo_wine_if(is_todo) todo_if(!strcmp(winetest_platform, "wine") && (is_todo)) > > > #ifdef NONAMELESSUNION > I don't mind if its changed, but please note that it was intentional to check "is_todo" first. The idea was that side effects (like assigning variables, changing last error, ...) are applied on both Wine and Windows. Just think about something like: FirstCall(); todo_wine_if(SecondCall()) ok(GetLastError() == ..., "\n"); With your patch applied, it will test two entirely different things on Windows (error from FirstCall) and Wine (error from SecondCall), which would also be confusing. Best regards, Sebastian

3 3

Re: [PATCH] msvcrt: Handle synchronous flag for x64 C++ exceptions
by Piotr Caban 21 Apr '17

21 Apr '17

Hi, On 04/20/17 16:42, Daniel Lehman wrote: > + if (descr->magic >= CXX_FRAME_MAGIC_VC8 && > + (descr->flags & FUNC_DESCR_SYNCHRONOUS) && > + (rec->ExceptionCode != CXX_EXCEPTION && rec->ExceptionCode != STATUS_UNWIND_CONSOLIDATE)) > + return ExceptionContinueSearch; /* handle only c++ exceptions */ I think the condition for STATUS_UNWIND_CONSOLIDATE should also check number of parameters and ExceptionInformation[0]==(ULONG_PTR)call_catch_block like it's done during unwinding. Also the code breaks unwinding for longjump when FUNC_DESCR_SYNCHRONOUS flag is set. Thanks, Piotr

1 0

Re: [PATCH 08/12] d3d10core/tests: Allow passing any interface to get_refcount().
by Henri Verbeet 21 Apr '17

21 Apr '17

On 21 April 2017 at 10:59, Józef Kucia <jkucia(a)codeweavers.com> wrote: > -static ULONG get_refcount(IUnknown *iface) > +#define get_refcount(iface) get_refcount_((IUnknown *)iface) > +static ULONG get_refcount_(IUnknown *iface) You don't really need that macro.

1 0

Linux desktop integration: Fill StartupWMClass in .desktop menu entries
by Eike Hein 21 Apr '17

21 Apr '17

Hi, I maintain the taskbar in Plasma 5 and would like to poke folks about a desktop integration pain point we (and our friends at other DEs) face with apps run via wine. Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699 Let me give some broader context on this. Modern DEs have a swath of UX going on that relies on being able to identify the application owning a particular window in the windowing system. "Identify the application" in practice means "map the window to a .desktop file installed in the menu file system". We want to do this because: a) Many a taskbar/dock-like UI tries to form a smooth life cycle across "launcher button", "startup notification" and "window button(s)". For each of those we need to work out the app they are associated with to be able to match them up. If it fails, ugly things like co-existing task buttons or missing startup throbbers and similar happen. b) UI these days tends to prefer to load assets such as app icons via the values defined in .desktop files instead of using the window icon, to ensure consistent results (apps may load icon assets differently from the shell, leading to asset quality issues, inconsistent theming, the icon changing between the lifecycle states mentioned in 'a', etc.) Plus the Wayland windowing system we're all migrating towards currently doesn'ㅅ have window icons. c) DEs do things like track app starts/quits for things like "Most used apps" launcher lists. To match a window to a .desktop file we rely on window and process metadata. On X11, there's the WM_CLASS window property: https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS Ideally, the second part of a X11 window's WM_CLASS matches the name of a .desktop file installed on the system. Failing that, it matches the value of StartupWMClass in that .desktop file (this is the key part I'll get back to soon). Here's some more documentation by our friends at Gnome on this standard scheme: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased (Look for WM_CLASS / StartupWMClass.) In practice, we pull many other tricks to cope with broken meta data. We try to match things by names, we grab process command lines from /proc and check them against Exec keys in .desktop files in complicated ways, ... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome does that we don't do (because I think it's brittle) is to store the name of the .desktop file an app was launched with as a private window hint on the next window that comes up (which then doesn't work when the app was launched from CLI instead of shell UI). None of these things currently allow us to handle wine very well. As of now (perhaps thanks to the patch mentioned in the linked ticket), wine sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But the .desktop files it generates don't match this by name, and they don't contain a StartupWMClass key. The process command line is the Windows-like path to the .exe, which we also can't easily match up to the complicated Exec values in wine's .desktop files. (Aside: On Wayland, there's a more modern version of this: Windows have an appid property, which should be set to a .desktop file name. I don't know what the status of Wayland support in wine is -- currently the wine clients we encounter run over Xwayland, so we're back to WM_CLASS. We hope wine will set this property correctly when the time comes, or we're happy to work with you guys to find a way to support wine.) Long story short ... could this be picked up? The goal must be to have either .desktop file names or their StartupWMClass values match whatever is set as WM_CLASS. Currently, the easiest fix would be to set StartupWMClass to the executable name set as WM_CLASS. I assume the .desktop file generator has access to this, as the .lnk file referred to by Exec should presumably contain the name of the executable to be launched. Cheers, Eike

1 0

Re: [Tools] winetest: Get rid of $gitdir.
by Francois Gouget 21 Apr '17

21 Apr '17

Actually this patch depends on the next one 'winetest/dissect: Check the build id and get its details in one Git call.' I'll resubmit them in a cleaner way. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 1/4] regedit: Validate REG_SZ import data before processing it any further (v2)
by Alexandre Julliard 21 Apr '17

21 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 6 ++++++ > programs/regedit/tests/regedit.c | 14 +++++++------- > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index 96c4564..ccd9ebe 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -293,6 +293,12 @@ static int REGPROC_unescape_string(WCHAR* str) > str[val_idx] = str[str_idx]; > break; > } > + } else if (str[str_idx] == '"') { > + WCHAR *p = str + str_idx + 1; > + while (*p == ' ' || *p == '\t') p++; > + if (*p && *p != ';') return 0; > + str[val_idx++] = str[str_idx]; > + break; That would work, but it seems to me that the comment check would be better in the caller, so that you can use the same code for validating value names. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] user32: add GetAutoRotationState/GetDisplayAutoRotationPreferences stubs
by Huw Davies 21 Apr '17

21 Apr '17

On Thu, Apr 20, 2017 at 05:33:15PM -0500, Austin English wrote: > diff --git a/dlls/user32/misc.c b/dlls/user32/misc.c > index fa0502e..3581235 100644 > --- a/dlls/user32/misc.c > +++ b/dlls/user32/misc.c > @@ -910,3 +910,24 @@ LRESULT WINAPI ImeWndProcW( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) > > return DefWindowProcW(hwnd, msg, wParam, lParam); > } > + > +/********************************************************************** > + * GetAutoRotationState [USER32.@] > + */ > +BOOL WINAPI GetAutoRotationState( AR_STATE *state ) > +{ > + *state = AR_NOT_SUPPORTED; > + FIXME("(%p): stub\n", state); > + return TRUE; > +} > + I think these would be better in sysparams.c. I realise that there are already functions of this nature in misc.c - they could probably be moved across too. User32 does indeed have some odd 'misc' like functions, but these aren't them. Also, we'd generally put the FIXME() at the start of the function, not after the assignment. Apart from that, this looks good to me. Huw.

1 0

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS
by 许文龙 20 Apr '17

20 Apr '17

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS

2 1

Re: [05/10] webservices: Add support for outgoing TCP connections.
by Alexandre Julliard 20 Apr '17

20 Apr '17

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/webservices/channel.c | 286 ++++++++++++++++++++++++++------- > dlls/webservices/listener.c | 16 +- > dlls/webservices/webservices_private.h | 5 + > 3 files changed, 240 insertions(+), 67 deletions(-) This breaks the Android build: x86_64-linux-android-gcc -m64 -c -o proxy.o ../../../wine/dlls/webservices/proxy.c -I. -I../../../wine/dlls/webservices \ -I../../include -I../../../wine/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret In file included from ../../../wine/dlls/webservices/webservices_private.h:19:0, from ../../../wine/dlls/webservices/proxy.c:29: ../../../wine/include/ws2tcpip.h:57:16: error: conflicting types for 'socklen_t' ../../../wine/include/ws2tcpip.h:29:18: note: in definition of macro 'WS' In file included from /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/stdio.h:50:0, from ../../../wine/dlls/webservices/proxy.c:19: /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/sys/types.h:127:21: note: previous declaration of 'socklen_t' was here -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin 20 Apr '17

20 Apr '17

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=30284 Your paranoid android. === w864 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8096: Test failed: Got unexpected color 0x00000080 for no color attribute test. === w1064 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [v3 PATCH 1/2] wined3d: Add dirty region tracking.
by Marvin 20 Apr '17

20 Apr '17

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=30282 Your paranoid android. === w864 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [PATCH] mfplat: Implement MFCreateAttributes
by Nikolay Sivov 20 Apr '17

20 Apr '17

On 04/20/2017 10:44 AM, Alistair Leslie-Hughes wrote: > +{ > + mfattributes *This = impl_from_IMFAttributes(iface); > + > + if(IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_IMFAttributes)) > + { > + TRACE("(IID_IUnknown %p)\n", object); > + *object = This; > + } > + else > + { > + FIXME("(%s, %p)\n", debugstr_guid(riid), object); > + *object = NULL; > + return E_NOINTERFACE; > + } > + > + IUnknown_AddRef((IUnknown*)*object); > + return S_OK; > +} Please add a regular TRACE for this method, and return iface or interface pointer from This, instead of This itself. Trace you have now is inaccurate. > +HRESULT WINAPI MFCreateAttributes(IMFAttributes **attributes, UINT32 size) > +{ > + mfattributes *object; > + > + TRACE("%p, %d\n", attributes, size); > + > + object = HeapAlloc( GetProcessHeap(), 0, sizeof(*attributes) ); > + if(!object) > + return E_OUTOFMEMORY; This should use sizeof(*object).

2 1

Re: [v2 PATCH] mfplat: Implement MFCreateAttributes
by Dmitry Timoshkov 20 Apr '17

20 Apr '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +typedef struct _mfattributes > +{ > + IMFAttributes IMFAttributes_iface; > + LONG ref; > +} mfattributes; Please try to exchange these two lines in the structure above and see what happens. -- Dmitry.

1 0

Review | endproc.c: Implement ProcessPage_OnEndProcessTree
by Akarsha Sehwag 19 Apr '17

19 Apr '17

Hi Could someone take out a little time to review the code once? Bug I intend to solve: https://bugs.winehq.org/show_bug.cgi?id=39640 I am new to wine. So, I would appreciate suggestions regarding my coding style if that's not-so-perfect according to wine standards. Or any other problems with the code I have written. I apologize for submitting an untested code earlier. I hope now it works fine. /*-------------------------------------------CODE--------------------------------------------------*/ typedef struct process_list { DWORD *pid; /*dynamic array to store the process IDs*/ SIZE_T count; /*index to maintain the last entry of the array;*/ SIZE_T size; /*the current size of the pid array*/ } process_list; static void init_process_list(process_list *list) { list->size = 4; /*initialise size with 4. Will increase if necessary.*/ list->pid = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, list->size * sizeof(list->pid)); list->count = 0; } static void increase_list_size(process_list *list) { list->size *= 2; list->pid = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, list->pid, list->size * sizeof(list->pid)); *//DOUBT: *Would sizeof(list->pid) be better or sizeof(int)? //Since in the former case, since list->pid is actually a pointer to DWORD, so //sizeof(list->pid) would return 8 bytes and not 4 bytes. } static void process_list_append(process_list *list, DWORD id) { if(list->count == list->size) increase_list_size(list); list->pid[list->count] = id; list->count += 1; } static void free_process_list(process_list *list) { HeapFree(GetProcessHeap(), 0, list->pid); } static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) { PROCESSENTRY32 entry; SIZE_T start, end, i ; start = list->count; entry.dwSize = sizeof(entry); if(!Process32First(snapshot, &entry)) return; do { if(entry.th32ParentProcessID == pid) process_list_append(list, entry.th32ProcessID); } while (Process32Next(snapshot, &entry)); end = list->count; for(i = start; i < end; ++i) { enum_process_children(snapshot, list, list->pid[i]); } } void ProcessPage_OnEndProcessTree(void) { {...} process_list list; SIZE_T i; HANDLE snapshot; {...} init_process_list(&list); if(list.pid == NULL) return; process_list_append(&list, dwProcessId); snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(!snapshot) return; enum_process_children(snapshot, &list, dwProcessId); CloseHandle(snapshot); for(i = 0; i < list.count; ++i) { hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list.pid[i]); if (!hProcess) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); break; } if (!TerminateProcess(hProcess, 0)) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); } CloseHandle(hProcess); } free_process_list(&list); } /*---------------------------------------END OF CODE------------------------------------------*/ Thanks and regards -- Akarsha Sehwag

1 0

Re: [2/3] wsdapi/tests: Add tests for Register/UnRegisterNotificationSink
by Nikolay Sivov 19 Apr '17

19 Apr '17

Don't know if that's important, but this does not test a case when RegisterNotificationSink is called on already registered sink.

3 3

Re: [PATCH] mfplat: Add MFCreateAttributes stub
by Nikolay Sivov 19 Apr '17

19 Apr '17

Does this make some application work, without providing actual interface implementation?

3 2

Re: [v2 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin 19 Apr '17

19 Apr '17

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=30251 Your paranoid android. === w1064 (32 bit visual) === visual.c:7992: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

Re: [PATCH 2/3] user32: Switch to normal window drawing on SetLayeredWindowAttributes call
by Ken Thomases 19 Apr '17

19 Apr '17

On Apr 18, 2017, at 11:43 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/user32/win.c | 6 +++++- > dlls/winemac.drv/window.c | 2 ++ > dlls/winex11.drv/window.c | 2 ++ > 3 files changed, 9 insertions(+), 1 deletion(-) The Mac driver part of this looks OK to me. -Ken

1 0

Re: [PATCH 1/3] shell32: Avoid leaking icon handles.
by Andrew Eikum 19 Apr '17

19 Apr '17

FWIW you're mixing up indent style in a function that is mostly consistently (if bizarrely) indented. Andrew On Wed, Apr 19, 2017 at 01:13:39PM +0100, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/shell32/iconcache.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c > index c3284a27d6..7beb47967d 100644 > --- a/dlls/shell32/iconcache.c > +++ b/dlls/shell32/iconcache.c > @@ -305,10 +305,12 @@ static INT SIC_IconAppend (LPCWSTR sSourceFile, INT dwSourceIndex, HICON hSmallI > * gets small/big icon by number from a file > */ > static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > -{ HICON hiconLarge=0; > +{ > + HICON hiconLarge=0; > HICON hiconSmall=0; > HICON hiconLargeShortcut; > HICON hiconSmallShortcut; > + int ret; > > PrivateExtractIconsW( sSourceFile, dwSourceIndex, GetSystemMetrics(SM_CXICON), > GetSystemMetrics(SM_CYICON), &hiconLarge, 0, 1, 0 ); > @@ -327,6 +329,8 @@ static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > hiconSmallShortcut = SIC_OverlayShortcutImage(hiconSmall, FALSE); > if (NULL != hiconLargeShortcut && NULL != hiconSmallShortcut) > { > + DestroyIcon( hiconLarge ); > + DestroyIcon( hiconSmall ); > hiconLarge = hiconLargeShortcut; > hiconSmall = hiconSmallShortcut; > } > @@ -339,8 +343,12 @@ static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > } > } > > - return SIC_IconAppend (sSourceFile, dwSourceIndex, hiconSmall, hiconLarge, dwFlags); > + ret = SIC_IconAppend( sSourceFile, dwSourceIndex, hiconSmall, hiconLarge, dwFlags ); > + DestroyIcon( hiconLarge ); > + DestroyIcon( hiconSmall ); > + return ret; > } > + > /***************************************************************************** > * SIC_Initialize [internal] > */ > -- > 2.12.0 > > >

2 1

Re: [6/6] secur32: Add support for SECPKG_ATTR_KEY_INFO (GnuTLS only).
by Jacek Caban 19 Apr '17

19 Apr '17

Hi Akihiro, Thanks for working on that. I have a few comments to the patch. On 17.04.2017 16:26, Akihiro Sagawa wrote: > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index 6914837..317686f 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -54,11 +54,14 @@ struct schan_handle > enum schan_handle_type type; > }; > > +#define SCHAN_KEY_NAME_MAX 8 > struct schan_context > { > schan_imp_session session; > ULONG req_ctx_attr; > const CERT_CONTEXT *cert; > + SEC_WCHAR key_signature_name[SCHAN_KEY_NAME_MAX]; > + SEC_WCHAR key_encrypt_name[SCHAN_KEY_NAME_MAX]; Those should not be needed. You could for example store both WCHAR and char strings inside alg_name_map. > }; > > static struct schan_handle *schan_handle_table; > @@ -962,6 +965,53 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextA( > return ret; > } > > +struct schan_alg_id_name { > + ALG_ID alg_id; > + const char* name; > +}; > + > +static int comp_alg_id(const void *a, const void *b) > +{ > + const struct schan_alg_id_name *lhs = a; > + const struct schan_alg_id_name *rhs = b; > + return (int)lhs->alg_id - (int)rhs->alg_id; > +} > + > +static void fill_alg_name(ALG_ID id, void *buffer, BOOL wide) If you change the patch as I suggested above, this could be something like: static void *get_alg_name(ALF_ID id, BOOL wide) > +{ > + static const struct schan_alg_id_name alg_name_map[] = { > + { CALG_ECDSA, "ECDSA" }, > + { CALG_RSA_SIGN, "RSA" }, > + { CALG_DES, "DES" }, > + { CALG_RC2, "RC2" }, > + { CALG_3DES, "3DES" }, > + { CALG_AES_128, "AES" }, > + { CALG_AES_192, "AES" }, > + { CALG_AES_256, "AES" }, > + { CALG_RC4, "RC4" }, > + }; > + const struct schan_alg_id_name *res; > + struct schan_alg_id_name key; > + const char *name; > + > + key.alg_id = id; > + res = bsearch(&key, alg_name_map, > + sizeof(alg_name_map)/sizeof(alg_name_map[0]), sizeof(alg_name_map[0]), > + comp_alg_id); > + if (res) > + name = res->name; > + else > + { > + TRACE("Unknown ALG_ID %04x\n", id); > + name = "???"; > + } A FIXME would would be nice here. Also, I think you could just return NULL in this case. > + > + if (wide) > + MultiByteToWideChar(CP_ACP, 0, name, -1, (SEC_WCHAR*)buffer, SCHAN_KEY_NAME_MAX); > + else > + strcpy((SEC_CHAR*)buffer, name); > +} > + > static SECURITY_STATUS ensure_remote_cert(struct schan_context *ctx) > { > HCERTSTORE cert_store; > @@ -989,6 +1039,7 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > > if (!context_handle) return SEC_E_INVALID_HANDLE; > ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + if (!ctx) return SEC_E_INVALID_HANDLE; This has an effect outside of scope of this patch. This should be be a separated patch, with a test case. > switch(attribute) > { > @@ -1016,6 +1067,19 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > > return status; > } > + case SECPKG_ATTR_KEY_INFO: > + { > + SecPkgContext_KeyInfoW *info = buffer; > + SECURITY_STATUS status = schan_imp_get_key_info(ctx->session, info); > + if (status == SEC_E_OK) > + { > + info->sSignatureAlgorithmName = ctx->key_signature_name; > + info->sEncryptAlgorithmName = ctx->key_encrypt_name; > + fill_alg_name(info->SignatureAlgorithm, info->sSignatureAlgorithmName, TRUE); > + fill_alg_name(info->EncryptAlgorithm, info->sEncryptAlgorithmName, TRUE); > + } > + return status; > + } > case SECPKG_ATTR_REMOTE_CERT_CONTEXT: > { > PCCERT_CONTEXT *cert = buffer; > @@ -1091,6 +1155,24 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesA( > { > case SECPKG_ATTR_STREAM_SIZES: > return schan_QueryContextAttributesW(context_handle, attribute, buffer); > + case SECPKG_ATTR_KEY_INFO: > + { > + SecPkgContext_KeyInfoA *info = buffer; > + struct schan_context *ctx; > + SECURITY_STATUS status; > + if (!context_handle) return SEC_E_INVALID_HANDLE; > + ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + if (!ctx) return SEC_E_INVALID_HANDLE; > + status = schan_imp_get_key_info(ctx->session, (SecPkgContext_KeyInfoW*)info); > + if (status == SEC_E_OK) > + { > + info->sSignatureAlgorithmName = (SEC_CHAR *)ctx->key_signature_name; > + info->sEncryptAlgorithmName = (SEC_CHAR *)ctx->key_encrypt_name; > + fill_alg_name(info->SignatureAlgorithm, info->sSignatureAlgorithmName, FALSE); > + fill_alg_name(info->EncryptAlgorithm, info->sEncryptAlgorithmName, FALSE); > + } > + return status; > + } > case SECPKG_ATTR_REMOTE_CERT_CONTEXT: > return schan_QueryContextAttributesW(context_handle, attribute, buffer); > case SECPKG_ATTR_CONNECTION_INFO: > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index 30640d3..ddf33a8 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -363,6 +363,22 @@ static ALG_ID schannel_get_kx_algid(int kx) > } > } > > +static ALG_ID schannel_get_kx_signature_algid(gnutls_kx_algorithm_t kx) > +{ > + switch (kx) > + { > + case GNUTLS_KX_UNKNOWN: return 0; > + case GNUTLS_KX_RSA: > + case GNUTLS_KX_RSA_EXPORT: > + case GNUTLS_KX_DHE_RSA: > + case GNUTLS_KX_ECDHE_RSA: return CALG_RSA_SIGN; > + case GNUTLS_KX_ECDHE_ECDSA: return CALG_ECDSA; > + default: > + FIXME("unknown algorithm %d\n", kx); > + return 0; > + } > +} > + > unsigned int schan_imp_get_session_cipher_block_size(schan_imp_session session) > { > gnutls_session_t s = (gnutls_session_t)session; > @@ -394,6 +410,23 @@ SECURITY_STATUS schan_imp_get_connection_info(schan_imp_session session, > return SEC_E_OK; > } > > +SECURITY_STATUS schan_imp_get_key_info(schan_imp_session session, SecPkgContext_KeyInfoW *info) > +{ > + gnutls_session_t s = (gnutls_session_t)session; > + gnutls_cipher_algorithm_t alg = pgnutls_cipher_get(s); > + gnutls_kx_algorithm_t kx = pgnutls_kx_get(s); > + > + TRACE("(%p,%p)\n", session, info); > + > + info->sSignatureAlgorithmName = NULL; /* filled later */ > + info->sEncryptAlgorithmName = NULL; /* filled later */ > + info->KeySize = pgnutls_cipher_get_key_size(alg) * 8; > + info->SignatureAlgorithm = schannel_get_kx_signature_algid(kx); > + info->EncryptAlgorithm = schannel_get_cipher_algid(alg); > + > + return SEC_E_OK; > +} I don't think such helper that fills output partially is the right solution here. You could use schan_imp_get_connection_info to get all info you need except signature algorithm. For signature algorithm, you may introduce a new, simpler, function. Thanks, Jacek

1 0

Re: [5/6] secur32/tests: Add tests with SECPKG_ATTR_KEY_INFO.
by Jacek Caban 19 Apr '17

19 Apr '17

Hi Akihiro, On 17.04.2017 16:26, Akihiro Sagawa wrote: > @@ -923,6 +924,15 @@ todo_wine > ok(conn_info.dwHashStrength >= 128, "conn_info.dwHashStrength = %d\n", conn_info.dwHashStrength); > } > > + status = pQueryContextAttributesA(&context, SECPKG_ATTR_KEY_INFO, &key_info); > + todo_wine_if(status == SEC_E_UNSUPPORTED_FUNCTION) > + ok(status == SEC_E_OK, "QueryContextAttributesW(SECPKG_ATTR_KEY_INFO) failed: %08x\n", status); I think this should use todo_wine, not todo_wine_if(). Thanks, Jacek

1 0

Re: [PATCH 01/10] wined3d: Introduce struct wined3d_dirty_regions.
by Stefan Dösinger 19 Apr '17

19 Apr '17

Hi Masanori, Thank you for your patches! I have a few comments: Regarding the big picture I think it would be great if we had a scheme that also worked for partially mapping resources. It's also necessary to make the D3DLOCK_NO_DIRTY_UPDATE test on managed textures work. However, doing this is a lot more work than your patchset and complicates location management a lot. If Henri tells you something different follow his advice. He is the authority for decisions in d3d :-) . Patch 1: Am 2017-04-17 um 15:47 schrieb Masanori Kakura: > +struct wined3d_dirty_regions > +{ > + UINT left; > + UINT top; > + UINT right; > + UINT bottom; > + UINT front; > + UINT back; > + struct wined3d_dirty_regions *next; > +}; A standard wine list would be better IMHO. Patch 2: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 785105d7b9..711f98a0a6 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2765,6 +2765,27 @@ struct wined3d_dirty_regions > struct wined3d_dirty_regions *next; > }; > > +static inline BOOL wined3d_dirty_regions_add(struct wined3d_dirty_regions **regions, > + UINT left, UINT top, UINT right, UINT bottom, UINT front, UINT back) I don't think we want this in the header file, I think it'd be better placed in resource.c. Also note that buffers already have a related mechanism (buffer->modified_areas). You can predeclare the functions in the header if you need to call them from multiple files. > +{ > + struct wined3d_dirty_regions *new_region; > + > + if (!(new_region = HeapAlloc(GetProcessHeap(), 0, sizeof(struct wined3d_dirty_regions)))) > + return FALSE; HeapAlloc is expensive. I think it is OK for the start, but in the long run a way to keep some old dirty region elements around and reuse them instead of always calling Alloc / Free. Patch 5: > + if (!wined3d_dirty_regions_add(&resource->dirty_regions, 0, 0, width, height, 0, depth)) Why not use wined3d_resource_maximize_dirty_region here? > wined3d_resource_acquire(resource); > + wined3d_dirty_regions_clear(&resource->dirty_regions); > wined3d_cs_destroy_object(resource->device->cs, wined3d_resource_destroy_object, resource); Regions need to be cleared from inside the cs thread in case there are pending update_texture commands. Similarly patch 6 needs to put the region modifying into wined3d_cs_exec_add_dirty_texture_region. Patch 7: > + if (box->left < box->right && box->top < box->bottom && box->front < box->back) > + { You don't need to check the box, texture_resource_sub_resource_map already does it before it reaches this place of the code. See wined3d_texture_check_box_dimensions. Patch 8: I am not sure if this is necessary at all. In d3d9 it doesn't matter because a UpdateSurface destination can never be an UpdateTexture source. Patch 9/10: These should be merged, and I don't think patch 10 looks right. I think dirty regions should be honored on sublevels as well, just adjusted (i.e., divide by 2 for every level). > + if (src_texture->resource.width <= dst_texture->resource.width > + && src_texture->resource.height <= dst_texture->resource.height > + && src_texture->resource.depth <= dst_texture->resource.depth) Why are you adding this check? Is it because the src_skip_levels broke the if (i == 0) root level detection? If you apply the dirty region to all levels this problem should go away.

3 8

Re: [PATCH 6/6] dwrite: Make CreateFontFaceFromHdc() properly fail on unsupported font format
by Marvin 19 Apr '17

19 Apr '17

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=30243 Your paranoid android. === wvistau64 (32 bit font) === font.c:3510: Test failed: got 0x80004005 === w2008s64 (32 bit font) === font.c:3510: Test failed: got 0x80004005 === wvistau64 (64 bit font) === font.c:3510: Test failed: got 0x80004005 === w2008s64 (64 bit font) === font.c:3510: Test failed: got 0x80004005

1 0

Re: [2/3] msi: Properly handle DWORD registry values in MsiGetPatchInfoEx.
by Marvin 19 Apr '17

19 Apr '17

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=30239 Your paranoid android. === w7u (32 bit msi) === The task timed out

1 0

Re: 0001-Fix-some-bugs-about-some-special-Chinese-tests-in-lo
by Jactry Zeng 19 Apr '17

19 Apr '17

Hi, Please have a look at this wiki page before you submitting a patch: https://wiki.winehq.org/Submitting_Patches Thanks for your work! 2017-04-18 16:00 GMT+08:00 Matrix95 <matrix95(a)foxmail.com>: > > > > > > -- Regards, Jactry Zeng

1 0

Re: [PATCH 3/3] user32: Add layered window child painting test when WS_CLIPCHILDREN flag is specified
by Marvin 18 Apr '17

18 Apr '17

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=30230 Your paranoid android. === w864 (32 bit win) === win.c:2323: Test failed: expected !100 win.c:2323: Test failed: expected !100

2 1

Re: [PATCH 1/2] mountmgr: Create devices and registry entries for serial ports.
by Hugh McMaster 18 Apr '17

18 Apr '17

Hi Alex, Just a few things I noticed. On Monday, 17 April 2017 2:23 PM, Alex Henrie wrote: >+ /* create registry entry */ >+ sprintfW( reg_value, reg_value_format, n ); >+ RegSetValueExW( windows_ports_key, nt_name.Buffer, 0, REG_SZ, >+ (BYTE *)reg_value, strlenW( reg_value ) * sizeof(WCHAR) ); >+ >+ return TRUE; >+} You need to pass RegSetValueExW() the string length plus the null-terminating character. >+/* find and create serial or parallel ports */ >+static void create_port_devices( DRIVER_OBJECT *driver ) >+{ >+ static const char *serial_search_paths[] = { >+#ifdef linux >+ "/dev/ttyS%u", >+ "/dev/ttyUSB%u", >+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) >+ "/dev/cuau%u", >+#elif defined(__DragonFly__) >+ "/dev/cuaa%u", >+#else >+ "", >+#endif >+ }; >+ static const WCHAR serialcomm_keyW[] = {'H','A','R','D','W','A','R','E','\\', >+ 'D','E','V','I','C','E','M','A','P','\\', >+ 'S','E','R','I','A','L','C','O','M','M',0}; >+ const char **search_paths; >+ const WCHAR *windows_ports_key_name; >+ char *dosdevices_path, *p; >+ HKEY wine_ports_key = NULL, windows_ports_key = NULL; >+ char unix_path[256]; >+ int i, j, n = 1; >+ >+ if (!(dosdevices_path = get_dosdevices_path( &p ))) >+ return; >+ >+ if (driver == serial_driver) >+ { >+ p[0] = 'c'; >+ p[1] = 'o'; >+ p[2] = 'm'; >+ search_paths = serial_search_paths; >+ windows_ports_key_name = serialcomm_keyW; >+ } >+ else >+ { >+ /* TODO: support parallel ports */ >+ } >+ p += 3; >+ >+ RegOpenKeyW( HKEY_LOCAL_MACHINE, ports_keyW, &wine_ports_key ); >+ RegOpenKeyW( HKEY_LOCAL_MACHINE, windows_ports_key_name, &windows_ports_key ); Please use RegOpenKeyExW() and check for any failures from these functions. >+ /* remove old symlinks */ >+ for (n = 1; n <= MAX_PORTS; n++) >+ { >+ sprintf( p, "%u", n ); >+ if (unlink( dosdevices_path ) != 0 && !errno) >+ break; >+ } >+ >+ /* look for ports in the usual places */ >+ n = 1; >+ for (i = 0; i < sizeof(search_paths)/sizeof(search_paths[0]); i++) This won't do what you expect. sizeof(search_paths)/sizeof(search_paths[0]) is 1. You need to pass in the number of elements in the array. Also, it's better to avoid making this calculation during each loop. Hugh

2 1

Re: [v2 PATCH] oleaut32: Remove redentant VariantClear call
by Huw Davies 18 Apr '17

18 Apr '17

I've sent another version with the typo in the subject fixed. Huw.

1 0

Re: [PATCH 4/4] ddraw/tests: Work around an Nvidia DEPTHFILL bug in ddraw2.
by Henri Verbeet 18 Apr '17

18 Apr '17

On 17 April 2017 at 22:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* Nvidia drivers (Tested on Geforce 7 to Geforce 650) on Windows incorrectly handle > + * depth fills in ddraw2. X axis coordinates are scaled by 3/4, so we end up clearing What is the depth format it ends up with? D24X8 by any chance?

1 0

Re: [PATCH 3/4] ddraw/tests: Don'T use DDBLT_COLORFILL in test_flip.
by Henri Verbeet 18 Apr '17

18 Apr '17

On 17 April 2017 at 22:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* The Nvidia Geforce 7 driver cannot do a color fill on a texture backbuffer after > + * the backbuffer has been locked. Do it ourselves as a workaround. Unlike ddraw1 > + * and 2 GetSurfaceDesc does not cause issues in ddraw4 and ddraw7. */ > +static void fill_surface(IDirectDrawSurface7 *surface, D3DCOLOR color) I think this kind of helper is fine, but the comment seems more appropriate for the place using it than the helper itself. > + color = get_surface_color(backbuffer1, 320, 240); > + color = get_surface_color(backbuffer2, 320, 240); > + color = get_surface_color(backbuffer3, 320, 240); Is this debug code?

1 0

Re: [PATCH] oleaut32: Improve support for IDispatch in VarCat
by Nikolay Sivov 18 Apr '17

18 Apr '17

On 17.04.2017 6:43, Alistair Leslie-Hughes wrote: > + else if (rightvt == VT_DISPATCH) > + { > + /* The returned Dispatch Value, may not be able to be coerced, ie. VT_NULL */ > + hres = VariantChangeTypeEx(&bstrvar_left,left,0,0,VT_BSTR); > + if (hres != S_OK && hres != DISP_E_TYPEMISMATCH) > + return hres; > + } > else > { > hres = VariantChangeTypeEx(&bstrvar_left,left,0,0,VT_BSTR); This is suspiciously similar to default case, in last else block. Could it mean VariantChangeTypeEx() should be fixed instead? > + if (This->bFailInvoke) > + return E_OUTOFMEMORY; I think it's better to use some non-specific error code that triggers FAILED() but is not generic as E_OUTOFMEMORY, anything above 0x8000000 I suppose. Also maybe it's better to use exact code instead of bFailInvoke, and return if (FAILED(This->hr))? > +static inline DummyDispatch *impl_from_IDispatch(IDispatch *iface) > +{ > + return CONTAINING_RECORD(iface, DummyDispatch, IDispatch_iface); > +} > + > +static ULONG WINAPI DummyDispatch_AddRef(IDispatch *iface) > +{ > + DummyDispatch *This = impl_from_IDispatch(iface); > + return InterlockedIncrement(&This->ref); > +} If static object is enough, you can remove reference counter. > + if (pVarCmp) > + ok(pVarCmp(&result,&expected,lcid,0) == VARCMP_EQ, > + "VarCat: EMPTY concat with EMPTY did not return empty VT_BSTR\n"); This is not a problem this patch introduces, but there's no reason to continue to use pVarCmp, as it's always available on platforms we're testing on.

2 1

Re: [v3 PATCH] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Huw Davies 18 Apr '17

18 Apr '17

On Thu, Apr 13, 2017 at 01:06:50AM +0000, Alistair Leslie-Hughes wrote: > +static BOOL write_config_value(const WCHAR *driver, const WCHAR *args) > +{ > + long ret; > + HKEY hkey; > + > + if (!args) > + return FALSE; > + > + if ((ret = RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + WCHAR *divider, *value; > + > + WCHAR *name = heap_alloc( (strlenW(args) + 1) * sizeof(WCHAR)); > + if(!name) > + { > + push_error(ODBC_ERROR_OUT_OF_MEM, odbc_error_out_of_mem); > + return FALSE; You're returning without closing the registry keys. You may want to change the error handling to a 'goto fail;' type behaviour. > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index ed8e6f1..e5a8896 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c ... > + > ret = SQLInstallDriverEx("WINE ODBC Driver Path\0Driver=sample.dll\0Setup=sample.dll\0\0", "c:\\temp", path, MAX_PATH, &size, ODBC_INSTALL_COMPLETE, NULL); > + ok(ret, "SQLInstallDriverEx failed\n"); > sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > - ok(sql_ret && error_code == SQL_SUCCESS, "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > + ok(sql_ret == SQL_NO_DATA || (sql_ret && error_code == SQL_SUCCESS), "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > ok(!strcmp(path, "c:\\temp"), "invalid path %s\n", path); > > + ret = SQLConfigDriver(NULL, ODBC_CONFIG_DRIVER, "WINE ODBC Driver Path", "NoWrite=60;xxxx=555", error, sizeof(error), NULL); > + ok(ret, "SQLConfigDriver failed\n"); > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + ok(sql_ret == SQL_NO_DATA || (sql_ret && error_code == SQL_SUCCESS), "SQLConfigDriver failed %d, %u\n", sql_ret, error_code); > + > + ret = SQLConfigDriver(NULL, ODBC_CONFIG_DRIVER, "WINE ODBC Driver Path", "empty", error, sizeof(error), NULL); > + ok(!ret, "SQLConfigDriver successed\n"); > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + ok(sql_ret && error_code == ODBC_ERROR_INVALID_KEYWORD_VALUE, "SQLConfigDriver failed %d, %u\n", sql_ret, error_code); > + > if (ret) > { This entire block is now skipped if things proceed as expected... Also, 'successed' is not a word ;-) Huw.

1 0

Re: [PATCH] oleaut32: Pass the correct variable to VariantClear
by Huw Davies 18 Apr '17

18 Apr '17

On Tue, Apr 18, 2017 at 04:05:31AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oleaut32/vartype.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > index fc5a025..3513399 100644 > --- a/dlls/oleaut32/vartype.c > +++ b/dlls/oleaut32/vartype.c > @@ -136,7 +136,7 @@ static HRESULT VARIANT_FromDisp(IDispatch* pdispIn, LCID lcid, void* pOut, > if (SUCCEEDED(hRet)) > { > VARIANT_CopyData(&dstVar, vt, pOut); > - VariantClear(&srcVar); > + VariantClear(&dstVar); This isn't right. In the BSTR case (the only interesting case) CopyData doesn't allocate a new BSTR, so you would end up free'ing the BSTR you return. This VariantClear() should just go away. Huw.

1 0

Re: [v3 PATCH] oleaut32: Improve support for IDispatch in VarCat
by Marvin 18 Apr '17

18 Apr '17

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=30222 Your paranoid android. === wxppro (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2003std (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === wvistau64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2008s64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7u (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7pro64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w8 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w864 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w1064 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === wvistau64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2008s64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7pro64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w864 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w1064 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000

1 0

Re: [v2 2/3] d3dx9: Use magic number instead of parameter tables for parameter handles.
by Matteo Bruni 17 Apr '17

17 Apr '17

2017-04-11 15:58 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > static struct d3dx_parameter *get_valid_parameter(struct d3dx9_base_effect *base, D3DXHANDLE parameter) > { > - struct d3dx_parameter **handle_param = (struct d3dx_parameter **)parameter; > + struct d3dx_parameter *handle_param = (struct d3dx_parameter *)parameter; > > - if (handle_param >= base->param_table.table && handle_param < base->param_table.table + base->param_table.count) > - return *handle_param; > + if (handle_param && !strncmp(handle_param->magic_string, parameter_magic_string, > + sizeof(parameter_magic_string))) > + return handle_param; > > return get_parameter_by_name(base, NULL, parameter); > } Not new and somewhat separate from the patch, although it gets "more interesting" with the new handles scheme: we should probably avoid the call to get_parameter_by_name() if the effect was created with the D3DXFX_LARGEADDRESSAWARE flag, returning NULL instead. Worth a test I think.

2 4

Re: [5/6] secur32/tests: Add tests with SECPKG_ATTR_KEY_INFO.
by Marvin 17 Apr '17

17 Apr '17

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=30216 Your paranoid android. === wxppro (32 bit schannel) === schannel.c:931: Test failed: key_info.SignatureAlgorithm = 0000 schannel.c:932: Test failed: key_info.sSignatureAlgorithmName = PKCS === w2003std (32 bit schannel) === schannel.c:931: Test failed: key_info.SignatureAlgorithm = 0000 schannel.c:932: Test failed: key_info.sSignatureAlgorithmName = PKCS

1 0

Re: [PATCH 10/10] wined3d: Update only dirty region for level 0 in wined3d_device_update_texture().
by Marvin 17 Apr '17

17 Apr '17

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

1 0

Re: [PATCH] oleaut32: Improve support for IDispatch in VarCat
by Nikolay Sivov 17 Apr '17

17 Apr '17

Another thing I noticed, also unrelated to your changes, but to VarCat - static strings there should go away.

1 0

Re: localeNameToLCID
by Marvin 16 Apr '17

16 Apr '17

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=30192 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 16 Apr '17

16 Apr '17

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=30191 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 16 Apr '17

16 Apr '17

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=30190 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: locale
by Marvin 16 Apr '17

16 Apr '17

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=30189 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test inparse_locale_name()
by Marvin 16 Apr '17

16 Apr '17

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=30188 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 16 Apr '17

16 Apr '17

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=30187 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 15 Apr '17

15 Apr '17

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=30184 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 15 Apr '17

15 Apr '17

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=30183 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 15 Apr '17

15 Apr '17

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=30182 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 15 Apr '17

15 Apr '17

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=30181 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test inparse_locale_name()
by Nikolay Sivov 14 Apr '17

14 Apr '17

On 14.04.2017 13:58, loagen95 wrote: > I tried in this way ,but it doesn't work. > 发自我的iPhone Please be more specific, what did you try and it didn't work? > > > ------------------ Original ------------------ > *From:* Nikolay Sivov <bunglehead(a)gmail.com> > *Date:* Fri,Apr 14,2017 18:42 > *To:* wine-devel <wine-devel(a)winehq.org> > *Cc:* loagen95 <loagen95(a)gmail.com> > *Subject:* Re: PATCH:kernel32/locale:Fix some bugs about special Chinese > test inparse_locale_name() > > On 14.04.2017 13:21, THuang wrote: >> >> > > >> @@ -457,6 +457,8 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) >> static const WCHAR cW[] = {'C',0}; >> static const WCHAR latinW[] = {'l','a','t','i','n',0}; >> static const WCHAR latnW[] = {'-','L','a','t','n',0}; >> + static const WCHAR HantW[] = {'-','H','a','n','t',0}; >> + static const WCHAR HansW[] = {'-','H','a','n','s',0}; >> WCHAR *p; >> >> TRACE("%s\n", debugstr_w(str)); >> @@ -487,6 +489,16 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) >> else if (*p == '-') /* Windows format */ >> { >> strcpyW( name->win_name, name->lang ); >> + if(!strcmpiW(p,HantW)){ >> + name->lcid = 0x0c04; >> + name->matches = 1; >> + return ; >> + } >> + if(!strcmpiW(p,HansW)){ >> + name->lcid = 0x0804; >> + name->matches = 1; >> + return ; >> + } >> *p++ = 0; >> name->country = p; >> if (!(p = strpbrkW( p, winsepW ))) goto done; > > Well, no, that's not how it works. Did you explore a possibility if > adding hant/hans specific locale data to kernel32/nls will help? >

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Nikolay Sivov 14 Apr '17

14 Apr '17

On 14.04.2017 13:21, THuang wrote: > > > @@ -457,6 +457,8 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) > static const WCHAR cW[] = {'C',0}; > static const WCHAR latinW[] = {'l','a','t','i','n',0}; > static const WCHAR latnW[] = {'-','L','a','t','n',0}; > + static const WCHAR HantW[] = {'-','H','a','n','t',0}; > + static const WCHAR HansW[] = {'-','H','a','n','s',0}; > WCHAR *p; > > TRACE("%s\n", debugstr_w(str)); > @@ -487,6 +489,16 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) > else if (*p == '-') /* Windows format */ > { > strcpyW( name->win_name, name->lang ); > + if(!strcmpiW(p,HantW)){ > + name->lcid = 0x0c04; > + name->matches = 1; > + return ; > + } > + if(!strcmpiW(p,HansW)){ > + name->lcid = 0x0804; > + name->matches = 1; > + return ; > + } > *p++ = 0; > name->country = p; > if (!(p = strpbrkW( p, winsepW ))) goto done; Well, no, that's not how it works. Did you explore a possibility if adding hant/hans specific locale data to kernel32/nls will help?

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin 14 Apr '17

14 Apr '17

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=30177 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: [v2 3/3] d3dx9: Compare parameter definition instead of parameter handle in IsParameterUsed().
by Matteo Bruni 13 Apr '17

13 Apr '17

2017-04-11 15:58 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > is_same_parameter() is defined this way (argument type and placement in the file) > for a more straightforward reuse later in shared parameters implementation. > - if (walk_state_dep(&pass->states[j], compare_param_ptr, param)) > + if (walk_state_dep(&pass->states[j], (walk_parameter_dep_func)is_same_parameter, param)) The cast isn't nice though. Either change the signature of is_same_parameter() to match walk_parameter_dep_func or, if that really isn't an option, add a wrapper function with the correct signature and use that here instead. Even if you prefer the latter, it's probably better to do that only when you need it, in a later patch.

1 0

Re: [PATCH 1/3] d3dx9/tests: Add tests for cross effect handles usage.
by Matteo Bruni 13 Apr '17

13 Apr '17

2017-04-11 15:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 75 ++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 69 insertions(+), 6 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index de5ae69..62da636 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -4515,18 +4515,26 @@ static void test_isparameterused_children(ID3DXEffect *effect, D3DXHANDLE tech, > } > } > > -static void test_isparameterused_param_with_children(ID3DXEffect *effect, D3DXHANDLE tech, const char *name, > - BOOL expected_result) > +static void test_isparameterused_param_with_children(ID3DXEffect *effect, ID3DXEffect *effect2, D3DXHANDLE tech, > + const char *name, BOOL expected_result) I think you want to pass the source line to the function (like e.g. test_effect_preshader_compare_vconsts()) now that you call it from multiple places. > { > D3DXHANDLE param; > > - param = effect->lpVtbl->GetParameterByName(effect, NULL, name); > + ok(!effect->lpVtbl->IsParameterUsed(effect, (D3DXHANDLE)name, tech) == !expected_result, > + "Unexpected IsParameterUsed() result for %s.\n", name); > + > + if (effect2) > + param = effect2->lpVtbl->GetParameterByName(effect2, NULL, name); > + else > + param = effect->lpVtbl->GetParameterByName(effect, NULL, name); > ok(!!param, "GetParameterByName failed for %s.\n", name); > > + todo_wine_if(!!effect2 && expected_result) You don't need the !! here, the && gives an integer result anyway. > ok(!effect->lpVtbl->IsParameterUsed(effect, param, tech) == !expected_result, > "Unexpected IsParameterUsed() result for %s.\n", name); This is not new, but again the negations shouldn't be necessary. Actually if it turns out that they are, that means IsParameterUsed() doesn't always return a proper BOOL and that's an interesting result by itself. > +static void test_cross_effect_handle(IDirect3DDevice9 *device) > +{ > + ID3DXEffect *effect1, *effect2; > + D3DXHANDLE param1, param2; > + static int expected_ivect[4] = {28, 29, 30, 31}; > + int ivect[4]; > + HRESULT hr; > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, 0, NULL, &effect1, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, 0, NULL, &effect2, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); It probably makes sense to add a ok(effect1 != effect2) here, to show that native doesn't do effect object deduplication (which would trivially imply that the rest of this test passes). > + param1 = effect1->lpVtbl->GetParameterByName(effect1, NULL, "g_iVect"); > + ok(!!param1, "GetParameterByName failed.\n"); > + > + param2 = effect2->lpVtbl->GetParameterByName(effect2, NULL, "g_iVect"); > + ok(!!param2, "GetParameterByName failed.\n"); Same here with param1 and param2.

1 0

Re: [PATCH 1/8] mshtml/tests: Added IMarshal and IManagedObject QueryInterface tests.
by Marvin 13 Apr '17

13 Apr '17

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=30167 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2671: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5081: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 1/3] uuid: Include mscoree.idl.
by Alexandre Julliard 13 Apr '17

13 Apr '17

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/uuid/uuid.c | 1 + > 1 file changed, 1 insertion(+) > > > diff --git a/dlls/uuid/uuid.c b/dlls/uuid/uuid.c > index 913e99c..b8e15a2 100644 > --- a/dlls/uuid/uuid.c > +++ b/dlls/uuid/uuid.c > @@ -89,6 +89,7 @@ DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); > #include "netcfgx.h" > #include "shimgdata.h" > #include "comsvcs.h" > +#include "mscoree.h" That doesn't seem to match the PSDK. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcp90: Update exception RTTI data to reflect it's part of std namespace
by Piotr Caban 13 Apr '17

13 Apr '17

Hi, On 04/12/17 23:32, Daniel Lehman wrote: > -#ifdef _MSVCIRT > +#if defined(_MSVCIRT) || (_MSVCP_VER >= 80) I think that this condition should be following: #if _MSVCP_VER >= 80 ... AVexception@std #else ... AVexception Thanks, Piotr

1 0

Re: [v2 PATCH] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Marvin 13 Apr '17

13 Apr '17

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=30163 Your paranoid android. === wxppro (32 bit misc) === 0a20:misc: unhandled exception c0000005 at 5FE8DFF9

1 0

Re: [PATCH 2/3] mshtml/tests: Added IMarshal and IManagedObject QueryInterface tests.
by Marvin 12 Apr '17

12 Apr '17

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

1 0

Re: [PATCH 2/3] regedit: Validate REG_SZ import data before processing it any further
by Alexandre Julliard 12 Apr '17

12 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -390,6 +390,25 @@ static const WCHAR *reg_type_to_wchar(DWORD type) > return NULL; > } > > +static BOOL validate_reg_sz_data(WCHAR *str) > +{ > + WCHAR *p, *end; > + > + if (!*str || !(p = strchrW(str, '"'))) > + return FALSE; > + > + while (*p && *(p - 1) == '\\') > + p = strchrW(++p, '"'); The backslash could have been escaped, you have to check the whole string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] d3d9/tests: Relax the partially initialized varyings test (v2).
by Marvin 12 Apr '17

12 Apr '17

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

1 0

Re: [PATCH 5/5] d3d9/tests: Fix stream_test cases which do not use stream 0.
by Marvin 12 Apr '17

12 Apr '17

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=30146 Your paranoid android. === w8 (32 bit visual) === visual.c:7992: Test failed: Got unexpected color 0x00ff0000 for quad 2 (different colors).

1 0

Re: [PATCH 1/5] d3d9/tests: Relax the partially initialized varyings test.
by Marvin 12 Apr '17

12 Apr '17

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

1 0

Re: [1/2] winhttp/tests: Test when large amount of data is returned from a 401.
by Marvin 12 Apr '17

12 Apr '17

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=30140 Your paranoid android. === wxppro (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

2 1

Re: [2/2] winhttp: Always drain content before sending the next request.
by Marvin 12 Apr '17

12 Apr '17

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=30141 Your paranoid android. === w2003std (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

1 0

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Marvin 11 Apr '17

11 Apr '17

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=30136 Your paranoid android. === wvistau64 (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400 === w2008s64 (64 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

1 0

Re: [PATCH 2/5] wined3d: Send texture dirty region updates through the command stream.
by Józef Kucia 11 Apr '17

11 Apr '17

On Tue, Apr 11, 2017 at 11:24 PM, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > - context = context_acquire(texture->resource.device, NULL, 0); > - sub_resource_idx = layer * texture->level_count; > - for (i = 0; i < texture->level_count; ++i, ++sub_resource_idx) > - { > - if (!wined3d_texture_load_location(texture, sub_resource_idx, context, texture->resource.map_binding)) > - { > - ERR("Failed to load location %s.\n", wined3d_debug_location(texture->resource.map_binding)); > - context_release(context); > - return E_OUTOFMEMORY; > - } > - wined3d_texture_invalidate_location(texture, sub_resource_idx, ~texture->resource.map_binding); > - } > - context_release(context); > + wined3d_cs_emit_add_dirty_texture_region(texture->resource.device->cs, texture, layer * texture->level_count); I think that just "layer" should be passed as the last argument to wined3d_cs_emit_add_dirty_texture_region().

1 0

Re: [PATCH v2] mountmgr: Create registry entries for serial ports.
by Alexandre Julliard 11 Apr '17

11 Apr '17

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -453,7 +457,21 @@ NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > RegCloseKey( hkey ); > if (!RegCreateKeyExW( devicemap_key, serialW, 0, NULL, REG_OPTION_VOLATILE, > KEY_ALL_ACCESS, NULL, &hkey, NULL )) > + { > + /* create a registry entry for each serial port */ > + for (i = 1; i <= 256; i++) > + { > + sprintfW( pathW, comW, i ); > + serial_device = CreateFileW( pathW, 0, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); > + if (serial_device == INVALID_HANDLE_VALUE) > + break; > + > + CloseHandle( serial_device ); > + RegSetValueExW( hkey, pathW + 4, 0, REG_SZ, (BYTE *)(pathW + 4), > + (strlenW( pathW + 4 ) + 1) * sizeof(WCHAR) ); The registry key name is supposed to be the NT device. Ideally, what you'd want is to actually create the NT device pointing it to the corresponding Unix device, as well as the DOS symlink. If you do this, CreateFile can then use the normal path, and the ntdll serial device detection logic can be moved to mountmgr. -- Alexandre Julliard julliard(a)winehq.org

1 0

Putting in place traffic shaping on winehq
by Jeremy White 11 Apr '17

11 Apr '17

Hey folks, We've been getting nailed with peak charges on the traffic coming from the WineHQ web server. We think a large reason for this is that we were not sophisticated in how we flushed the fastly cache, so we'd get slammed in a big rush when we flushed. I believe that Jeremy Newman has fixed that now, so hopefully it won't happen again. But those overcharges are brutal (i.e. thousands of dollars) :-(. So I'm planning to put in place some traffic shaping to provide a hard upper limit for winehq (I'm going to impose 8Mbit; we currently pay for 10Mbpit committed; if I up that to 20, I may expand that). This should not disrupt anything, but I thought I'd warn folks, so you'd know to blame me if things suddenly go dark <grin>. Cheers, Jeremy

3 4

Re: [PATCH 2/4] user32/tests: Correctly restore the caption sizes when run in DPI scaling mode.
by Marvin 11 Apr '17

11 Apr '17

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=30112 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:272: SPI_SETSCREENSAVETIMEOUT failed for reason: 329. Indicating test failure and skipping remainder of test sysparams.c:273: Test failed: SystemParametersInfoA: rc=0 err=329 sysparams.c:273: Test failed: SystemParametersInfoA: rc=0 err=329 sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

2 1

Re: [PATCH 4/4] user32/tests: Fix tests for minimium icon spacing when not in DPI scaling mode.
by Marvin 11 Apr '17

11 Apr '17

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=30117 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [PATCH 3/4] user32/tests: Fix a few failures in DPI scaling mode.
by Marvin 11 Apr '17

11 Apr '17

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=30116 Your paranoid android. === w7u (32 bit sysparams) === sysparams.c:246: Test failed: Missed a message: change_counter=0 sysparams.c:249: Test failed: Wrong action got 0 expected 4 sysparams.c:246: Test failed: Missed a message: change_counter=0 sysparams.c:249: Test failed: Wrong action got 0 expected 4 === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === The task timed out

1 0

Re: [PATCH 2/2] regedit: Re-implement convertHextToDWord() (v3)
by Alexandre Julliard 11 Apr '17

11 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > + while (*buf == ' ' || *buf == '\t') buf++; > + if (!*buf) goto exit; > + > + p = buf; > + while (isxdigit(*p)) > + { > + count++; > + p++; > } > - return TRUE; > + if (count > 8) goto exit; > + > + end = p; > + while (*p == ' ' || *p == '\t') p++; > + if (*p && *p != ';') goto exit; > + > + *end = 0; > + *dw = strtoul(buf, &end, 16); > + ret = TRUE; > + > + exit: > + if (!ret) output_message(STRING_INVALID_HEX); > + HeapFree(GetProcessHeap(), 0, buf); The pointer has been modified, you need to free the original one. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2] endproc.c: Implement ProcessPage_OnEndProcessTree
by Stefan Dösinger 11 Apr '17

11 Apr '17

Hi Akarsha, Thank you for your patches! My apologies for the very late review of your code. I am currently catching up on my mail after moving :-\ . Your patch has numerous compile errors. Please make sure that the code compiles without errors or warnings before sending it. Am 2017-03-30 um 19:57 schrieb Akarsha Sehwag: > +typedef struct process_list { > + int *pid; /*dynamic array to store the process IDs*/ MODULEENTRY32.th32ProcessID is a DWORD, please use it here as well. > + SIZE_T count; /*index to maintain the last entry of the array;*/ > + SIZE_T size; /*the current size of the pid array*/ > +} process_list; Is it necessary to store the child processes in a separate list? I'd expect that CreateToolhelp32Snapshot creates a snapshot that is not affected by changes to the process tree after it returns. If this is the case you can kill processes as you iterate over the snapshot with Process32Next. This would simplify the code a lot If you keep the list please use a wine list from include/wine/list.h. This will also give you more flexibility in the order of how you kill the processes, see below. > +static void init_process_list(process_list *list) { > + list->size = 4; /*initialise size with 4. Will increase if necessary.*/ > + list->pid = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size * sizeof(int)); Minor style hint: You can use sizeof(*list->pid) instead of sizeof(int). That way the code doesn't need changes if the type of pid changes. > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + process_list_append(list, entry.th32ProcessID); > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + > + for(i = start; i < end; ++i) > + { > + enum_process_children(snapshot, list, list->pid[i]); > + } I am not sure if this matters, but this will kill parent processes before their children. It may or may not be the correct thing and may be an interesting thing to find out with a test (unfortunately writing automated tests for taskmgr is not easy) I think the same kind of recursion should work if you operate on the snapshot directly without the helper list. > + for(i = 0; i <= list->last; ++i) { > + hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list->pid[i]); > > --- patch 2 --- > - for(i = 0; i <= list->last; ++i) { > + for(i = 0; i < list->count; ++i) { This should be merged into patch 1. It is important that the code always builds to prevent problems in git bisect (e.g. assume I am looking for a regression in the d3d code, but one of the revisions I want to test doesn't compile taskmgr) With best regards, Stefan

1 1

Help on how to run winetest in debug
by Yashodeep Mahapatra 11 Apr '17

11 Apr '17

Hi All, This is Yashodeep Mahapatra from Birla Institute Of Technology ,Mesra,India. I tried running wine on my machine after building and installing it. But the problem that I am facing is that my system just keeps running the process wine and displays Wine Shell Script in the window. Running wine winecfg also runs in the same way without giving any output on the screen. I also tried running notepad.exe but only a blank screen appeared. wine winecfg command led to this output: err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 and nothing appeared on the screen. wine /programs/winetest/winetest.exe.so gave the following result: err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 Can anyone please help me?

3 2

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Hans Leidekker 11 Apr '17

11 Apr '17

On Tue, 2017-04-11 at 02:08 +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index a5eff11..0761c2e 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -2059,6 +2059,16 @@ static const char multiauth[] = > "Content-Type: text/plain\r\n" > "\r\n"; > > +static const char largeauth[] = > +"HTTP/1.1 401 Unauthorized\r\n" > +"Server: winetest\r\n" > +"WWW-Authenticate: Bearer\r\n" > +"WWW-Authenticate: Basic realm=\"placebo\"\r\n" > +"WWW-Authenticate: NTLM\r\n" > +"Content-Length: 10240\r\n" > +"Content-Type: text/plain\r\n" > +"\r\n"; Please try to be minimal. You're only using NTLM so the other two authenticate headers are not needed. > @@ -2172,6 +2182,20 @@ static DWORD CALLBACK server_thread(LPVOID param) > { > send(c, multiauth, sizeof multiauth - 1, 0); > } > + if(strstr(buffer, "GET /largeauth")) > + { > + if (strstr(buffer, "Authorization: NTLM")) > + send(c, okmsg, sizeof(okmsg) - 1, 0); > + else > + { > + void *data = malloc(10240); > + send(c, largeauth, sizeof largeauth - 1, 0); > + memset(data, 'A', 10240); > + send(c, data, 10240, 0); > + free(data); > + continue; You can avoid the allocation e.g. by sending 1 byte in a loop. > +static void test_large_data_authentication(int port) > +{ > + static const WCHAR largeauthW[] = {'/','l','a','r','g','e','a','u','t','h',0}; > + static const WCHAR getW[] = {'G','E','T',0}; > + static WCHAR userW[] = {'u','s','e','r',0}; > + static WCHAR passW[] = {'p','w','d',0}; > + HINTERNET ses, con, req; > + DWORD supported, first, target, status, size; > + BOOL ret; > + > + ses = WinHttpOpen(test_useragent, WINHTTP_ACCESS_TYPE_NO_PROXY, NULL, NULL, 0); > + ok(ses != NULL, "failed to open session %u\n", GetLastError()); > + > + con = WinHttpConnect(ses, localhostW, port, 0); > + ok(con != NULL, "failed to open a connection %u\n", GetLastError()); > + > + req = WinHttpOpenRequest(con, getW, largeauthW, NULL, NULL, NULL, 0); > + ok(req != NULL, "failed to open a request %u\n", GetLastError()); > + > + ret = WinHttpSendRequest(req, WINHTTP_NO_ADDITIONAL_HEADERS, 0, > + WINHTTP_NO_REQUEST_DATA,0, 0, 0 ); > + ok(ret, "expected success\n"); > + > + ret = WinHttpReceiveResponse(req, NULL); > + ok(ret, "expected success\n"); > + > + size = sizeof(status); > + ret = WinHttpQueryHeaders(req, WINHTTP_QUERY_STATUS_CODE | WINHTTP_QUERY_FLAG_NUMBER, NULL, > + &status, &size, NULL ); > + ok(ret, "expected success\n"); > + ok(status == HTTP_STATUS_DENIED, "got %d\n", status); > + > + supported = first = target = 0xdeadbeef; > + ret = WinHttpQueryAuthSchemes(req, &supported, &first, &target); > + ok(ret, "expected success\n"); > + ok(supported == (WINHTTP_AUTH_SCHEME_BASIC | WINHTTP_AUTH_SCHEME_NTLM), "got %x\n", supported); > + ok(target == WINHTTP_AUTH_TARGET_SERVER, "got %x\n", target); > + ok(first == WINHTTP_AUTH_SCHEME_BASIC, "got %x\n", first); This is also copied from another test and not strictly needed. You can hardcode scheme and target. WinHttpQueryAuthSchemes is already tested elsewhere.

1 0

Re: [v2 PATCH 2/2] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Huw Davies 11 Apr '17

11 Apr '17

On Mon, Apr 10, 2017 at 04:30:48AM +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index f28d464..2f415c7 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -303,6 +303,41 @@ static HMODULE load_config_driver(const WCHAR *driver) > return hmod; > } > > +static BOOL write_timeout_value(const WCHAR *driver, const WCHAR *args) > +{ > + static WCHAR cptimeout[] = {'C','P','T','i','m','e','o','u','t',0}; > + long ret; > + HKEY hkey; > + WCHAR *position; > + > + if ( !(position = strstrW(args, cptimeout))) > + return FALSE; > + > + if ((ret = RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + const WCHAR *value = &args[sizeof(cptimeout) / sizeof(WCHAR)]; > + > + TRACE("CPTimeout value %s\n", debugstr_w(value)); > + if(RegSetValueExW(hkeydriver, cptimeout, 0, REG_SZ, (BYTE*)value, > + strlenW(value) * sizeof(WCHAR)) != ERROR_SUCCESS) > + ERR("Failed to write registry installed key\n"); > + What are the possible formats of the arg string here? You initially strstr to find "CPTimeout" (which is fine). Later on, when you assign value, you're assuming that "CPTimeout" is at the beginning of the string (and this is a pretty ugly way of doing it). You're then writting anything that follows to the registry. Could there be more than one arg, if so how are they separated? Huw.

1 0

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Marvin 11 Apr '17

11 Apr '17

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=30105 Your paranoid android. === w864 (64 bit winhttp) === winhttp.c:3831: Test failed: got 80090321

1 0

Re: [PATCH 4/5] wined3d: Fix specular lighting calculation.
by Alexandre Julliard 10 Apr '17

10 Apr '17

Matteo Bruni <mbruni(a)codeweavers.com> writes: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > For bug 41827. > > I don't really like the shader_glsl_ffp_vertex_lighting_footer name but I > couldn't think of anything nicer... > > dlls/d3d8/tests/visual.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/d3d9/tests/visual.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/ddraw/tests/ddraw2.c | 49 +++++++++++++++++++++++++++++--------- > dlls/ddraw/tests/ddraw4.c | 51 +++++++++++++++++++++++++++++---------- > dlls/ddraw/tests/ddraw7.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/wined3d/glsl_shader.c | 50 +++++++++++++++------------------------ > 6 files changed, 225 insertions(+), 102 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so visual && touch visual.ok visual.c:793: Test failed: Expected color 0x00000000 at location (160, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (160, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (160, 360), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 360), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 360), got 0x00ffffff, case 7. visual.c:2790: Tests skipped: D3DFMT_P8 textures not supported. visual.c:4294: Tests skipped: No RESZ support, skipping RESZ test. visual.c:4971: Tests skipped: Volume DXT5 textures are not supported, skipping test. visual.c:6632: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. Makefile:246: recipe for target 'visual.ok' failed make: *** [visual.ok] Error 9 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] regedit/tests: Add tests for importing DWORD values
by Alexandre Julliard 10 Apr '17

10 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/tests/regedit.c | 56 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) It fails here: ../../../tools/runtest -q -P wine -T ../../.. -M regedit.exe -p regedit.exe_test.exe.so regedit && touch regedit.ok regedit.c:803: Test failed: RegQueryValueEx failed: got 2 regedit.c:804: Test failed: RegQueryValueEx failed: got 2 Makefile:174: recipe for target 'regedit.ok' failed make[1]: *** [regedit.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.
by Matteo Bruni 10 Apr '17

10 Apr '17

2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -697,13 +739,13 @@ static HRESULT parse_preshader(struct d3dx_preshader *pres, unsigned int *ptr, u > for (i = 0; i < pres->ins_count; ++i) > { > for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > - update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].table, > - get_reg_offset(pres->ins[i].inputs[j].table, > - pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].reg.table, > + get_reg_offset(pres->ins[i].inputs[j].reg.table, > + pres->ins[i].inputs[j].reg.offset + pres->ins[i].component_count - 1)); > > - update_table_size(pres->regs.table_sizes, pres->ins[i].output.table, > - get_reg_offset(pres->ins[i].output.table, > - pres->ins[i].output.offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].output.reg.table, > + get_reg_offset(pres->ins[i].output.reg.table, > + pres->ins[i].output.reg.offset + pres->ins[i].component_count - 1)); Do these update_table_size() always do the right thing with relative addressing? If I'm not mistaken, they should be fine because we only accept relative addressing for CONST and IMMED and the former is taken care by update_table_sizes_consts() just below while the latter's size is set statically just above this chunk. I think that means though that we don't need to call update_table_size() on the input arguments. If that sounds right to you, you could drop that "for(j)" altogether or, probably better, replace the update_table_size() with a check that the argument is not out of bounds (probably returning failure if the check doesn't pass). That should be a separate patch. > @@ -1088,18 +1130,65 @@ static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstan > return ret; > } > > +static double exec_get_reg_value(struct d3dx_regstore *rs, enum pres_reg_tables table, unsigned int offset) > +{ > + if (!regstore_is_val_set_reg(rs, table, offset / table_info[table].reg_component_count)) > + WARN("Using uninitialized input, table %u, offset %u.\n", table, offset); > + > + return regstore_get_double(rs, table, offset); > +} > + > static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) > { > - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) > - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); > + unsigned int offset, base_index, reg_index, table; > + > + table = opr->reg.table; > + > + if (opr->index_reg.table == PRES_REGTAB_COUNT) > + base_index = 0; > + else > + base_index = lrint(exec_get_reg_value(rs, opr->index_reg.table, opr->index_reg.offset)); > + > + /* '4' is used instead of reg_component_count, as immediate constants (which have > + * reg_component_count of 1) are still indexed as 4 values according to the tests. > + */ > + offset = base_index * 4 + opr->reg.offset + comp; Actually, is there any reason why reg_component_count for PRES_REGTAB_IMMED isn't 4? Maybe change it to 4 and in parse_preshader() check that const_count is a multiple of 4 (which is something we're depending on anyway). That would be a separate patch too. Clue me if I'm missing anything. > + reg_index = offset / table_info[table].reg_component_count; > + > + if (reg_index >= rs->table_sizes[table]) > + { > + unsigned int wrap_size; > + > + if (table == PRES_REGTAB_CONST) > + { > + /* As it can be guessed from tests (by iterating base register value and > + * observing the period of result values repeat), offset into floating > + * constant table are wrapped to the nearest power of 2 and not to the > + * actual table size. > + */ > + for (wrap_size = 1; wrap_size < rs->table_sizes[table]; wrap_size <<= 1) > + ; Please close the comment on the last text line (i.e. "*/" shouldn't be on its own line) and maybe remove the part in parentheses which is pretty obvious. I like the comment otherwise. Another thing on this, maybe add a WARN() on wrapped accesses to show what offset (or value) is returned in that case? Ignore it if you don't think that's useful.

2 9

Re: [3/3] [resend] wsdapi/tests: Add initial tests for WSDCreateDiscoveryPublisher
by Alexandre Julliard 10 Apr '17

10 Apr '17

Owen Rudge <orudge(a)codeweavers.com> writes: > +START_TEST(discovery) > +{ > + HMODULE dllHandle; > + > + CoInitialize(NULL); > + > + dllHandle = LoadLibraryA("wsdapi.dll"); > + > + if (dllHandle) > + { > + BOOL ret; > + > + ret = FreeLibrary(dllHandle); > + ok(ret, "FreeLibrary(1) returned %d\n", GetLastError()); > + } This test doesn't seem very useful. Also there shouldn't be any reason to load the library dynamically, you could simply link to it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/13] msidb: Add stub tool for manipulating MSI databases.
by Hans Leidekker 10 Apr '17

10 Apr '17

On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote: > The "Windows SDK Components for Windows Installer Developers" has a > command line tool called msidb that is incredibly useful for creating, > editing, and exporting MSI installer databases, think of it as > winemsibuilder on steroids. This patch series implements much of the > functionality of the msidb tool, maintains compatible CLI flags, and > the underlying MSI functionality necessary to support these features. > With this patch series all the existing winemsibuilder functionality > is available, plus the ability to drop streams, export the > _SummaryInformation table, export binary streams (Binary/Icon tables), > and some miscellaneous bug fixes. A big feature of the implementation > is that it allows you to edit existing installer databases, rather > than just creating new ones. I can see how the extra functionality is useful for package builders but at the same time it's not essential to build Wine. That doesn't mean we can't maintain it in Wine, but I can also see it being part of a separate SDK tools project. Have you considered that?

2 1

Re: [PATCH] regedit: Do not import DWORD values beginning with "0x" (v2)
by Marvin 10 Apr '17

10 Apr '17

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

1 0

Re: [PATCH] xmllite/writer: Fix IID argument handling in CreateXmlWriter()
by Jacek Caban 10 Apr '17

10 Apr '17

Hi Nikolay, On 4/10/17 6:37 AM, Nikolay Sivov wrote: > + hr = CreateXmlWriter(&IID_IStream, (void **)&unk, NULL); > + ok(hr == E_NOINTERFACE, "got %08x\n", hr); > + > + hr = CreateXmlWriter(&IID_IUnknown, (void **)&unk, NULL); > + ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + hr = IUnknown_QueryInterface(unk, &IID_IUnknown, (void **)&writer); > + I think you meant IID_IXmlWriter here. Jacek

2 1

Re: [PATCH 2/2] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Marvin 10 Apr '17

10 Apr '17

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=30067 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 2/2 v2] ntdll: Zero debug registers after thread creation
by Michael Müller 09 Apr '17

09 Apr '17

Am 07.04.2017 um 17:52 schrieb Christian Inci: > DWORD tid = 0; > int request_pipe[2]; > + CONTEXT ctx; > NTSTATUS status; > > [...] > > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + NtSetContextThread(handle, &ctx); > + You didn't initialize the register values and therefore set the debug registers to random stack values. You should either initialize them manually or memset the whole struct.

3 4

Re: [PATCH v2 1/5] wined3d: Save pixel and vertex shader resource views in stateblocks.
by Henri Verbeet 09 Apr '17

09 Apr '17

On 5 April 2017 at 15:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3129,6 +3129,8 @@ struct wined3d_saved_states > WORD vertexShaderConstantsB; /* WINED3D_MAX_CONSTS_B, 16 */ > WORD vertexShaderConstantsI; /* WINED3D_MAX_CONSTS_I, 16 */ > BOOL vs_consts_f[WINED3D_MAX_VS_CONSTS_F]; > + DWORD pixel_shader_resource_views : 16; /* MAX_FRAGMENT_SAMPLERS, 16 */ > + DWORD vertex_shader_resource_views : 4; /* MAX_VERTEX_SAMPLERS, 4 */ > DWORD textures : 20; /* MAX_COMBINED_SAMPLERS, 20 */ > DWORD indices : 1; > DWORD material : 1; > @@ -3137,17 +3139,18 @@ struct wined3d_saved_states > DWORD pixelShader : 1; > DWORD vertexShader : 1; > DWORD scissorRect : 1; > - DWORD padding : 5; > + DWORD padding : 17; That doesn't do the right thing, unfortunately: struct wined3d_saved_states { DWORD transform[16]; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ WORD streamSource; /* 64 2 */ WORD streamFreq; /* 66 2 */ DWORD renderState[7]; /* 68 28 */ DWORD textureState[8]; /* 96 32 */ /* --- cacheline 2 boundary (128 bytes) --- */ WORD samplerState[20]; /* 128 40 */ DWORD clipplane; /* 168 4 */ WORD pixelShaderConstantsB; /* 172 2 */ WORD pixelShaderConstantsI; /* 174 2 */ BOOL ps_consts_f[224]; /* 176 896 */ /* --- cacheline 16 boundary (1024 bytes) was 48 bytes ago --- */ WORD vertexShaderConstantsB; /* 1072 2 */ WORD vertexShaderConstantsI; /* 1074 2 */ BOOL vs_consts_f[256]; /* 1076 1024 */ /* --- cacheline 32 boundary (2048 bytes) was 52 bytes ago --- */ DWORD pixel_shader_resource_views:16; /* 2100:16 4 */ DWORD vertex_shader_resource_views:4; /* 2100:12 4 */ /* XXX 12 bits hole, try to pack */ DWORD textures:20; /* 2104:12 4 */ DWORD indices:1; /* 2104:11 4 */ DWORD material:1; /* 2104:10 4 */ DWORD viewport:1; /* 2104: 9 4 */ DWORD vertexDecl:1; /* 2104: 8 4 */ DWORD pixelShader:1; /* 2104: 7 4 */ DWORD vertexShader:1; /* 2104: 6 4 */ DWORD scissorRect:1; /* 2104: 5 4 */ /* XXX 5 bits hole, try to pack */ DWORD padding:17; /* 2108:15 4 */ /* --- cacheline 33 boundary (2112 bytes) --- */ /* size: 2112, cachelines: 33, members: 24 */ /* bit holes: 2, sum bit holes: 17 bits */ /* bit_padding: 15 bits */ }; Incidentally, this also illustrates the issue of the ps_consts_f and vs_consts_f fields using up way more space than needed.

3 2

Re: [resend PATCH 4/4] d3dx9: Effect should preserve states regardless of state manager presence.
by Matteo Bruni 09 Apr '17

09 Apr '17

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> Given that you have to resend anyway... It's generally preferred to write commit subjects in the imperative mood, so in this case it would be "Preserve states regardless of state manager presence." A slightly different, more direct, alternative would be "Ignore state manager when saving and restoring device state." Choose whatever you prefer (including something else entirely).

1 0

Re: [resend PATCH 2/4] d3dx9/tests: Add tests for effect state manager.
by Matteo Bruni 09 Apr '17

09 Apr '17

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > + static const struct test_state_manager_update test_effect_states_record[] = expected_updates[]?

1 0

Re: [resend PATCH 1/4] d3dx9/tests: Add test implementation for ID3DXEffectStateManager interface.
by Matteo Bruni 09 Apr '17

09 Apr '17

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct test_state_manager_update > +{ > + unsigned int state_op; > + DWORD param1; > + DWORD param2; > +}; > + > +struct test_ID3DXEffectStateManagerImpl Sorry for being a PITA but it would be better to avoid this kind of naming, at a first glance it might be confused with a MS structure. Just call it test_manager or similar. > +static HRESULT WINAPI test_ID3DXEffectStateManagerImpl_QueryInterface(ID3DXEffectStateManager *iface, > + REFIID riid, void **object) > +{ > + if (IsEqualGUID(riid, &IID_IUnknown) > + || IsEqualGUID(riid, &IID_ID3DXEffectStateManager)) > + { > + iface->lpVtbl->AddRef(iface); > + *object = iface; > + return S_OK; > + } > + > + return E_NOINTERFACE; > +} Do you know if this is called by d3dx9 at all? Either way, adding some ok() here would be nice. > + state_manager->update_record = new_alloc; > + state_manager->update_record_size = new_size; > + > + } Spurious blank line. Also I'm not sure it makes a lot of sense to use new_alloc / new_size and check that the allocation succeeded with ok() to then always assign the new variables to the struct fields anyway. Memory allocation should never legitimately fail there so I'd remove the vestigial error checking entirely and let the test crash if the allocation somehow fails.

1 0

Re: [PATCH] d3dx11: Add D3DX11FilterTexture stub.
by Matteo Bruni 09 Apr '17

09 Apr '17

2017-04-03 18:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > diff --git a/include/d3dx11tex.h b/include/d3dx11tex.h > index 16b280a..81a43cc 100644 > --- a/include/d3dx11tex.h > +++ b/include/d3dx11tex.h > @@ -93,6 +93,8 @@ HRESULT WINAPI D3DX11CreateShaderResourceViewFromMemory(ID3D11Device *device, co > HRESULT WINAPI D3DX11CreateTextureFromMemory(ID3D11Device *device, const void *src_data, SIZE_T src_data_size, > D3DX11_IMAGE_LOAD_INFO *loadinfo, ID3DX11ThreadPump *pump, ID3D11Resource **texture, HRESULT *hresult); > > +HRESULT WINAPI D3DX11FilterTexture(ID3D11DeviceContext *context, ID3D11Resource *texture, UINT src_level, UINT filter); > + > HRESULT WINAPI D3DX11GetImageInfoFromMemory(const void *src_data, SIZE_T src_data_size, ID3DX11ThreadPump *pump, > D3DX11_IMAGE_INFO *img_info, HRESULT *hresult); > > -- > 2.7.4 Could you please also add the D3DX11_FILTER_FLAG definition to d3dx11tex.h? Looks okay otherwise.

1 0

GSoC Mentors
by André Hentschel 09 Apr '17

09 Apr '17

Hi, for those who had not had a look at the proposals yet, please review them and comment. Thanks!

1 0

Re: [PATCH v5] ntdll/tests: Check debug registers of a newly created thread
by Marvin 09 Apr '17

09 Apr '17

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=30054 Your paranoid android. === build (build) === Make failed

1 0

Wine-Staging Performance Regression since 2.0rc6
by Bjoern Bidar/Thaodan 08 Apr '17

08 Apr '17

Hello guys I hope this is the right place to ask. Since after 2.0rc6 many Wow user getting worse performance. For comparsion: 2.0rc6: 65fps 2.1/2.2: about 40 2.4: no change either even the main menu lags when you look close. To test just download the game and open it even the main menu lags as said before. Me and many users don't know how to help in debugging the issue, so im asking here. Greetings Björn

1 0

Re: [PATCH 2/4] winex11: move XDestroyWindow() after free_gl_drawable() in set_win_format()
by Alexandre Julliard 08 Apr '17

08 Apr '17

Miklós Máté <mtmkls(a)gmail.com> writes: > @@ -1334,21 +1334,21 @@ static void free_gl_drawable( struct gl_drawable *gl ) > /*********************************************************************** > * create_gl_drawable > */ > -static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl ) > +static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl, struct x11drv_win_data *data ) > { > gl->drawable = 0; > > if (GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow()) /* top-level window */ > { > - struct x11drv_win_data *data = get_win_data( hwnd ); > - > if (data) > { > gl->type = DC_GL_WINDOW; > gl->window = create_client_window( data, gl->visual ); > if (gl->window) > + { > gl->drawable = pglXCreateWindow( gdi_display, gl->format->fbconfig, gl->window, NULL ); > - release_win_data( data ); > + XSync( gdi_display, False ); Do you really need all the extra XSync calls? We try to avoid server round-trips as much as possible. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v4] ntdll/tests: Check debug registers of a newly created thread
by Dmitry Timoshkov 08 Apr '17

08 Apr '17

Hi Christian, Christian Inci <chris.wine(a)broke-the-inter.net> wrote: > + thread = CreateThread(NULL, 0, dummy_thread, NULL, CREATE_SUSPENDED, NULL); > + ok(thread != INVALID_HANDLE_VALUE, "CreateThread failed with %d\n", GetLastError()); > + memset(&ctx, 0, sizeof(ctx)); > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + status = pNtGetContextThread(thread, &ctx); > + ok(status == STATUS_SUCCESS, "NtGetContextThread failed with %x\n", status); > + ok(!ctx.Dr0, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr0); > + ok(!ctx.Dr1, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr1); > + ok(!ctx.Dr2, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr2); > + ok(!ctx.Dr3, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr3); > + todo_wine ok(!ctx.Dr6, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr6); > + todo_wine ok(!ctx.Dr7, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr7); > + CloseHandle(thread); > +} The thread needs to be explicitly terminated. -- Dmitry.

2 1

Re: [PATCH] tools/winedump: Change duplicate flag.
by Alexandre Julliard 07 Apr '17

07 Apr '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > diff --git a/tools/winedump/main.c b/tools/winedump/main.c > index a4ebb43..5c683f6 100644 > --- a/tools/winedump/main.c > +++ b/tools/winedump/main.c > @@ -226,7 +226,7 @@ static const struct my_option option_table[] = { > {"-v", SPEC, 0, do_verbose, "-v Show lots of detail while working (verbose)."}, > {"dump", DUMP, 0, do_dump, "dump <file> Dump the contents of 'file' (dll, exe, lib...)"}, > {"-C", DUMP, 0, do_symdmngl, "-C Turn on symbol demangling"}, > - {"-f", DUMP, 0, do_dumphead, "-f Dump file header information"}, > + {"-F", DUMP, 0, do_dumphead, "-F Dump file header information"}, Not a big deal, but is there a reason for changing this? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v2] ntdll/tests: Check debug registers of a newly created thread
by Christian Inci 07 Apr '17

07 Apr '17

Forgot to send the response to wine-devel too. On 04/07/2017 10:01 PM, Christian Inci wrote: > Thank you very much for letting me know. > > Setting Dr7 with the "wrong" bits set will result into this error. > I'm going to change the testcase right now. > > On 04/07/2017 09:07 PM, Alexandre Julliard wrote: >> Christian Inci <chris.wine(a)broke-the-inter.net> writes: >> >>> +static void test_thread_debug_registers(void) >>> +{ >>> + HANDLE thread; >>> + CONTEXT ctx; >>> + NTSTATUS status; >>> + >>> + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; >>> + ctx.Dr0 = 0xffffffff; >>> + ctx.Dr1 = 0xffffffff; >>> + ctx.Dr2 = 0xffffffff; >>> + ctx.Dr3 = 0xffffffff; >>> + ctx.Dr6 = 0xffffffff; >>> + ctx.Dr7 = 0xffffffff; >>> + status = pNtSetContextThread(GetCurrentThread(), &ctx); >>> + todo_wine ok(status == STATUS_SUCCESS, "NtSetContextThread failed with %x\n", status); >> >> It would be a more convincing test if setting the context succeeded. The >> failure is of course interesting too, but that could be a separate test. >>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel