- wine-devel - winehq.org

Re: [PATCH 3/4] quartz: fix crash in FilterGraph2_Render
by Andrew Eikum 02 Jun '17

02 Jun '17

Can you add a test for this? Andrew On Thu, May 25, 2017 at 04:54:49PM +0200, Miklós Máté wrote: > Note: there are a lot of other places as well where the null pointer handling > is present in the msdn docs but missing in wine. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/quartz/filtergraph.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index a143b05d83..e26eb199c8 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -1279,6 +1279,9 @@ static HRESULT WINAPI FilterGraph2_Render(IFilterGraph2 *iface, IPin *ppinOut) > > TRACE("(%p/%p)->(%p)\n", This, iface, ppinOut); > > + if (!ppinOut) > + return E_POINTER; > + > if (TRACE_ON(quartz)) > { > PIN_INFO PinInfo; > -- > 2.11.0 > > >

3 2

Re: [PATCH 1/4] quartz: AsyncReader is always expected to have output pin
by Andrew Eikum 01 Jun '17

01 Jun '17

Thanks for working on this. I tested your patch sequence against a number of games as well as embedding videos in MSOffice 2007 and 2010 and found no regressions. I do have some comments, though, in-line below. Is this something you could write a test for? E.g. create the filter and then query for its output pin immediately after creation. On Thu, May 25, 2017 at 04:54:47PM +0200, Miklós Máté wrote: > Even between create() and Load(). This fixes a crash in DSPlayer. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/quartz/filesource.c | 31 ++++++++++++++++++++----------- > 1 file changed, 20 insertions(+), 11 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index ed7e5ee201..200463ff5b 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -73,7 +73,8 @@ static const IFileSourceFilterVtbl FileSource_Vtbl; > static const IAsyncReaderVtbl FileAsyncReader_Vtbl; > static const IAMFilterMiscFlagsVtbl IAMFilterMiscFlags_Vtbl; > > -static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin); > +static HRESULT FileAsyncReader_Construct(IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin); > +static HRESULT FileAsyncReader_SetFile(IAsyncReader * iface, HANDLE hFile); > > static const WCHAR mediatype_name[] = { > 'M', 'e', 'd', 'i', 'a', ' ', 'T', 'y', 'p', 'e', 0 }; > @@ -416,6 +417,7 @@ static const BaseFilterFuncTable BaseFuncTable = { > HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > { > AsyncReader *pAsyncRead; > + HRESULT hr; > > if( pUnkOuter ) > return CLASS_E_NOAGGREGATION; > @@ -429,7 +431,8 @@ HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > > pAsyncRead->IFileSourceFilter_iface.lpVtbl = &FileSource_Vtbl; > pAsyncRead->IAMFilterMiscFlags_iface.lpVtbl = &IAMFilterMiscFlags_Vtbl; > - pAsyncRead->pOutputPin = NULL; > + hr = FileAsyncReader_Construct(&pAsyncRead->filter.IBaseFilter_iface, &pAsyncRead->filter.csFilter, &pAsyncRead->pOutputPin); > + BaseFilterImpl_IncrementPinVersion(&pAsyncRead->filter); If this fails, I think we should free resources and return the error immediately. > > pAsyncRead->pszFileName = NULL; > pAsyncRead->pmt = NULL; > @@ -438,7 +441,7 @@ HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > > TRACE("-- created at %p\n", pAsyncRead); > > - return S_OK; > + return hr; > } > > /** IUnknown methods **/ > @@ -606,7 +609,7 @@ static ULONG WINAPI FileSource_Release(IFileSourceFilter * iface) > > static HRESULT WINAPI FileSource_Load(IFileSourceFilter * iface, LPCOLESTR pszFileName, const AM_MEDIA_TYPE * pmt) > { > - HRESULT hr; > + HRESULT hr = E_FAIL; > HANDLE hFile; > IAsyncReader * pReader = NULL; > AsyncReader *This = impl_from_IFileSourceFilter(iface); > @@ -625,16 +628,15 @@ static HRESULT WINAPI FileSource_Load(IFileSourceFilter * iface, LPCOLESTR pszFi > return HRESULT_FROM_WIN32(GetLastError()); > } > > - /* create pin */ > - hr = FileAsyncReader_Construct(hFile, &This->filter.IBaseFilter_iface, &This->filter.csFilter, &This->pOutputPin); > - BaseFilterImpl_IncrementPinVersion(&This->filter); > > - if (SUCCEEDED(hr)) > + if (This->pOutputPin) Since we now create the output pin during filter creation, this should never be non-NULL, right? > hr = IPin_QueryInterface(This->pOutputPin, &IID_IAsyncReader, (LPVOID *)&pReader); > > /* store file name & media type */ > if (SUCCEEDED(hr)) > { > + FileAsyncReader_SetFile(pReader, hFile); > + > CoTaskMemFree(This->pszFileName); > if (This->pmt) > FreeMediaType(This->pmt); > @@ -939,7 +941,7 @@ static const BaseOutputPinFuncTable output_BaseOutputFuncTable = { > BaseOutputPinImpl_BreakConnect > }; > > -static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin) > +static HRESULT FileAsyncReader_Construct(IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin) > { > PIN_INFO piOutput; > HRESULT hr; > @@ -952,9 +954,8 @@ static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter > > if (SUCCEEDED(hr)) > { > - FileAsyncReader *pPinImpl = (FileAsyncReader *)*ppPin; > + FileAsyncReader *pPinImpl = impl_from_IPin(*ppPin); > pPinImpl->IAsyncReader_iface.lpVtbl = &FileAsyncReader_Vtbl; > - pPinImpl->hFile = hFile; > pPinImpl->bFlushing = FALSE; > pPinImpl->sample_list = NULL; > pPinImpl->handle_list = NULL; > @@ -965,6 +966,14 @@ static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter > return hr; > } > > +static HRESULT FileAsyncReader_SetFile(IAsyncReader * iface, HANDLE hFile) > +{ > + FileAsyncReader *This = impl_from_IAsyncReader(iface); > + > + This->hFile = hFile; > + return S_OK; > +} > + Why is this a separate function instead of just setting hFile in FileSource_Load? > /* IAsyncReader */ > > static HRESULT WINAPI FileAsyncReader_QueryInterface(IAsyncReader * iface, REFIID riid, LPVOID * ppv) > -- > 2.11.0 > > >

2 1

Re: ntdll: On macOS, don't use clock_gettime() even if it's available.
by Michael Müller 01 Jun '17

01 Jun '17

Not sure which one of two commands is causing the lower overhead, but shouldn't you just build Wine using the 10.11 SDK if you plan to deploy it on 10.11? This could theoretically also apply to other parts of Wine and I don't think it makes sense to add backwards compatibility hacks everywhere. Regards, Michael

2 1

Re: [PATCH] msacm32: Correctly allocate WAVEFORMATEX.
by Andrew Eikum 01 Jun '17

01 Jun '17

This doesn't look right to me. According to MSDN[1], the cbFormatSize field should already be the full size of the format struct. It's possible MSDN is wrong, but we'd need tests to prove that first. Who sets cbFormatSize? Could the error be there? [1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd742918(v=vs.85).… Andrew On Wed, May 31, 2017 at 06:03:58PM -0500, Zebediah Figura wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=26388 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msacm32/format.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/msacm32/format.c b/dlls/msacm32/format.c > index de07cba9a3..ec46cae163 100644 > --- a/dlls/msacm32/format.c > +++ b/dlls/msacm32/format.c > @@ -75,7 +75,7 @@ static BOOL CALLBACK MSACM_FillFormatTagsCB(HACMDRIVERID hadid, > > afd.cbStruct = sizeof(afd); > afd.dwFormatTag = paftd->dwFormatTag; > - afd.pwfx = HeapAlloc(MSACM_hHeap, 0, paftd->cbFormatSize); > + afd.pwfx = HeapAlloc(MSACM_hHeap, 0, sizeof(WAVEFORMATEX) + paftd->cbFormatSize); > if (!afd.pwfx) return FALSE; > afd.pwfx->wFormatTag = paftd->dwFormatTag; > afd.pwfx->cbSize = paftd->cbFormatSize; > -- > 2.13.0 > > >

1 0

Re: PATCH 1/7] msvcrt: Translate SEH exception on each call to __CxxFrameHandler.
by Piotr Caban 01 Jun '17

01 Jun '17

On 05/24/17 02:54, Daniel Lehman wrote: > +extern void __wine_rtl_unwind( EXCEPTION_REGISTRATION_RECORD* frame, EXCEPTION_RECORD *record, > + void (*target)(void) ); It's already defined in wine/exception.h. > +extern void CDECL __DestructExceptionObject(EXCEPTION_RECORD *rec); This is also already defined (in msvcrt.h) > + > +static void DECLSPEC_NORETURN seh_unwind_target(void) > +{ > + seh_frame_info *seh_frame = (seh_frame_info *)__wine_get_frame(); > + __wine_pop_frame( &seh_frame->frame ); There's no need to call __wine_pop_frame here, it will be done after the jump anyway. I think that the whole series will be cleaner/easier to read if we add the __EXCEPT_CTX/__FINALLY_CTX macros and use them here. I'm attaching a patch with proposition of changes for this functions. With such changes your patch will look like this (this is not tested): typedef struct { ULONG64 dest_frame; ULONG64 orig_frame; DISPATCHER_CONTEXT *dispatch; const cxx_function_descr *descr; } se_translator_ctx; static DWORD se_translation_filter(EXCEPTION_POINTERS *ep, void *c) { se_translator_ctx *ctx = (se_translator_ctx*)c; /* this is copied from original patch but I think that */ /* terminate should be called on non C++ exceptions here */ if (ep->rec->ExceptionCode != CXX_EXCEPTION) return ExceptionContinueSearch; find_catch_block(...); __DestructExceptionObject(ep->rec); return ExceptionExecuteHandler; } in cxx_frame_handler: if (data->se_translator) { se_translator_ctx ctx; //initialize ctx __TRY { except_ptrs.ExceptionRecord = rec; except_ptrs.ContextRecord = context; data->se_translator(rec->ExceptionCode, &except_ptrs); } __EXCEPT_CTX(se_translation_filter, &ctx) { } __END_TRY } With such changes second patch can be also changed to use __TRY/__FINALLY_CTX around "ret_addr = handler(0, frame);" file. What do you think about it? Thanks, Piotr

2 1

Re: [PATCH 6/6] d3dx9: Merge constant setting for child parameters when possible.
by Matteo Bruni 31 May '17

31 May '17

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + if (!(const_set->table == current_table && current_start_offset == start_offset > + && const_set->direct_copy == first_const->direct_copy > + && current_data == const_set->param->data > + && (const_set->direct_copy || (first_const->param->type == const_set->param->type > + && first_const->param->class == const_set->param->class > + && first_const->param->columns == const_set->param->columns > + && first_const->param->rows == const_set->param->rows > + && first_const->register_count == const_set->register_count > + && (i == const_tab->const_set_count - 1 > + || first_const->param->element_count == const_set->param->element_count))))) > + { > + TRACE("direct_copy %u, i %u, index %u, param %s.%s, current_data %p, const_set->param->data %p, "\ > + "current_start_offset %u, start_offset %u, const_set->table %u, current_table %u.\n", > + const_set->direct_copy, i, index, debugstr_a(param->name), > + debugstr_a(const_set->param->name), current_data, const_set->param->data, > + current_start_offset, start_offset, const_set->table, current_table); > + break; > + } This looks like a debug trace. > + TRACE("Merging %u child parameters for %s, not merging %u, direct_copy %u.\n", i - index, > + debugstr_a(param->name), const_tab->const_set_count - i, first_const->direct_copy); I guess it's intentional that you're printing this even when not merging anything, in that case the TRACE sounds a bit awkward though. Maybe have a separate TRACE for that case? BTW, please format the BOOL with %#x. > + if (i > index + 1) > + { > + first_const->element_count = element_count; > + if (first_const->direct_copy) > + { > + first_const->element_count = 1; > + if (index == start_index > + && !(param->type == D3DXPT_VOID && param->class == D3DXPC_STRUCT)) > + { > + if (param_type_to_table_type(param->type) == PRES_VT_MAX) > + return D3DERR_INVALIDCALL; > + first_const->param = param; > + } > + first_const->register_count = get_reg_offset(current_table, current_start_offset) > + - first_const->register_index; > + } > + memmove(&const_tab->const_set[index + 1], &const_tab->const_set[i], > + sizeof(*const_tab->const_set) * (const_tab->const_set_count - i)); > + const_tab->const_set_count -= i - index - 1; > + } Just for my own curiosity, do you think it's significant to merge non-direct_copy entries? Not that it hurts anything to have it.

2 4

Re: [v2 2/6] d3dx9: Factor out get_const_upload_info() function.
by Matteo Bruni 31 May '17

31 May '17

2017-05-30 11:38 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v2: > - renamed 'n' to 'major_count'; major_count is still a bit meh, since "major" is really already a count and there is an unspecified "count" too. I don't have any good suggestion and this is an improvement over the current naming though, so...

1 0

Re: [PATCH 1/6] d3dx9: Get rid of table lookup for converting between register indexes and offsets.
by Matteo Bruni 31 May '17

31 May '17

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > static unsigned int get_reg_offset(unsigned int table, unsigned int offset) > { > - return offset / table_info[table].reg_component_count; > + return table == PRES_REGTAB_OBCONST ? offset : offset >> 2; > +} > + > +static unsigned int get_offset_reg(unsigned int table, unsigned int reg_idx) > +{ > + return table == PRES_REGTAB_OBCONST ? reg_idx : reg_idx << 2; > } I suppose using an explicit division and multiplication here wouldn't change the generated code, in which case I'd slightly prefer that. It doesn't matter right now, just mentioning it for potentially similar cases in the future. Also this patch probably should have been split in two, with the first patch introducing get_offset_reg() with no functional changes and the second hardcoding the table check / dropping the table lookup. Not worth a rework at this point I guess. > @@ -1033,9 +1035,9 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > unsigned int offset; > > offset = start_offset + i * major_stride + j; > - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) > + if (get_reg_offset(table, offset) >= rs->table_sizes[table]) > { > - if (table_info[table].reg_component_count != 1) > + if (table != PRES_REGTAB_OBCONST) > FIXME("Output offset exceeds table size, name %s, component %u.\n", > debugstr_a(param->name), i); > break; Not new and probably I just forgot the details, but, why would the register component count matter for the FIXME? > - offset = reg_index * table_info[table].reg_component_count > - + offset % table_info[table].reg_component_count; > + offset = get_offset_reg(table, reg_index) + offset % get_offset_reg(table, 1); That "get_offset_reg(table, 1)" comes up a number of times. Maybe worth making an extra get_reg_components(table) (or similar) helper? Simply for even greater clarity.

2 5

Re: [PATCH 3/6] d3d9: Validate adapter format in CheckDeviceFormat().
by Marvin 31 May '17

31 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=31280 Your paranoid android. === wvistau64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w2008s64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7u (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7pro64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w8 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w864 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w1064 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === wvistau64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w2008s64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7pro64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w864 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w1064 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4.

2 1

Re: [PATCH 2/6] d3d8: Validate adapter format in CheckDeviceFormat().
by Marvin 31 May '17

31 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=31279 Your paranoid android. === w8 (32 bit device) === device.c:2945: Test failed: Received WM_WINDOWPOSCHANGED but did not expect it.

1 0

RE: [PATCH 2/7] msvcrt: Clean up registered C++ object in handler.
by Daniel Lehman 31 May '17

31 May '17

On 05/24/17 02:55, Daniel Lehman wrote: > +static DWORD cxx_catch_cleanup(EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, > + CONTEXT *context, > +EXCEPTION_REGISTRATION_RECORD **pdispatcher) { > + if (rec->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND)) > + { > + thread_data_t *data = msvcrt_get_thread_data(); > + frame_info *cur; > + > + if (cxx_is_consolidate(rec)) > Is this condition really needed? Shouldn't we clean the object no matter what's the reason of unwind? Yeah. That's covered by patch 7/7. The original code only cleaned up if consolidating. Since this 2/7 patch was somewhat of a refactoring for the later patches, I kept the consolidate-only cleanup logic. I can merge them if you want >> + if ((ULONG64)cur <= (ULONG64)frame) > This condition is not working. It's making assumption about order of catch_frame and frame_info variables on stack while they are declared this way: I see what you mean. If I forcefully reverse them, my tests crash; my version of gcc was always putting them in the same place on the stack, regardless of where they were declared >> + EXCEPTION_REGISTRATION_RECORD catch_frame; >> cxx_frame_info frame_info; > Shouldn't the cxx_catch_cleanup just unregister the object that was registered in call_catch_block? I didn't find a way to be call __CxxUnregisterObject on that one specifically (I'll try suggestions if you got em) but the loop in cxx_catch_cleanup effective does this. when unwinding a nested exception, cxx_catch_cleanup will be called when unwinding call_catch_block, so all objects registered in call_catch_block and below will be cleaned up at that point. Unless the catch block itself explicitly calls __CxxRegisterObject, the only object on the list up to that frame will be the one from call_catch_block > Here's a test case that demonstrate the problem with cur <= frame > comparison: > > try { > try { int *p = NULL; *p = 0x42; } > catch (klass x) { throw 1; } > } catch (int i) { } > > try { throw 1; } > catch(...) {} This crashes for me even on Windows because the SEGV is uncaught. It 'works' if I set an seh translator that throws int, but I get identical results on Wine with my series applied. Do I need to add something? Thanks daniel

2 1

Re: [PATCH 7/7] regedit: Do not get text for items with an index less than one
by Alexandre Julliard 31 May '17

31 May '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -59,7 +59,7 @@ LPWSTR GetItemText(HWND hwndLV, UINT item) > { > LPWSTR newStr, curStr; > unsigned int maxLen = 128; > - if (item == 0) return NULL; /* first item is ALWAYS a default */ > + if (item < 1) return NULL; /* first item is ALWAYS a default */ How is this different? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 2/3] mfplat: Implement MFCreateMediaType
by Dmitry Timoshkov 30 May '17

30 May '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +struct IMFMediaTypeVtbl mediatype_vtbl = > +{ It should be 'static const', and without 'struct'. -- Dmitry.

1 0

Re: [7/7] wsdapi/tests: Add tests for Get/SetSockaddr.
by Marvin 30 May '17

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

1 0

Re: [6/7] wsdapi/tests: Add tests for Get/SetMessageType.
by Marvin 30 May '17

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

1 0

Re: [5/7] wsdapi/tests: Add tests for Get/SetPort.
by Marvin 30 May '17

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

1 0

Re: [4/7] wsdapi/tests: Add tests for Get/SetTransportAddress.
by Marvin 30 May '17

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

1 0

Re: [3/7] wsdapi/tests: Add WSDCreateUdpAddress tests.
by Marvin 30 May '17

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

1 0

Re: [PATCH 2/7] msvcrt: Clean up registered C++ object in handler.
by Piotr Caban 30 May '17

30 May '17

On 05/24/17 02:55, Daniel Lehman wrote: > +static DWORD cxx_catch_cleanup(EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, > + CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **pdispatcher) > +{ > + if (rec->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND)) > + { > + thread_data_t *data = msvcrt_get_thread_data(); > + frame_info *cur; > + > + if (cxx_is_consolidate(rec)) Is this condition really needed? Shouldn't we clean the object no matter what's the reason of unwind? > + { > + rec = (void*)rec->ExceptionInformation[4]; > + > + for (cur = data->frame_info_head; cur; cur = cur->next) > + { > + if ((ULONG64)cur <= (ULONG64)frame) This condition is not working. It's making assumption about order of catch_frame and frame_info variables on stack while they are declared this way: > + EXCEPTION_REGISTRATION_RECORD catch_frame; > cxx_frame_info frame_info; Shouldn't the cxx_catch_cleanup just unregister the object that was registered in call_catch_block? Thanks, Piotr

1 1

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change
by Ken Thomases 30 May '17

30 May '17

On May 25, 2017, at 1:22 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/winemac.drv/clipboard.c | 34 ++++++++++------------------------ > dlls/winemac.drv/cocoa_clipboard.m | 18 ++++++++++++++++++ > dlls/winemac.drv/macdrv_cocoa.h | 1 + > 3 files changed, 29 insertions(+), 24 deletions(-) > > +int macdrv_has_pasteboard_changed(void) > +{ > + __block int new_change_count; > + int ret; > + > + OnMainThread(^{ > + NSPasteboard* pb = [NSPasteboard generalPasteboard]; > + new_change_count = [pb changeCount]; > + }); > + > + ret = (change_count != new_change_count); > + change_count = new_change_count; > + return ret; > +} Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard. For example, if the owner replaces the data for an existing type, it doesn't change. I'd have to check again, but I think it doesn't even change if the owner adds a new data type. I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:. -Ken

2 5

Re: [PATCH 4/6] d3dx9: Evaluate condition if parameter can be directly copied during initialization.
by Matteo Bruni 29 May '17

29 May '17

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: The patch subject is a bit cumbersome IMO, what about "d3dx9: Add a direct copy path to set_constants()."?

2 2

Re: [PATCH 3/6] d3dx9: Factor out param_type_to_table_type() function.
by Matteo Bruni 29 May '17

29 May '17

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 262b7c1..bddd74f 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -193,7 +193,8 @@ enum pres_value_type > PRES_VT_FLOAT, > PRES_VT_DOUBLE, > PRES_VT_INT, > - PRES_VT_BOOL > + PRES_VT_BOOL, > + PRES_VT_MAX > }; I guess you mean PRES_VT_COUNT. > > static const struct > @@ -260,6 +261,22 @@ struct d3dx_pres_ins > struct d3dx_pres_operand output; > }; > > +static enum pres_value_type param_type_to_table_type(D3DXPARAMETER_TYPE type) In d3d we usually name those the other way around e.g. table_type_from_param_type().

1 0

Re: [PATCH 2/6] d3dx9: Factor out get_constant_dimensions() function.
by Matteo Bruni 29 May '17

29 May '17

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 43 +++++++++++++++++++++++++++---------------- > 1 file changed, 27 insertions(+), 16 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 29a2346..262b7c1 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -979,6 +979,31 @@ void d3dx_free_param_eval(struct d3dx_param_eval *peval) > HeapFree(GetProcessHeap(), 0, peval); > } > > +static void get_constant_dimensions(struct d3dx_const_param_eval_output *const_set, BOOL *transpose, > + unsigned int *major, unsigned int *minor, unsigned int *major_stride, unsigned int *n, > + unsigned int *count) It seems better to pass around a struct pointer in place of all those separate out arguments, e.g. struct const_upload_info. Then you can name the helper get_"structname"() too. > + *n = min(*major * *major_stride, > + get_offset_reg(table, const_set->register_count) + *major_stride - 1) / *major_stride; > + *count = *n * *minor; Preexisting, but "n" is a bit confusing, especially considering that there is a "count" too. Something like "available_major" / "reg_count"? count might be "component_count" or similar. Maybe you can find some better names...

1 0

Re: [PATCH] api-ms-win-security-activedirectoryclient-l1-1-0: Add dll.
by Nikolay Sivov 29 May '17

29 May '17

On 29.05.2017 14:04, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > configure | 2 ++ > configure.ac | 1 + > dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in | 1 + > .../api-ms-win-security-activedirectoryclient-l1-1-0.spec | 8 ++++++++ > tools/make_specfiles | 4 ++++ > 5 files changed, 16 insertions(+) > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > > diff --git a/configure b/configure > index d2d391c..fb22627 100755 > --- a/configure > +++ b/configure > @@ -1026,6 +1026,7 @@ enable_api_ms_win_ntuser_dc_access_l1_1_0 > enable_api_ms_win_power_base_l1_1_0 > enable_api_ms_win_power_setting_l1_1_0 > enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +enable_api_ms_win_security_activedirectoryclient_l1_1_0 > enable_api_ms_win_security_audit_l1_1_1 > enable_api_ms_win_security_base_l1_1_0 > enable_api_ms_win_security_base_l1_2_0 > @@ -17897,6 +17898,7 @@ wine_fn_config_dll api-ms-win-ntuser-dc-access-l1-1-0 enable_api_ms_win_ntuser_d > wine_fn_config_dll api-ms-win-power-base-l1-1-0 enable_api_ms_win_power_base_l1_1_0 > wine_fn_config_dll api-ms-win-power-setting-l1-1-0 enable_api_ms_win_power_setting_l1_1_0 > wine_fn_config_dll api-ms-win-rtcore-ntuser-private-l1-1-0 enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +wine_fn_config_dll api-ms-win-security-activedirectoryclient-l1-1-0 enable_api_ms_win_security_activedirectoryclient_l1_1_0 > wine_fn_config_dll api-ms-win-security-audit-l1-1-1 enable_api_ms_win_security_audit_l1_1_1 > wine_fn_config_dll api-ms-win-security-base-l1-1-0 enable_api_ms_win_security_base_l1_1_0 > wine_fn_config_dll api-ms-win-security-base-l1-2-0 enable_api_ms_win_security_base_l1_2_0 > diff --git a/configure.ac b/configure.ac > index db4d168..dde867b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2843,6 +2843,7 @@ WINE_CONFIG_DLL(api-ms-win-ntuser-dc-access-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-setting-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-rtcore-ntuser-private-l1-1-0) > +WINE_CONFIG_DLL(api-ms-win-security-activedirectoryclient-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-audit-l1-1-1) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-2-0) > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > new file mode 100644 > index 0000000..e1e99bd > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > @@ -0,0 +1 @@ > +MODULE = api-ms-win-security-activedirectoryclient-l1-1-0.dll > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > new file mode 100644 > index 0000000..eef1c40 > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > @@ -0,0 +1,8 @@ > +@ stub DsBindWithSpnExW > +@ stub DsCrackNamesW > +@ stub DsFreeDomainControllerInfoW > +@ stub DsFreeNameResultW > +@ stub DsFreePasswordCredentials > +@ stub DsGetDomainControllerInfoW > +@ stub DsMakePasswordCredentialsW > +@ stub DsUnBindW > diff --git a/tools/make_specfiles b/tools/make_specfiles > index e544293..910bd0f 100755 > --- a/tools/make_specfiles > +++ b/tools/make_specfiles > @@ -157,6 +157,10 @@ my @dll_groups = > "api-ms-win-power-setting-l1-1-0", > ], > [ > + "ntdsapi", > + "api-ms-win-security-activedirectoryclient-l1-1-0", > + ], > + [ > "kernel32", > "api-ms-win-appmodel-identity-l1-1-0", > "api-ms-win-appmodel-runtime-l1-1-1", > Those exports are present in kernelbase spec file, maybe it's better to forward to it?

1 0

Re: [PATCH 4/6] wined3d: Prefer GLSL 1.50 shaders in draw_test_quad().
by Henri Verbeet 29 May '17

29 May '17

On 29 May 2017 at 10:53, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + BOOL use_glsl_150 = gl_info->glsl_version >= 150; That doesn't work in Wine :D I wouldn't necessarily mind if it did though.

1 0

Re: [PATCH] comctl32/listview: Do not select the first list item when drawing a marquee rectangle
by Nikolay Sivov 29 May '17

29 May '17

On 22.05.2017 16:02, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/listview.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index c681451..a117f83 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -3892,6 +3892,9 @@ static void LISTVIEW_MarqueeHighlight(LISTVIEW_INFO *infoPtr, const POINT *coord > if ((scroll & SCROLL_DOWN) && (coords_orig->y >= infoPtr->rcList.bottom)) > LISTVIEW_Scroll(infoPtr, 0, (coords_orig->y - infoPtr->rcList.bottom)); > > + if (IsRectEmpty(&infoPtr->marqueeRect)) > + infoPtr->marqueeRect = rect; > + > iterator_frameditems_absolute(&old_elems, infoPtr, &infoPtr->marqueeRect); > > infoPtr->marqueeRect = rect; > I see what you mean, when you start selecting with marquee first item in report mode is always selected. This patch fixes that, but breaks ICON mode it seems - sometimes items are not selected when they are clearly intersect with marquee rectangle. Admittedly this selection mode is already funny in ICON mode, it does not use dead zones properly, so slight movement selects things, while it should check with icon rectangle when resized horizontally, and allow about half icon rectangle intersect marquee vertically before setting item state.

2 3

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.
by Stefan Dösinger 29 May '17

29 May '17

Am 2017-05-24 um 15:49 schrieb Masanori Kakura: > + for (j = 0; j < layer_count; ++j) > + { > + wined3d_cs_emit_blt_sub_resource(cs, > + &dst_texture->resource, j * dst_level_count + i, &box, > + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, > + 0, NULL, WINED3D_TEXF_POINT); > + } I don't like emitting new operations in the CS handler instead of doing the actual operation. Maybe this can be avoided with some refactoring of wined3d_cs_exec_blt_sub_resource?

3 3

Re: [v6 PATCH 2/3] wined3d: Add dirty region tracking.
by Marvin 28 May '17

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

1 0

about donat enikeev csmt on graphics tab in winecfg
by CARLOS RODRIGUEZ 27 May '17

27 May '17

Hi henri I read your discussion about normal user dont need touch that However various titles needs csmt, mainly for solve graphics issues case duke nuke forever (dont show anything without csmt), resident evil 6 (only see light without csmt) Or flickering graphics case im alive, senran kagura shinovi versus, bayonetta, vanquish Resolve audio sincronization in prerenderer sequences case front mission evolved And possible many other titles Put option in winecfg could be usefull for new users I agree about you said related csmt dont be stay active for default for now, but solve before problems described Maybe can add some note in csmt like that: mainly for resolve graphics issues for now or something similar Thanks

1 0

Re: [PATCH] msvcp140: Implement _To_wide (v2).
by Stefan Dösinger 26 May '17

26 May '17

Am 2017-05-26 um 13:17 schrieb Stefan Dösinger: > + return MultiByteToWideChar(CP_ACP, 0, src, -1, dst, strlen(src) + 1); Do not commit this yet, there is another version coming. The maximum length is limited to MAX_PATH, and Nikolai says the test randomly crashes on his Windows. It seems Microsoft lets interns write APIs nowadays.

1 0

Re: [PATCH] msvcp140: Implement _To_wide.
by Marvin 26 May '17

26 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=31204 Your paranoid android. === wvistau64 (32 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f" === wvistau64 (64 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f"

1 0

Re: [PATCH] oleaut32: Add VarBstrFromDisp tests
by Marvin 25 May '17

25 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=31191 Your paranoid android. === wxppro (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2003std (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2008s64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7u (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7pro64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w8 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w864 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w1064 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w2008s64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w7pro64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w1064 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\5540\5653\4157\4154\4155\4156\4857\6c8d\e124\8148\d8ec" oleaut32:vartype crashed (c0000374)

1 0

Re: [7/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture3d.
by Józef Kucia 25 May '17

25 May '17

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_R8G8B8A8_UNORM, D3D11_BIND_DEPTH_STENCIL, FALSE, FALSE}, > {DXGI_FORMAT_D24_UNORM_S8_UINT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_SHADER_RESOURCE, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_DEPTH_STENCIL, FALSE, FALSE}, Please use D3D11 enum values.

1 0

Re: [6/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture2d.
by Józef Kucia 25 May '17

25 May '17

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_DEPTH_STENCIL, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_SHADER_RESOURCE, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_DEPTH_STENCIL, 0, FALSE, FALSE}, > }; Please use D3D11 enum values.

1 0

Re: [5/8] d3d10core/tests: Add R9G9B9E5_SHAREDEXP to test_texture.
by Józef Kucia 25 May '17

25 May '17

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > + static const DWORD r9g9b9e5_colors[16] = { Please try to put opening brackets on a new line (applies also to the d3d11 version).

1 0

Re: [PATCH 1/5] d3dx9/tests: Use ARRAY_SIZE in test_D3DXSHEvalDirectionalLight().
by Matteo Bruni 24 May '17

24 May '17

2017-05-23 11:04 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > @@ -2908,7 +2908,7 @@ static void test_D3DXSHEvalDirectionalLight(void) > green_out = test[l].green_in; > blue_out = test[l].blue_in; > > - for (j = 0; j < 49; j++) > + for (j = 0; j < ARRAY_SIZE(red_out); ++j) red_out here is defined as a pointer, not an array.

1 0

Re: [v5 PATCH 3/3] wined3d: Update only dirty regions in wined3d_cs_exec_update_texture().
by Marvin 24 May '17

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

1 0

Re: [PATCH] iphlpapi: Implement if_nametoindex.
by Bruno Jesus 24 May '17

24 May '17

On Wed, May 24, 2017 at 7:39 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > ... > diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c > index 796950e0f9..4cceb65621 100644 > --- a/dlls/iphlpapi/iphlpapi_main.c > +++ b/dlls/iphlpapi/iphlpapi_main.c > @@ -36,6 +36,9 @@ > #ifdef HAVE_RESOLV_H > # include <resolv.h> > #endif > +#ifdef HAVE_NET_IF_H > +# include <net/if.h> > +#endif > > #define NONAMELESSUNION > #define NONAMELESSSTRUCT > @@ -3208,3 +3211,12 @@ DWORD WINAPI ConvertInterfaceNameToLuidW(const WCHAR *name, NET_LUID *luid) > luid->Info.IfType = row.dwType; > return NO_ERROR; > } > + > +/****************************************************************** > + * if_nametoindex (IPHLPAPI.@) > + */ > +IF_INDEX WINAPI IPHLP_if_nametoindex(const char *name) > +{ > + TRACE("(%s)\n", name); > + return if_nametoindex(name); > +} Hi, this seems to be the ASCII version of GetAdapterIndex, can't you call getInterfaceIndexByName and avoid the new #include? Best wishes, Bruno

3 8

Re: [PATCH 2/2] winex11.drv: Implement clipboard changes tracking using xfixes extension
by Alexandre Julliard 24 May '17

24 May '17

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -499,6 +499,7 @@ extern Atom systray_atom DECLSPEC_HIDDEN; > typedef BOOL (*x11drv_event_handler)( HWND hwnd, XEvent *event ); > > extern void X11DRV_register_event_handler( int type, x11drv_event_handler handler, const char *name ) DECLSPEC_HIDDEN; > +extern void X11DRV_register_XFixesSelectionNotify( int type ) DECLSPEC_HIDDEN; Is there a reason you can't use X11DRV_register_event_handler? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/2] regedit: Add 'Expand' and 'Collapse' options to the treeview pop-up menu
by Nikolay Sivov 24 May '17

24 May '17

On 24.05.2017 11:21, Hugh McMaster wrote: > + item.mask = TVIF_CHILDREN | TVIF_HANDLE | TVIF_STATE; > + item.stateMask = TVIS_EXPANDED | TVIS_EXPANDEDONCE | TVIS_EXPANDPARTIAL; > + SendMessageW(hwndTV, TVM_GETITEMW, 0, (LPARAM)&item) Later you only test for TVIS_EXPANDED, is it necessary to request other bits?

2 1

Re: [PATCH 2/2] regedit: Add 'Expand' and 'Collapse' options to the treeview pop-up menu
by Nikolay Sivov 24 May '17

24 May '17

On 24.05.2017 11:21, Hugh McMaster wrote: > + case ID_TREE_EXPAND: > + { > + HTREEITEM selected = (HTREEITEM)SendMessageW(g_pChildWnd->hTreeWnd, TVM_GETNEXTITEM, TVGN_CARET, 0); > + SendMessageW(g_pChildWnd->hTreeWnd, TVM_EXPAND, TVE_TOGGLE, (LPARAM)selected); > + break; > + } Maybe it's better to name it ID_TREE_EXPAND_COLLAPSE, since it does not only expand.

2 1

Re: [PATCH] authz: document missorted function in specfile
by Alexandre Julliard 24 May '17

24 May '17

Austin English <austinenglish(a)gmail.com> writes: > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/authz/authz.spec | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/authz/authz.spec b/dlls/authz/authz.spec > index eb9e044d2a..1e9edefc59 100644 > --- a/dlls/authz/authz.spec > +++ b/dlls/authz/authz.spec > @@ -35,6 +35,8 @@ > @ stub AuthziInitializeAuditQueue > @ stub AuthziInitializeContextFromSid > @ stub AuthziLogAuditEvent > +# AuthziModifyAuditEvent2 comes before AuthziModifyAuditEvent on native, > +# even though AuthzInitializeObjectAccessAuditEvent is before AuthzInitializeObjectAccessAuditEvent2 > @ stub AuthziModifyAuditEvent2 > @ stub AuthziModifyAuditEvent > @ stub AuthziModifyAuditEventType There are many functions that aren't sorted, I don't think this warrants a comment. If you have a script for this, you may want to maintain a list of exceptions inside the script instead. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH] comctl32/listview: Do not select the first list item when drawing a marquee rectangle
by Nikolay Sivov 23 May '17

23 May '17

On 22.05.2017 16:02, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/listview.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index c681451..a117f83 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -3892,6 +3892,9 @@ static void LISTVIEW_MarqueeHighlight(LISTVIEW_INFO *infoPtr, const POINT *coord > if ((scroll & SCROLL_DOWN) && (coords_orig->y >= infoPtr->rcList.bottom)) > LISTVIEW_Scroll(infoPtr, 0, (coords_orig->y - infoPtr->rcList.bottom)); > > + if (IsRectEmpty(&infoPtr->marqueeRect)) > + infoPtr->marqueeRect = rect; > + > iterator_frameditems_absolute(&old_elems, infoPtr, &infoPtr->marqueeRect); > > infoPtr->marqueeRect = rect; > How can I reproduce this issue?

1 0

Re: [PATCH 2/2] d3d11/tests: Add additional test for occlusion query.
by Henri Verbeet 22 May '17

22 May '17

On 20 May 2017 at 14:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + for (i = 0; i < 500; ++i) > + { > + if ((hr = ID3D11DeviceContext_GetData(context, query, NULL, 0, 0)) != S_FALSE) > + break; > + Sleep(10); > + } > + ok(hr == S_OK, "Got unexpected hr %#x.\n", hr); > + hr = ID3D11DeviceContext_GetData(context, query, &data, sizeof(data), 0); > + ok(hr == S_OK, "Got unexpected hr %#x.\n", hr); > + todo_wine ok(data.dword[0] == 0x1000 && !data.dword[1], > + "Got unexpected query result 0x%08x%08x.\n", data.dword[1], data.dword[0]); This fails about half of the time with csmt enabled: d3d11.c:4872: Test succeeded inside todo block: Got unexpected query result 0x0000000000001000.

2 2

Re: [PATCH 5/5] d2d1: Implement initial support for quadratic bezier outlines.
by Dmitry Timoshkov 22 May '17

22 May '17

Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > +static void d2d_point_lerp(D2D1_POINT_2F *out, > + const D2D1_POINT_2F *a, const D2D1_POINT_2F *b, float t) > +{ > + out->x = a->x * (1.0f - t) + b->x * t; > + out->y = a->y * (1.0f - t) + b->y * t; > +} According to my investigation of a better bilinear blending (lerp) implementation the above formula is better to explicitely simplify to out->x = a->x + (b->x - a->x) * t; out->y = a->y + (b->y - a->y) * t; or even better to avoid floating point operations at all by replacing them either by fixed point math or a mmx/sse helper, which is able to considerably (x10) improve performance. -- Dmitry.

3 9

What is the best way to debug a freeze in wine?
by Derek Lesho 22 May '17

22 May '17

This is my first time posting in a mailing list, so if this is the wrong place to ask or I am doing something wrong, please tell me. Anyway, In wine 2.8, GTA-V is able to be run, however there is a major bug in which any key press will freeze the game for a few seconds. However, if you bind any actions to the mouse, say mouse4 or mouse5, the issue is not present. GTA-V has also worked for people using xbox 360 controllers. I have moderate programming knowledge, and I would like to find the source of this bug, however I have no found a good way to do it yet. I have tried winedbg, however when I get a backtrace of the process, there are atleast 50 threads running and I am unsure which one is locking up the game. I would use perf, however so far I haven't figured out how to make it tell me which functions are taking up most of the time. My question is, do any of you know of good tools/techniques that would help me debug this sort of problem? It would be greatly appreciated. P.S. for any of you who are also interested in this specific problem, many error messages are sent out at a very fast speed, but when the game is frozen due to this bug, all error messages temporarily halt with the exception of these two: fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 40000000: semi-stub! fixme:keyboard:X11DRV_ActivateKeyboardLayout flags 40000000 not supported Which are output a slow interval instead until the game unfreezes at which point the console output returns back to its normal sporadic behavior. Also, here is a normal backtrace from winedbg while the issue is occuring: http://paste.ubuntu.com/24539530/

2 1

Re: [PATCH 7/7] d3dx9/tests: Use static test blob in test_effect_preshader_ops().
by Matteo Bruni 22 May '17

22 May '17

2017-05-19 13:56 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: Thanks, I do think this is an improvement compared to the old tests. A few comments below. > static const struct > { > - unsigned int pos; > + const char *mnem; > + unsigned int expected_result[4]; > unsigned int result_index; > - unsigned int ins_count; > + float *result; > + D3DXVECTOR4 opvect1, opvect2, opvect3; > + unsigned int ulps; > + BOOL todo[4]; > } I assume ulps and todo are there for future tests? > + for (j = 0; j < 4; ++j) > + { > + const float *v = op_tests[i].result; Can you put the initialization of 'v' outside of the inner loop? I'm sure the compiler sees the optimization and the generated code is ultimately the same (not that it would really matter for a test anyway...) but it seems a bit nicer to do that in the "correct" block. You could also call it "result" or similar. > + todo_wine_if(op_tests[i].todo[j]) > + ok(compare_float(v[j], ((float *)op_tests[i].expected_result)[j], op_tests[i].ulps), > + "Operation %s, component %u, expected %#x (%g), got %#x (%g).\n", op_tests[i].mnem, > + j, op_tests[i].expected_result[j], ((float *)op_tests[i].expected_result)[j], > + ((unsigned int *)v)[j], v[j]); Just an idea, maybe use %.8e to print the float values? Mostly for consistency with the usual d3d stuff, although in this case it doesn't matter much since you're also printing the bit encoding in hex. Also you can clean the ok() a bit by defining a "const float *expected_float;" variable (similarly to test_effect_preshader_relative_addressing()). BTW, notice that you're currently casting away const from v.

2 2

Re: [v2 2/2] d3d11/tests: Add tests for SM5 instructions gather4_c/gather4_po_c
by Henri Verbeet 22 May '17

22 May '17

On 19 May 2017 at 14:31, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > Signed-off-by: Sven Hesse <drmccoy(a)drmccoy.de> > --- > dlls/d3d11/tests/d3d11.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 230 insertions(+) > This fails here: d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}.

2 2

Re: [PATCH 1/2] kernel32/tests: Added more PeedNamedPipe tests.
by Marvin 22 May '17

22 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=31084 Your paranoid android. === w7u (32 bit pipe) === pipe.c:2631: Test failed: FlushFileBuffers failed: 0

1 0

D3D command stream patches for testing
by A.S. 21 May '17

21 May '17

Hello, I have low frame rate (~16-18) problem in Unreal Tournament 3, wine 2.8. "stat fps", "stat ld" commands were enabled in game console and showed relation that fps drop after 'static mesh tris' goes higher than >200 000 So I applied patchset from https://www.winehq.org/pipermail/wine-devel/2013-September/101116.html to wine 1.7 with CXXFLAGS -o3 -m native, and tested it. Yes, finnaly my fps imroves to ~30 on same maps where it was lower before. Thank you Stefan. same issue was reported by many unreal engine 3 players on windows, so AFAIK this could be ue3 problem itself. the patchset could be step in right direction, or workaround, but not a total fix, cuz even minimal ~30 frame rate is lower than expected on Core2Duo, gf GTS450, when other games works better. Thanks, Lex.

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