- wine-devel - winehq.org

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

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