March 2017 - Wine-Devel - list.winehq.org

Re: [PATCH] ole32: Add CoRegisterSurrogate/Ex stubs
by Huw Davies March 27, 2017

March 27, 2017

On Mon, Mar 27, 2017 at 04:29:24AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > diff --git a/include/objbase.h b/include/objbase.h > index 875f0e1..8f89389 100644 > --- a/include/objbase.h > +++ b/include/objbase.h > @@ -331,6 +331,7 @@ HRESULT WINAPI CoRevokeClassObject(DWORD dwRegister); > HRESULT WINAPI CoGetPSClsid(REFIID riid,CLSID *pclsid); > HRESULT WINAPI CoRegisterPSClsid(REFIID riid, REFCLSID rclsid); > HRESULT WINAPI CoRegisterSurrogate(LPSURROGATE pSurrogate); > +HRESULT WINAPI CoRegisterSurrogateEx(REFGUID guid, void *reserved); I don't see this in my Windows 10 SDK. Where does it come from? Huw.

2 2

Re: [v2 PATCH] oledb32/tests: Add convert to DBTYPE_NUMERIC tests
by Huw Davies March 27, 2017

March 27, 2017

On Sun, Mar 26, 2017 at 10:14:00PM +0000, Alistair Leslie-Hughes wrote: > v2 > - Added VT_NULL test > - Use result variables for each test. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> convert.c:3349: Test succeeded inside todo block: got 00000000 convert.c:3350: Test succeeded inside todo block: got 00000003 I've fixed these, removed the unnecessary src array, and resent. Huw.

1 0

Re: [PATCH v3 3/6] user32: Always send WM_CANCELMODE when disabling a window.
by Marvin March 26, 2017

March 26, 2017

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=29708 Your paranoid android. === w7u (32 bit msg) === msg.c:12062: Test failed: WmMouseHoverSeq: 0: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:12064: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:12064: Test failed: wrong tme.hwndTrack 0012017C, expected 00000000 msg.c:12064: Test failed: wrong tme.dwHoverTime 400, expected 0

1 0

Re: [PATCH 4/7] wined3d: Save pixel and vertex shader resource views in stateblocks.
by Henri Verbeet March 26, 2017

March 26, 2017

On 24 March 2017 at 17:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3132,6 +3132,8 @@ struct wined3d_saved_states > WORD vertexShaderConstantsB; /* WINED3D_MAX_CONSTS_B, 16 */ > WORD vertexShaderConstantsI; /* WINED3D_MAX_CONSTS_I, 16 */ > BOOL vs_consts_f[WINED3D_MAX_VS_CONSTS_F]; > + DWORD pixel_shader_resource_views : 16; /* MAX_FRAGMENT_SAMPLERS, 16 */ > + DWORD vertex_shader_resource_views : 16; /* MAX_VERTEX_SAMPLERS, 4 */ So why is it 16 bits wide?

2 1

Re: [PATCH 2/7] wined3d: Allow creating shader resource views with NULL description.
by Henri Verbeet March 26, 2017

March 26, 2017

On 24 March 2017 at 17:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > For ddraw, d3d8 and d3d9. > I think we'd rather just create a wined3d_view_desc in those DLLs.

1 0

Re: cmd: Adjust CMD_LIST to a tree-like structure and implement command chains
by Flávio J. Saraiva March 26, 2017

March 26, 2017

Hi, Some time ago I was told that every patch in a patch set all patches should produce a state that passes all the tests. Given how much the current code is interconnected, i don't think i can split this while keeping the tests functional. How should I proceed in this case, can I split the code into logical bits knowing that the intermediate states will not pass the tests? Flávio J. Saraiva 2017-03-21 21:06 GMT+00:00 Marvin <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Needs splitting". > > This means that the patch needs to be split, either because it > contains unrelated changes that should be their own separate patch, or > because it's too large for review. You need to find a way to resend > the changes in smaller chunks. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email.

5 8

Re: [PATCH v2 1/5] user32: Fix handling of internal messages.
by Alexandre Julliard March 25, 2017

March 25, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > This patch adds a new flag and a server reply, allowing GetQueueStatus > to ignore internal messages, and MsgWaitForMultipleObjects to process > internal messages until a real sent message is found. There's a lot of code duplication in there, and adding private flags to public headers is discouraged. There has to be a better way of doing this, or else it would need a stronger justification than a couple of EnableWindow tests. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] oleaut32: Implement GetAltMonthNames()
by Jacek Caban March 25, 2017

March 25, 2017

Hi Nikolay, On 3/24/17 7:32 PM, Nikolay Sivov wrote: > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index f9734e6d78..816b18ce35 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -935,3 +935,109 @@ HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) > /* FIXME: make an extended conversation from HICON to HCURSOR */ > return CopyCursor(hIcon); > } > + > +BOOL WINAPI GetAltMonthNames(LCID lcid, LPOLESTR **str) Shouldn't it return HRESULT? Thanks, Jacek

2 1

Re: [PATCH 2/3] d3dx9: Support relative addressing in preshader.
by Matteo Bruni March 24, 2017

March 24, 2017

2017-03-23 16:06 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 103 ++++++++++++++++++++++++++++++++++++------- > dlls/d3dx9_36/tests/effect.c | 38 ++++++++-------- > 2 files changed, 106 insertions(+), 35 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 9aedc99..2974ffd 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -191,6 +191,8 @@ struct d3dx_pres_operand > /* offset is component index, not register index, e. g. > offset for component c3.y is 13 (3 * 4 + 1) */ > unsigned int offset; > + enum pres_reg_tables base_reg_table; > + unsigned int base_reg_offset; > }; It would be nicer to create a struct for storing together table and offset and to pass it around to the various functions taking both arguments, like parse_pres_reg(). It should probably be a separate patch before this one. > + ptr = parse_pres_reg(ptr + 1, &opr->base_reg_table, &opr->base_reg_offset); > + } > + else > + { > + opr->base_reg_table = PRES_REGTAB_COUNT; > + ++ptr; > } > - opr->table = reg_table[*ptr++]; > - opr->offset = *ptr++; > + > + ptr = parse_pres_reg(ptr, &opr->table, &opr->offset); This would crash if the previous parse_pres_reg() call returned NULL. > + size = rs->table_sizes[table] * table_info[table].reg_component_count; > + if (offset >= size) > + { > + if ((offset & 255) < size) > + offset &= 255; > + else > + offset = offset % size; > + } Is this just to try and avoid the modulo operation in some cases or is there a deeper reason? If the former, you could extend that to all the power-of-two sizes by first checking if that's the case (!(size & size - 1)) and, if so, and-ing offset with the mask (size - 1). That's assuming the compiler doesn't do the same optimization already. Let me know if there is some other reason instead. > static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) > { > - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) > - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); > + unsigned int base_offset, index; > + > + if (opr->base_reg_table == PRES_REGTAB_COUNT) > + index = 0; > + else > + index = (int)exec_get_reg_value(rs, opr->base_reg_table, opr->base_reg_offset); I think it's better with lrint() in place of the cast. > + if (index >= rs->table_sizes[opr->table] && opr->table == PRES_REGTAB_CONST) > + { > + unsigned int size_pow2; > + > + for (size_pow2 = 1; size_pow2 < rs->table_sizes[opr->table]; size_pow2 <<= 1) > + ; > + index &= (size_pow2 - 1); > + if (index >= rs->table_sizes[opr->table]) > + return 0.0; > + } I don't think we necessarily have to follow native's madness on buffer overflows to the letter. Since you did, that's certainly fine though.

2 6

Re: [PATCH v2] winex11: Use GLX_OML_sync_control to synchronise buffer swaps with X11DRV_FLUSH_GL_DRAWABLE requests.
by Jacek Caban March 24, 2017

March 24, 2017

Hi Henri, On 23.03.2017 23:58, Henri Verbeet wrote: > diff --git a/dlls/winex11.drv/init.c b/dlls/winex11.drv/init.c > index af2fd92..7efd603 100644 > --- a/dlls/winex11.drv/init.c > +++ b/dlls/winex11.drv/init.c > @@ -375,9 +375,6 @@ static INT X11DRV_ExtEscape( PHYSDEV dev, INT escape, INT in_count, LPCVOID in_d > RECT rect = physDev->dc_rect; > > OffsetRect( &rect, -physDev->dc_rect.left, -physDev->dc_rect.top ); > - /* The GL drawable may be lagged behind if we don't flush first, so > - * flush the display make sure we copy up-to-date data */ > - XFlush( gdi_display ); Shouldn't this be called if GLX_OML_sync_control is not available? It seems to me that it should either depend on extension availability or be a separated patch. Thanks, Jacek

2 1