- wine-devel - winehq.org

Re: [PATCH] wincodecs: Trigger conversion to target format in WriteSource()
by Dmitry Timoshkov 23 Nov '16

23 Nov '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - if (!IsEqualGUID(&src_format, format)) > - { > - /* FIXME: should use WICConvertBitmapSource to convert */ > - ERR("format %s unsupported\n", debugstr_guid(&src_format)); > - return E_FAIL; > + hr = IWICBitmapFrameEncode_SetPixelFormat(iface, &src_format); > + if (FAILED(hr)) return hr; > } Despite the removing a questionable FIXME this part of the code won't do what you think it does. Besides, since there is no a single todo_wine removed with this patch adding a bunch of tests for different encoders is needed to show that the automatic conversion is really supposed to happen, and that it doesn't depend on the implementation detail in some of the encoders. According to my testing not every encoder does this kind of thing, especially when a conversion needs a palette. -- Dmitry.

2 2

Re: [PATCH] wincodecs: Recognize FilterOption property in PNG encoder
by Vincent Povirk 23 Nov '16

23 Nov '16

We should either set this option when encoding, or print a fixme. I think setting it is easy enough.

1 0

Re: [PATCH] quartz: Use straight assignments instead of CopyRect().
by Michael Stefaniuc 23 Nov '16

23 Nov '16

On 11/22/2016 08:01 PM, Hadrien Boizard wrote: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > dlls/quartz/videorenderer.c | 8 ++++---- > dlls/quartz/vmr9.c | 8 ++++---- > 2 files changed, 8 insertions(+), 8 deletions(-) > > > 0001-quartz-Use-straight-assignments-instead-of-CopyRect.patch > > > diff --git a/dlls/quartz/videorenderer.c b/dlls/quartz/videorenderer.c > index 61f08f5..6631ccd 100644 > --- a/dlls/quartz/videorenderer.c > +++ b/dlls/quartz/videorenderer.c > @@ -483,7 +483,7 @@ static const BaseWindowFuncTable renderer_BaseWindowFuncTable = { > static HRESULT WINAPI VideoRenderer_GetSourceRect(BaseControlVideo* iface, RECT *pSourceRect) > { > VideoRendererImpl *This = impl_from_BaseControlVideo(iface); > - CopyRect(pSourceRect,&This->SourceRect); > + *pSourceRect = This->SourceRect; NACK, this is not a no-op change. CopyRect() also checks for NULL rect pointers so it protects against NULL pSourceRect. With your change apps would crash if they do that. The proper fix is to add tests for NULL rects and return the proper error in those functions. Or at least add code like: if (!pSourceRect) return E_POINTER; No clue if Andrew Eikum is willing to accept that without tests. E_INVALIDARG would be also a plausible error code. bye michael

1 0

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.
by Dmitry Timoshkov 23 Nov '16

23 Nov '16

Huw Davies <huw(a)codeweavers.com> wrote: > + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); > + if (IsWindowUnicode(hwnd)) > + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); > + else > + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always return a unicode string regardless of wheather IsWindowUnicode() is broken or not, otherwise a lot of applications would misbehave in weird ways. This needs further investigation. -- Dmitry.

2 7

Re: [PATCH 09/10] kernel32/tests: Added more named pipe tests.
by Marvin 23 Nov '16

23 Nov '16

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=26858 Your paranoid android. === w864 (64 bit pipe) === pipe.c:2575: Test failed: FlushFileBuffers failed: 87 pipe.c:2575: Test failed: FlushFileBuffers failed: 87

1 0

Re: [PATCH] msvcrt: Add _lfind_s
by Piotr Caban 23 Nov '16

23 Nov '16

Hi, On 11/22/16 16:36, Daniel Lehman wrote: > dlls/msvcrt/misc.c | 26 +++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/tests/misc.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++ Please also update other spec files. > + /* simple samples */ > + /* simple sample - not found */ Could you please also remove these comments? They are not very useful. Thank you, Piotr

1 0

Re: [08/23] wined3d: Allow viewport to be out-of-bounds if using offscreen target.
by Andrew Wesie 23 Nov '16

23 Nov '16

Assuming that viewport_test in d3d9/tests/visual.c is wrong only when render_offscreen is true, is there anyway to fix that test? Or should viewport_test be removed? The reason for the patch is that Overwatch renders to a 2D texture some UI elements. If the viewport is not what is expected, then the output is wrong (e.g. the UI elements are the wrong size or drawn at the wrong place on the texture). -Andrew On Sun, Nov 13, 2016 at 12:35 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/state.c | 42 ++++++++++++++++++++++-------------------- > 1 file changed, 22 insertions(+), 20 deletions(-) > > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index cd3763c..ed20e325 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -4617,26 +4617,6 @@ static void viewport_miscpart(struct > wined3d_context *context, const struct wine > struct wined3d_viewport vp = state->viewport; > unsigned int width, height; > > - if (target) > - { > - if (vp.width > target->width) > - vp.width = target->width; > - if (vp.height > target->height) > - vp.height = target->height; > - > - wined3d_rendertarget_view_get_drawable_size(target, context, > &width, &height); > - } > - else if (depth_stencil) > - { > - width = depth_stencil->width; > - height = depth_stencil->height; > - } > - else > - { > - FIXME("No attachments draw calls not supported.\n"); > - return; > - } > - > gl_info->gl_ops.gl.p_glDepthRange(vp.min_z, vp.max_z); > checkGLcall("glDepthRange"); > /* Note: GL requires lower left, DirectX supplies upper left. This is > @@ -4644,7 +4624,29 @@ static void viewport_miscpart(struct > wined3d_context *context, const struct wine > if (context->render_offscreen) > gl_info->gl_ops.gl.p_glViewport(vp.x, vp.y, vp.width, vp.height); > else > + { > + if (target) > + { > + if (vp.width > target->width) > + vp.width = target->width; > + if (vp.height > target->height) > + vp.height = target->height; > + > + wined3d_rendertarget_view_get_drawable_size(target, context, > &width, &height); > + } > + else if (depth_stencil) > + { > + width = depth_stencil->width; > + height = depth_stencil->height; > + } > + else > + { > + FIXME("No attachments draw calls not supported.\n"); > + return; > + } > + > gl_info->gl_ops.gl.p_glViewport(vp.x, (height - (vp.y + > vp.height)), vp.width, vp.height); > + } > checkGLcall("glViewport"); > } > > -- > 2.7.4 > >

2 3

Re: [v2 1/3] wined3d: Implement return instruction.
by Józef Kucia 23 Nov '16

23 Nov '16

On Fri, Nov 18, 2016 at 6:46 AM, Andrew Wesie <awesie(a)gmail.com> wrote: > --- a/dlls/wined3d/shader.c > +++ b/dlls/wined3d/shader.c > @@ -2028,6 +2028,7 @@ void shader_generate_main(const struct wined3d_shader *shader, struct wined3d_st > struct wined3d_shader_tex_mx tex_mx; > struct wined3d_shader_context ctx; > const DWORD *ptr = byte_code; > + enum WINED3D_SHADER_INSTRUCTION_HANDLER last_opcode = WINED3DSIH_TABLE_SIZE; > > /* Initialize current parsing state. */ > tex_mx.current_row = 0; > @@ -2062,6 +2063,16 @@ void shader_generate_main(const struct wined3d_shader *shader, struct wined3d_st > > /* Call appropriate function for output target */ > device->shader_backend->shader_handle_instruction(&ins); > + last_opcode = ins.handler_idx; > + } > + > + if (last_opcode != WINED3DSIH_RET) > + { > + /* Force a return instruction at the end of function body. */ > + memset(&ins, 0, sizeof(ins)); > + ins.ctx = &ctx; > + ins.handler_idx = WINED3DSIH_RET; > + device->shader_backend->shader_handle_instruction(&ins); > } > } Would it make sense to always generate a shader epilogue for shader model <= 3, and handle the RET instruction in a special way for shader model >= 4?

2 3

Re: [PATCH 6/6] d3d9/tests: Add test for occlusion query with result bigger than UINT32_MAX.
by Alexandre Julliard 22 Nov '16

22 Nov '16

Józef Kucia <jkucia(a)codeweavers.com> writes: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d9/tests/device.c | 87 +++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 78 insertions(+), 9 deletions(-) This one fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2291: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:5666: Test failed: Failed to create render target, hr 0x8876017c. device.c:5670: Test failed: Failed to set render target, hr 0x8876086c. device.c:5705: Test failed: Got unexpected query result 0x0000000003f7a000. wine: Unhandled page fault on read access to 0x00000000 at address 0x7ecb5a48 (thread 00bd), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7ecb5a48). fixme:dbghelp_dwarf:dwarf2_parse_const_type Unsupported children Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ecb5a48 ESP:0032f484 EBP:0032f658 EFLAGS:00210212( R- -- I -A- - ) EAX:00000000 EBX:7ed3f000 ECX:0032f480 EDX:00000000 ESI:00000001 EDI:7ed15e7c Stack dump: 0x0032f484: 7ed198a4 00000000 03f7a000 04000000 0x0032f494: 7ed198a4 7ed12a3f 7ed13f78 00000001 0x0032f4a4: 001434b8 01390060 00000042 7ed15e7c 0x0032f4b4: 00000001 7ed1e200 7ed12a26 0032f4e0 0x0032f4c4: 00000000 03f7a000 00161970 00000000 0x0032f4d4: 00000000 0013ea60 0013aa30 03f7a000 Backtrace: =>0 0x7ecb5a48 test_occlusion_query+0xe58() [/home/julliard/wine/wine/dlls/d3d9/tests/device.c:5713] in d3d9_test (0x0032f658) 1 0x7ecbe103 func_device+0x4772() [/home/julliard/wine/wine/dlls/d3d9/tests/device.c:11382] in d3d9_test (0x0032fd68) 2 0x7ec85d9a main+0x379(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/d3d9/tests/../../../include/wine/test.h:589] in d3d9_test (0x0032fe18) 3 0x7ed124db __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in d3d9_test (0x0032fe58) 4 0x7b45e3cc call_process_entry+0xb() in kernel32 (0x0032fe78) 5 0x7b45f34a start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1108] in kernel32 (0x0032fea8) 6 0x7bc7fb8c call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 7 0x7bc8295f call_thread_func+0xde(entry=0x7b45f2f0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0032ffa8) 8 0x7bc7fb6a call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 9 0x7bc53587 start_process+0x16(kernel_start=0x7b45f2f0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3047] in ntdll (0x0032ffe8) 10 0xf755e8cd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 11 0xf755ea30 wine_switch_to_stack+0x1f(func=0x7bc53570, arg=0x7b45f2f0, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xffda6508) 12 0x7bc59279 LdrInitializeThunk+0x228(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3103] in ntdll (0xffda6548) 13 0x7b465179 __wine_kernel_init+0xa58() [/home/julliard/wine/wine/dlls/kernel32/process.c:1302] in kernel32 (0xffda7438) 14 0x7bc5a0c3 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3312] in ntdll (0xffda74a8) 15 0xf755cac3 wine_init+0x2a2(argc=0x3, argv=0xffda79e4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:956] in libwine.so.1 (0xffda74f8) 16 0x7c000a3a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:254] in <wine-loader> (0xffda7938) 17 0xf736a276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7ecb5a48 test_occlusion_query+0xe58 [/home/julliard/wine/wine/dlls/d3d9/tests/device.c:5713] in d3d9_test: movl 0x0(%eax),%edx 5713 IDirect3DSurface9_Release(rt); -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] gdi32: Initialize rgbReserved to zero in SetDIBColorTable
by Nikolay Sivov 22 Nov '16

22 Nov '16

On 11/22/2016 06:36 PM, Daniel Lehman wrote: > removes a TODO > > Signed-off-by: Daniel Lehman <dlehman25(a)gmail.com> > --- > dlls/gdi32/dib.c | 9 ++++++++- > dlls/gdi32/tests/bitmap.c | 3 ++- > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c > index 36a7b0f..6636f23 100644 > --- a/dlls/gdi32/dib.c > +++ b/dlls/gdi32/dib.c > @@ -922,7 +922,7 @@ INT WINAPI SetDIBitsToDevice(HDC hdc, INT xDest, INT yDest, DWORD cx, > UINT WINAPI SetDIBColorTable( HDC hdc, UINT startpos, UINT entries, const RGBQUAD *colors ) > { > DC * dc; > - UINT result = 0; > + UINT i, result = 0; > BITMAPOBJ * bitmap; > > if (!(dc = get_dc_ptr( hdc ))) return 0; > @@ -933,6 +933,13 @@ UINT WINAPI SetDIBColorTable( HDC hdc, UINT startpos, UINT entries, const RGBQUA > { > result = min( entries, bitmap->dib.dsBmih.biClrUsed - startpos ); > memcpy(bitmap->color_table + startpos, colors, result * sizeof(RGBQUAD)); > + for (i = 0; i < result; i++) > + { > + bitmap->color_table[startpos + i].rgbBlue = colors[i].rgbBlue; > + bitmap->color_table[startpos + i].rgbGreen = colors[i].rgbGreen; > + bitmap->color_table[startpos + i].rgbRed = colors[i].rgbRed; > + bitmap->color_table[startpos + i].rgbReserved = 0; > + } > } Doesn't this make memcpy() redundant? A couple of options that could be used: - leave memcpy() and only reset rgbReserved() in the loop; - remove memcpy(); - remove memcpy(), add another memcpy() for a size of three fields instead of a quad, keep separate rgbReserved assignment; Not sure which one will be the fastest, could depend on 'result' value too. > GDI_ReleaseObj( dc->hBitmap ); > > diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c > index 5539283..88250ca 100644 > --- a/dlls/gdi32/tests/bitmap.c > +++ b/dlls/gdi32/tests/bitmap.c > @@ -880,12 +880,13 @@ static void test_dibsections(void) > ok( ret == 1, "SetDIBColorTable returned unexpected result %u\n", ret ); > ok( rgb[0].rgbReserved == 123, "Expected rgbReserved = 123, got %u\n", rgb[0].rgbReserved ); > > + rgb[0].rgbRed = rgb[0].rgbGreen = rgb[0].rgbBlue = rgb[0].rgbReserved = -1; > ret = GetDIBColorTable( hdcmem, 0, 1, rgb ); > ok( ret == 1, "GetDIBColorTable returned unexpected result %u\n", ret ); > ok( rgb[0].rgbRed == 1, "Expected rgbRed = 1, got %u\n", rgb[0].rgbRed ); > ok( rgb[0].rgbGreen == 2, "Expected rgbGreen = 2, got %u\n", rgb[0].rgbGreen ); > ok( rgb[0].rgbBlue == 3, "Expected rgbBlue = 3, got %u\n", rgb[0].rgbBlue ); > - todo_wine ok( rgb[0].rgbReserved == 0, "Expected rgbReserved = 0, got %u\n", rgb[0].rgbReserved ); > + ok( rgb[0].rgbReserved == 0, "Expected rgbReserved = 0, got %u\n", rgb[0].rgbReserved ); > > SelectObject(hdcmem, oldbm); > DeleteObject(hdib);

1 0

Re: Jeremy Newman : beginnings of HTML5 code and updating design
by Bruno Jesus 22 Nov '16

22 Nov '16

On Mon, Nov 21, 2016 at 12:38 PM, Jeremy Newman <jnewman(a)winehq.org> wrote: > ... > include/header.php | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/include/header.php b/include/header.php > index 014a8c4..ff01e3b 100644 > --- a/include/header.php > +++ b/include/header.php > @@ -2,28 +2,31 @@ > /*********************************/ > /* Application Database - Header */ > /*********************************/ > -?><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > -<html> > +?><!doctype html> > +<html lang="en"> > <head> > <title>WineHQ <?php echo $title; ?></title> > - <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> > - <meta HTTP-EQUIV="Expires" CONTENT="Mon, 06 Jan 1990 00:00:01 GMT"> > - <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> > + > + <meta charset="utf-8"> > <meta name="description" content="Open Source Software for running Windows applications on other operating systems."> > <meta name="keywords" content="windows, linux, macintosh, solaris, freebsd"> > <meta name="robots" content="index, follow"> > <meta name="copyright" content="Copyright WineHQ.org All Rights Reserved."> > <meta name="language" content="English"> > <meta name="revisit-after" content="1"> > + > + <link href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin="anonymous"> > + <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.6.1/css/font-awesome.min.css"> > + <link rel="stylesheet" href="https://code.jquery.com/ui/1.11.4/themes/smoothness/jquery-ui.css" type="text/css" media="all"> Why not https://code.jquery.com/ui/1.11.4/themes/smoothness/jquery-ui.min.css ?

2 3

Re: [PATCH 2/3] kernel32/tests: On failure don't test the returned count - it contains random data on Windows 8 and 10.
by Marvin 22 Nov '16

22 Nov '16

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=26790 Your paranoid android. === w864 (32 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed === w1064 (32 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed === w1064 (64 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed

1 0

Re: [PATCH 1/3] kernel32/tests: Add some GetLastError() values for Windows 8 and 10.
by Marvin 22 Nov '16

22 Nov '16

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=26789 Your paranoid android. === w864 (32 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [13] Expected output count to be 0, got 2685552 console.c:1497: Test failed: [15] Expected output count to be 0, got 2685616 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 2685680 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [13] Expected output count to be 0, got 2685552 console.c:1741: Test failed: [15] Expected output count to be 0, got 2685616 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 2685680 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1 === w1064 (32 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [13] Expected output count to be 0, got 51 console.c:1497: Test failed: [15] Expected output count to be 0, got 43 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 43 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [13] Expected output count to be 0, got 51 console.c:1741: Test failed: [15] Expected output count to be 0, got 43 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 43 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1

1 0

Re: [PATCH 2/6] wined3d: Increase data size for occlusion queries to 8 bytes.
by Henri Verbeet 22 Nov '16

22 Nov '16

On 21 November 2016 at 15:15, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -115,7 +115,9 @@ static DWORD WINAPI d3d9_query_GetDataSize(IDirect3DQuery9 *iface) > > wined3d_mutex_lock(); > type = wined3d_query_get_type(query->wined3d_query); > - if (type == WINED3D_QUERY_TYPE_TIMESTAMP_DISJOINT) > + if (type == WINED3D_QUERY_TYPE_OCCLUSION) > + ret = sizeof(DWORD); We probably don't care that much, but note that this only works with little-endian byte order.

1 0

Re: [PATCH] d2d1: Implement DrawLine() over DrawGeometry() for a linear path
by Henri Verbeet 22 Nov '16

22 Nov '16

On 21 November 2016 at 13:10, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + ID2D1GeometrySink_BeginFigure(sink, p0, D2D1_FIGURE_BEGIN_FILLED); > + ID2D1GeometrySink_AddLine(sink, p1); > + ID2D1GeometrySink_EndFigure(sink, D2D1_FIGURE_END_CLOSED); Strictly speaking D2D1_FIGURE_BEGIN_HOLLOW and D2D1_FIGURE_END_OPEN would be more appropriate here, but it shouldn't matter in practice.

1 0

Re: [v2 2/2] d3d11/tests: Add test of SV_VertexID.
by Józef Kucia 22 Nov '16

22 Nov '16

On Fri, Nov 18, 2016 at 6:06 AM, Andrew Wesie <awesie(a)gmail.com> wrote: > +static void test_sm4_vertexid(void) I would drop the "sm4" prefix. > + static const D3D11_INPUT_ELEMENT_DESC layout_desc[] = > + { > + { "SV_Position", 0, DXGI_FORMAT_R32G32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 }, > + { "SV_VertexID", 0, DXGI_FORMAT_R32_UINT, 1, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 }, > + }; I don't think that SV_VertexID should be a part of the input layout.

2 1

Re: [v2 1/2] wined3d: Fix mapping of SV_VertexID to gl_VertexID.
by Henri Verbeet 22 Nov '16

22 Nov '16

On 18 November 2016 at 06:06, Andrew Wesie <awesie(a)gmail.com> wrote: > @@ -424,6 +424,9 @@ static void wined3d_cs_exec_draw(struct wined3d_cs *cs, const void *data) > device_invalidate_state(cs->device, STATE_BASEVERTEXINDEX); > } > > + state->base_vertex_index = op->indexed ? op->base_vertex_idx : op->start_idx; I don't think you can do this, the modified state would be visible to the application through wined3d_stateblock_capture() and wined3d_device_get_base_vertex_index(). > + device_invalidate_state(cs->device, STATE_BASEVERTEXINDEX); State invalidation isn't free, so it may be better to avoid doing this unnecessarily. But if you do do this unconditionally, the invalidation of STATE_BASEVERTEXINDEX a few lines above becomes redundant. > @@ -1793,7 +1800,8 @@ static void shader_glsl_declare_generic_vertex_attribute(struct wined3d_string_b > > if (e->sysval_semantic == WINED3D_SV_VERTEX_ID) > { > - shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID), 0.0, 0.0, 0.0);\n", > + shader_addline(buffer, "uniform int base_vertex;\n"); > + shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID - base_vertex), 0.0, 0.0, 0.0);\n", > index); > return; > } Note that in principle this code would do the wrong thing when ARB_draw_elements_base_vertex is not supported. The reason it works in practice is that SV_VertexID is a SM4+ feature, and SM4 requires GL 3.2, which implies ARB_draw_elements_base_vertex. That's fine, but could do with a comment.

1 0

Re: [v2 2/2] d3d11/tests: Add test for primitive restart index.
by Henri Verbeet 22 Nov '16

22 Nov '16

Józef pointed out a couple of issues in the other patches that also apply here. I won't repeat those. On 18 November 2016 at 04:45, Andrew Wesie <awesie(a)gmail.com> wrote: > + static const struct vec2 vertices[] = > + { > + { -1.0f, -1.0f }, > + { -1.0f, 1.0f }, > + { 1.0f, -1.0f }, > + { 1.0f, 1.0f }, > + { -1.0f, -1.0f }, > + { -1.0f, 1.0f }, > + { 1.0f, -1.0f }, > + { 1.0f, 1.0f }, > + }; This works, but for primitive restart in particular it may be more useful to not draw these overlapping and instead use e.g. {-1.0f, -0.25f, 0.25f, 1.0f} for the x-coordinates. > + static const unsigned int indices[] = > + { > + 0, 1, 2, 3, 0xFFFFFFFF, 4, 5, 6, 7 > + }; We use lowercase hexadecimal constants. > + hr = ID3D11Device_CreateInputLayout(device, layout_desc, > + sizeof(layout_desc) / sizeof(*layout_desc), > + vs_code, sizeof(vs_code), &test_context.input_layout); I realise test_cb_relative_addressing() in particular uses test_context's input_layout field in a similar way, but it doesn't strike me as something we'd want to encourage. Likewise for the "vs" and "vb" fields. We use double indentation for line continuations. > + expected_color = 0xff0000ff; > + ID3D11DeviceContext_IASetIndexBuffer(test_context.immediate_context, ib, DXGI_FORMAT_R32_UINT, 0); > + ID3D11DeviceContext_DrawIndexed(test_context.immediate_context, 9, 0, 0); > + check_texture_color(test_context.backbuffer, expected_color, 0); > + > + ID3D11DeviceContext_IASetIndexBuffer(test_context.immediate_context, ib16, DXGI_FORMAT_R16_UINT, 0); > + ID3D11DeviceContext_DrawIndexed(test_context.immediate_context, 9, 0, 0); > + check_texture_color(test_context.backbuffer, expected_color, 0); The "expected_color" variable seems unnecessary here.

1 0

Re: [PATCH 1/2] regedit: Overhaul Unicode line processing
by Alexandre Julliard 22 Nov '16

22 Nov '16

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > + p = strpbrkW(line, line_endings); > + if (!p) > + { > + HeapFree(GetProcessHeap(), 0, buf); > + return NULL; If there are no line endings you need to read more data instead of failing. Also it looks to me that you are reading the entire file into the buffer instead of just one line. -- Alexandre Julliard julliard(a)winehq.org

2 4

Code style guidelines on the wiki
by Alex Henrie 22 Nov '16

22 Nov '16

As requested at WineConf, I have rewritten the wiki's notes about code style to match our current practices, as best I understand them: https://wiki.winehq.org/Submitting_Patches#Code_guidelines Please read this over, let me know what you think, and feel free to edit the wiki directly. -Alex

2 1

readelf: Error: the dynamic segment offset + size exceeds the size of the file
by Hin-Tak Leung 22 Nov '16

22 Nov '16

Hi, Just rebuilding the wine staging rpm from fedora, and towards the end I see piles of "readelf: Error: the dynamic segment offset + size exceeds the size of the file" on wine's dll.so's. This is specific to the rpm build and packaging process - AFAIK this strips off the debuginfo so that it can be shipped as a separate package. Nonetheless, should I worry about it, and/or file this as a problem of readelf (binutils)? Thanks. Hin-Tak

1 0

Re: [4/5] quartz: Add tests for IBasicVideo.
by Andrew Eikum 21 Nov '16

21 Nov '16

It's a good start, though I'm a little concerned your tests didn't turn up the bugs I found in 2/5, 3/5, and 5/5, nor the bug I noticed in BaseControlVideoImpl_get_DestinationHeight while reviewing your patches... Andrew On Sun, Nov 20, 2016 at 03:33:25PM +0900, Akihiro Sagawa wrote: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/quartz/tests/filtergraph.c | 93 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 93 insertions(+) > > diff --git a/dlls/quartz/tests/filtergraph.c b/dlls/quartz/tests/filtergraph.c > index 87b1123..a92aab3 100644 > --- a/dlls/quartz/tests/filtergraph.c > +++ b/dlls/quartz/tests/filtergraph.c > @@ -50,6 +50,97 @@ static int createfiltergraph(void) > &CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, &IID_IGraphBuilder, (LPVOID*)&pgraph); > } > > +static void test_basic_video(void) > +{ > + IBasicVideo* pbv; > + LONG video_width, video_height; > + LONG left, top, width, height; > + HRESULT hr; > + > + hr = IGraphBuilder_QueryInterface(pgraph, &IID_IBasicVideo, (LPVOID*)&pbv); > + ok(hr==S_OK, "Cannot get IBasicVideo interface returned: %x\n", hr); > + > + /* test get video size */ > + hr = IBasicVideo_GetVideoSize(pbv, NULL, NULL); > + ok(hr==E_POINTER, "IBasicVideo_GetVideoSize returned: %x\n", hr); > + hr = IBasicVideo_GetVideoSize(pbv, &video_width, NULL); > + ok(hr==E_POINTER, "IBasicVideo_GetVideoSize returned: %x\n", hr); > + hr = IBasicVideo_GetVideoSize(pbv, NULL, &video_height); > + ok(hr==E_POINTER, "IBasicVideo_GetVideoSize returned: %x\n", hr); > + hr = IBasicVideo_GetVideoSize(pbv, &video_width, &video_height); > + ok(hr==S_OK, "Cannot get video size returned: %x\n", hr); > + > + /* test source position */ > + hr = IBasicVideo_GetSourcePosition(pbv, NULL, NULL, NULL, NULL); > + ok(hr == E_POINTER, "IBasicVideo_GetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_GetSourcePosition(pbv, &left, &top, NULL, NULL); > + ok(hr == E_POINTER, "IBasicVideo_GetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_GetSourcePosition(pbv, NULL, NULL, &width, &height); > + ok(hr == E_POINTER, "IBasicVideo_GetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_GetSourcePosition(pbv, &left, &top, &width, &height); > + ok(hr == S_OK, "Cannot get source position returned: %x\n", hr); > + ok(left == 0, "expected 0, got %d\n", left); > + ok(top == 0, "expected 0, got %d\n", top); > + ok(width == video_width, "expected %d, got %d\n", video_width, width); > + ok(height == video_height, "expected %d, got %d\n", video_height, height); > + > + hr = IBasicVideo_SetSourcePosition(pbv, 0, 0, 0, 0); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_put_SourceTop(pbv, -1); > + ok(hr==E_INVALIDARG, "IBasicVideo_put_SourceTop returned: %x\n", hr); > + hr = IBasicVideo_put_SourceTop(pbv, 0); > + ok(hr==S_OK, "Cannot put source top returned: %x\n", hr); > + hr = IBasicVideo_put_SourceTop(pbv, 1); > + todo_wine ok(hr==E_INVALIDARG, "IBasicVideo_put_SourceTop returned: %x\n", hr); > + > + hr = IBasicVideo_SetSourcePosition(pbv, video_width, 0, 1, video_height); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_SetSourcePosition(pbv, 0, video_height, video_width, 1); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetSourcePosition returned: %x\n", hr); > + > + hr = IBasicVideo_SetSourcePosition(pbv, 0, 0, video_width, video_height+1); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetSourcePosition returned: %x\n", hr); > + hr = IBasicVideo_SetSourcePosition(pbv, 0, 0, video_width+1, video_height); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetSourcePosition returned: %x\n", hr); > + > + /* test destination position */ > + hr = IBasicVideo_GetDestinationPosition(pbv, NULL, NULL, NULL, NULL); > + ok(hr == E_POINTER, "IBasicVideo_GetDestinationPosition returned: %x\n", hr); > + hr = IBasicVideo_GetDestinationPosition(pbv, &left, &top, NULL, NULL); > + ok(hr == E_POINTER, "IBasicVideo_GetDestinationPosition returned: %x\n", hr); > + hr = IBasicVideo_GetDestinationPosition(pbv, NULL, NULL, &width, &height); > + ok(hr == E_POINTER, "IBasicVideo_GetDestinationPosition returned: %x\n", hr); > + hr = IBasicVideo_GetDestinationPosition(pbv, &left, &top, &width, &height); > + ok(hr == S_OK, "Cannot get destination position returned: %x\n", hr); > + ok(left == 0, "expected 0, got %d\n", left); > + ok(top == 0, "expected 0, got %d\n", top); > + todo_wine ok(width == video_width, "expected %d, got %d\n", video_width, width); > + todo_wine ok(height == video_height, "expected %d, got %d\n", video_height, height); > + > + hr = IBasicVideo_SetDestinationPosition(pbv, 0, 0, 0, 0); > + ok(hr==E_INVALIDARG, "IBasicVideo_SetDestinationPosition returned: %x\n", hr); > + > + hr = IBasicVideo_put_DestinationLeft(pbv, -1); > + todo_wine ok(hr==S_OK, "Cannot put destination left returned: %x\n", hr); > + hr = IBasicVideo_put_DestinationLeft(pbv, 0); > + todo_wine ok(hr==S_OK, "Cannot put destination left returned: %x\n", hr); > + hr = IBasicVideo_put_DestinationLeft(pbv, 1); > + todo_wine ok(hr==S_OK, "Cannot put destination left returned: %x\n", hr); > + > + hr = IBasicVideo_SetDestinationPosition(pbv, 0, 0, video_width * 2, video_height * 2); > + ok(hr==S_OK, "Cannot set destination position returned: %x\n", hr); > + > + /* reset source position */ > + hr = IBasicVideo_SetSourcePosition(pbv, 0, 0, video_width, video_height); > + ok(hr==S_OK, "Cannot set source position returned: %x\n", hr); > + > + /* reset destination position */ > + hr = IBasicVideo_SetDestinationPosition(pbv, 0, 0, video_width, video_height); > + ok(hr==S_OK, "Cannot set destination position returned: %x\n", hr); > + > + IBasicVideo_Release(pbv); > +} > + > static void rungraph(void) > { > HRESULT hr; > @@ -70,6 +161,8 @@ static void rungraph(void) > > IMediaFilter_Release(pmf); > > + test_basic_video(); > + > hr = IMediaControl_Run(pmc); > ok(hr==S_FALSE, "Cannot run the graph returned: %x\n", hr); > >

1 0

Re: [3/5] strmbase: Add validation checks when updating destination rectangle.
by Andrew Eikum 21 Nov '16

21 Nov '16

On Sun, Nov 20, 2016 at 03:33:24PM +0900, Akihiro Sagawa wrote: > @@ -73,6 +73,17 @@ static HRESULT BaseControlVideoImpl_CheckSourceRect(BaseControlVideo *This, RECT > return S_OK; > } > > +static HRESULT BaseControlVideoImpl_CheckTargetRect(BaseControlVideo *This, RECT *pTargetRect) > +{ > + if (pTargetRect->top >= pTargetRect->bottom || > + pTargetRect->left >= pTargetRect->right || > + (pTargetRect->bottom - pTargetRect->top) <= 0 || > + (pTargetRect->right - pTargetRect->left) <= 0) > + return E_INVALIDARG; > + The third and fourth conditions seem redundant with the first and second. You could use IsRectEmpty() here as well. Andrew

1 0

Re: [5/5] strmbase: Shift source/destination rectangle when updating top or left property.
by Andrew Eikum 21 Nov '16

21 Nov '16

On Sun, Nov 20, 2016 at 03:33:26PM +0900, Akihiro Sagawa wrote: > @@ -212,7 +212,7 @@ HRESULT WINAPI BaseControlVideoImpl_put_SourceLeft(IBasicVideo *iface, LONG Sour > hr = This->pFuncsTable->pfnGetSourceRect(This, &SourceRect); > if (SUCCEEDED(hr)) > { > - SourceRect.left = SourceLeft; > + OffsetRect(&SourceRect, SourceLeft, 0); > hr = BaseControlVideoImpl_CheckSourceRect(This, &SourceRect); > } > if (SUCCEEDED(hr)) These look wrong to me. The SourceLeft argument is an absolute position, while OffsetRect takes an offset. Check my math, but I think you want something like OffsetRect( SourceLeft - SourceRect.left ). Andrew

1 0

Re: [3/5] strmbase: Add validation checks when updating destination rectangle.
by Andrew Eikum 21 Nov '16

21 Nov '16

On Sun, Nov 20, 2016 at 03:33:24PM +0900, Akihiro Sagawa wrote: > @@ -409,13 +438,19 @@ HRESULT WINAPI BaseControlVideoImpl_put_DestinationHeight(IBasicVideo *iface, LO > { > RECT DestRect; > BaseControlVideo *This = impl_from_IBasicVideo(iface); > + HRESULT hr; > > TRACE("(%p/%p)->(%d)\n", This, iface, DestinationHeight); > - This->pFuncsTable->pfnGetTargetRect(This, &DestRect); > - DestRect.right = DestRect.left + DestinationHeight; > - This->pFuncsTable->pfnSetTargetRect(This, &DestRect); > + hr = This->pFuncsTable->pfnGetTargetRect(This, &DestRect); > + if (SUCCEEDED(hr)) > + { > + DestRect.right = DestRect.left + DestinationHeight; You've got a copy-paste error here, unfortunately. Andrew

1 0

Re: [PATCH 6/6] d3d9/tests: Add test for occlusion query with result bigger than UINT32_MAX.
by Marvin 21 Nov '16

21 Nov '16

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=26773 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: [PATCH v2] winemapi: Directly use xdg-email if available, enabling file attachments.
by Hans Leidekker 21 Nov '16

21 Nov '16

On Thu, 2016-11-17 at 13:43 -0600, Jeremy White wrote: > +static ULONG add_argument(char **argv, int *argc, const char *arg, const char *param) > +{ > + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(arg) + 1); > + if (!argv[(*argc)]) > + return MAPI_E_INSUFFICIENT_MEMORY; > + strcpy(argv[(*argc)++], arg); > + > + if (param) > + { > + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(param) + 1); > + if (!argv[(*argc)]) > + return MAPI_E_INSUFFICIENT_MEMORY; > + strcpy(argv[(*argc)++], param); > + } > + > + return SUCCESS_SUCCESS; This still leaks when the first allocation succeeds and the second fails. > +static ULONG add_file(char **argv, int *argc, const char *path, const char *file) > +{ > + WCHAR *fullname, *p; > + char *unixpath; > + int namelen = 1; > + ULONG ret; > + > + if (path) > + namelen += strlen(path) + 1; > + if (file) > + namelen += strlen(file); > + > + p = fullname = HeapAlloc(GetProcessHeap(), 0, namelen * sizeof(WCHAR)); > + if (!fullname) > + return MAPI_E_INSUFFICIENT_MEMORY; > + memset(fullname, 0, namelen * sizeof(WCHAR)); You should pass HEAP_ZERO_MEMORY to HeapAlloc if you need a zero-initialized block but in this case it's sufficient to initialize the first element of fullname. > + if (path) > + { > + MultiByteToWideChar(CP_ACP, 0, path, -1, p, namelen); > + p += strlen(path); > + MultiByteToWideChar(CP_ACP, 0, "\\", 1, p, 1); > + p++; This is shorter and doesn't make an assumption about conversion length: p += MultiByteToWideChar(CP_ACP, 0, path, -1, p, namelen); > +ULONG XDGSendMail(LHANDLE session, ULONG_PTR uiparam, > + lpMapiMessage message, FLAGS flags, ULONG reserved) > +{ > + int i; > + int argc = 0; > + int max_args; > + char **argv = NULL; > + ULONG ret; > + > + TRACE("(0x%08lx 0x%08lx %p 0x%08x 0x%08x)\n", session, uiparam, message, flags, reserved); > + > + if (!message) > + return MAPI_E_FAILURE; > + > + max_args = 1 + (2 + message->nRecipCount + message->nFileCount) * 2; > + argv = HeapAlloc(GetProcessHeap(), 0, (max_args + 1) * sizeof(*argv)); > + if (!argv) > + return MAPI_E_INSUFFICIENT_MEMORY; > + > + memset(argv, 0, (max_args + 1) * sizeof(*argv)); See above.

1 0

Crash after accessing parts before allocated memory
by Fabian Maurer 21 Nov '16

21 Nov '16

This is a kind-of follow up to "Debugging wine and finding the cause of a crash", but another question. The program I'm debugging works reliably on windows/ReactOS, but on wine it crashes every time. I can get it to work by hacking RtlAllocateHeap to always allocate 5500 bytes more than needed, but that's hardly a solution. >From what I currently know, the issue stems from a few negative offsets being added on a pointer returned from RtlAllocateHeap. On windows this leads to accessing a memory region filled with zeroes, on wine it accesses random memory. The program can handle nullpointers, but not bogus pointer. Any ideas how to deal with that, or is UB like that just a no-go? I have zero knowledge about the internal management of the heap, so help would be appreciated. At least is seems suspicious subtracting something from a pointer it got from RtlAllocateHeap, but maybe there's some plan behind it.

3 4

Re: [v2 2/3] d3d10core/tests: Add test for nointerpolation support.
by Józef Kucia 21 Nov '16

21 Nov '16

On Sun, Nov 20, 2016 at 6:36 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > + struct VertexOut We generally do not use PascalCase. Please use snake_case. > + 0x43425844, 0x27846ba6, 0xd14f79cc, 0xc27a566f, 0xe83b028c, 0x00000001, 0x00000240, 0x00000005, > + 0x00000034, 0x0000008c, 0x000000c0, 0x00000114, 0x000001c4, 0x46454452, 0x00000050, 0x00000000, > + 0x00000000, 0x00000000, 0x0000001c, 0xfffe0400, 0x00000100, 0x0000001c, 0x7263694d, 0x666f736f, > + 0x52282074, 0x4c482029, 0x53204c53, 0x65646168, 0x6f432072, 0x6c69706d, 0x36207265, 0x392e332e, > + 0x2e303036, 0x38333631, 0xabab0034, 0x4e475349, 0x0000002c, 0x00000001, 0x00000008, 0x00000020, > + 0x00000000, 0x00000000, 0x00000003, 0x00000000, 0x00000f0f, 0x49534f50, 0x4e4f4954, 0xababab00, > + 0x4e47534f, 0x0000004c, 0x00000002, 0x00000008, 0x00000038, 0x00000000, 0x00000001, 0x00000003, > + 0x00000000, 0x0000000f, 0x00000044, 0x00000000, 0x00000000, 0x00000003, 0x00000001, 0x0000000f, > + 0x505f5653, 0x5449534f, 0x004e4f49, 0x4f4c4f43, 0xabab0052, 0x52444853, 0x000000a8, 0x00010040, > + 0x0000002a, 0x0300005f, 0x001010f2, 0x00000000, 0x04000067, 0x001020f2, 0x00000000, 0x00000001, > + 0x03000065, 0x001020f2, 0x00000001, 0x02000068, 0x00000001, 0x05000036, 0x001020f2, 0x00000000, > + 0x00101e46, 0x00000000, 0x07000031, 0x00100012, 0x00000000, 0x0010100a, 0x00000000, 0x00004001, > + 0x00000000, 0x0f000037, 0x001020f2, 0x00000001, 0x00100006, 0x00000000, 0x00004002, 0x00000000, > + 0x00000000, 0x3f800000, 0x3f800000, 0x00004002, 0x3f800000, 0x00000000, 0x00000000, 0x3f800000, > + 0x0100003e, 0x54415453, 0x00000074, 0x00000004, 0x00000001, 0x00000000, 0x00000003, 0x00000001, > + 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, > + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000001, 0x00000001, > + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 In order to make the shader bytecode a little bit smaller, the shader code should be compiled with /Qstrip_debug and /Qstrip_reflect options. This applies to other patches as well, but please do not resend before Henri's comments. > + static const struct vec2 quad[] = > + { > + { -1.0f, -1.0f }, > + { -1.0f, 1.0f }, > + { 1.0f, -1.0f }, > + { 1.0f, 1.0f }, > + }; Float literals are usually aligned.

1 0

Re: [v2 1/3] wined3d: Add support for flat interpolation in shaders.
by Józef Kucia 21 Nov '16

21 Nov '16

This is still broken in the same way as the first version: fixme:d3d_shader:print_glsl_info_log error: interpolation modifier mismatch for varying parameter (named ps_link1) between shader stages On Sun, Nov 20, 2016 at 6:36 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/glsl_shader.c | 47 ++++++++++++++++++++++++++++++------------ > dlls/wined3d/shader.c | 7 +++++++ > dlls/wined3d/wined3d_private.h | 1 + > 3 files changed, 42 insertions(+), 13 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 9e9c83b..5df1827 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -2162,7 +2162,14 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > UINT in_count = min(vec4_varyings(version->major, gl_info), shader->limits->packed_input); > > if (ps_args->vp_mode == vertexshader) > - declare_in_varying(gl_info, buffer, FALSE, "vec4 %s_link[%u];\n", prefix, in_count); > + { > + unsigned int j; > + for (j = 0; j < in_count; j++) > + { > + declare_in_varying(gl_info, buffer, shader->u.ps.input_reg_flags[j] == WINED3DSIM_CONSTANT, > + "vec4 %s_link%u;\n", prefix, j); > + } > + } We should add a FIXME() message for other unsupported interpolation modes. We do not want to hide that those are still not implemented. Currently, we have a FIXME() for the dcl_input_ps instruction. > + else if (ins.handler_idx == WINED3DSIH_DCL_INPUT_PS) > + { > + unsigned int reg_idx = ins.declaration.dst.reg.idx[0].offset; > + reg_maps->input_registers |= 1u << reg_idx; > + /* We can assume we are in the pixel shader */ > + shader->u.ps.input_reg_flags[reg_idx] = ins.flags; > + } We tend to check the shader type and print a FIXME() message in similar cases instead of adding a comment. See WINED3DSIH_DCL_INPUT_PRIMITIVE, WINED3DSIH_DCL_OUTPUT_TOPOLOGY and WINED3DSIH_DCL_VERTICES_OUT. > /* Pixel shader input semantics */ > DWORD input_reg_map[MAX_REG_INPUT]; > BOOL input_reg_used[MAX_REG_INPUT]; > + enum wined3d_shader_interpolation_mode input_reg_flags[MAX_REG_INPUT]; I think we could use better name for this variable, e.g. "input_reg_interpolation_mode" or "interpolation_mode".

1 0

Re: [v2 1/4] wined3d: Implement buffer shader resource views.
by Józef Kucia 21 Nov '16

21 Nov '16

I've also submitted a patch series for buffer shader views a while back [1]. My series seems to have better tests. The "lod" parameter handling is probably solved in a nicer way as well. On Sun, Nov 20, 2016 at 6:16 PM, Andrew Wesie <awesie(a)gmail.com> wrote: > + case GL_TEXTURE_BUFFER: > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, 0); > + checkGLcall("glBindTexture"); > + break; I suppose that a dummy texture is generally required in order to get correct results for unbound shader views. > + {"GL_ARB_texture_buffer_range", ARB_TEXTURE_BUFFER_RANGE }, This extension has to be also added to the "core_extensions" table. > +static void wined3d_shader_resource_view_create_buffer_view(struct wined3d_shader_resource_view *view, > + const struct wined3d_shader_resource_view_desc *desc, struct wined3d_buffer *buffer, > + const struct wined3d_format *view_format) > +{ > + const struct wined3d_gl_info *gl_info; > + struct wined3d_context *context; > + > + context = context_acquire(buffer->resource.device, NULL); > + gl_info = context->gl_info; > + > + wined3d_buffer_load_location(buffer, context, WINED3D_LOCATION_BUFFER); > + > + gl_info->gl_ops.gl.p_glGenTextures(1, &view->object); > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, view->object); > + > + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object, > + desc->u.buffer.start_idx * view_format->byte_count, desc->u.buffer.count * view_format->byte_count)); It would be nice to check if ARB_texture_buffer_range is supported and fallback to ARB_texture_buffer_object. This might be especially useful for macOS. > + checkGLcall("Create buffer view"); > + > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_BUFFER, 0); > + context_release(context); > +} This might invalidate shader resource bindings. There is no need to unbind the texture buffer, but you need to call "context_invalidate_state(context, STATE_SHADER_RESOURCE_BINDING);". [1] - https://www.winehq.org/pipermail/wine-patches/2016-March/148496.html

1 0

FOSDEM stand
by Marcus Meissner 19 Nov '16

19 Nov '16

Hi, (In follow up to the more conference/tradeshow presence topic of Wineconf.) I checked the FOSDEM website and the deadline for stands (small tables) was October 31st, so passed. Ciao, Marcus

1 0

Re: [v2] ntdll: Fix and test exception codes on x86-64.
by Marvin 18 Nov '16

18 Nov '16

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=26726 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:594: Test failed: 42: Unexpected eip 0x340000/0x340001 exception: unhandled exception 80000004 at 00340000 exception.c:594: Test failed: 42: Unexpected eip 0x77baed97/0x340001 === w7u (32 bit exception) === exception.c:594: Test failed: 42: Unexpected eip 0x710000/0x710001 exception: unhandled exception 80000004 at 00710000 exception.c:594: Test failed: 42: Unexpected eip 0x77cde34f/0x710001 === w1064 (32 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died) === wvistau64 (64 bit exception) === exception.c:2227: Test failed: 36: Unexpected eip 0x260000/0x260001 exception: unhandled exception 80000004 at 0000000000260000 === w1064 (64 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died)

1 0

Re: [PATCH] dwrite: Make it clear that wine_dbgstr_longlong() output is in hex
by Ken Thomases 18 Nov '16

18 Nov '16

If its output is hex, shouldn't wine_dbgstr_longlong() add the "0x" itself? -Ken > On Nov 16, 2016, at 10:57 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/font.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/dlls/dwrite/font.c b/dlls/dwrite/font.c > index 7672aa6..2e1eab0 100644 > --- a/dlls/dwrite/font.c > +++ b/dlls/dwrite/font.c > @@ -4373,11 +4373,12 @@ static ULONG WINAPI localfontfilestream_Release(IDWriteFontFileStream *iface) > return ref; > } > > -static HRESULT WINAPI localfontfilestream_ReadFileFragment(IDWriteFontFileStream *iface, void const **fragment_start, UINT64 offset, UINT64 fragment_size, void **fragment_context) > +static HRESULT WINAPI localfontfilestream_ReadFileFragment(IDWriteFontFileStream *iface, void const **fragment_start, > + UINT64 offset, UINT64 fragment_size, void **fragment_context) > { > struct dwrite_localfontfilestream *This = impl_from_IDWriteFontFileStream(iface); > > - TRACE_(dwrite_file)("(%p)->(%p, %s, %s, %p)\n",This, fragment_start, > + TRACE_(dwrite_file)("(%p)->(%p, 0x%s, 0x%s, %p)\n", This, fragment_start, > wine_dbgstr_longlong(offset), wine_dbgstr_longlong(fragment_size), fragment_context); > > *fragment_context = NULL; > @@ -5744,7 +5745,7 @@ static HRESULT WINAPI fontfacereference_EnqueueFileFragmentDownloadRequest(IDWri > { > struct dwrite_fontfacereference *This = impl_from_IDWriteFontFaceReference(iface); > > - FIXME("(%p)->(%s %s): stub\n", This, wine_dbgstr_longlong(offset), wine_dbgstr_longlong(size)); > + FIXME("(%p)->(0x%s 0x%s): stub\n", This, wine_dbgstr_longlong(offset), wine_dbgstr_longlong(size)); > > return E_NOTIMPL; > } > -- > 2.10.2 > > >

2 1

x86 User-Mode Instruction Prevention and winehq
by Neri, Ricardo 18 Nov '16

18 Nov '16

Hi All, I am working on implementing support for a new feature in the Linux kernel named User-Mode Instruction Prevention that will be present in upcoming Intel processors. In a nutshell, if this feature is present and enabled, a general protection fault will happen if any of the following instructions is executed with CPL > 0. * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register The goal of this feature is to prevent user space applications to read the resources mentioned above. For instance, a user-space application could easily read the descriptor tables and use that to instrument an attack. I am aware that maybe wine (or applications using wine) might want to use some of these instructions. For instance, wine might want to use the sgdt instruction to emulate the VxD driver model. Currently the proposed implementation is as follows: If running in protected mode, always propagate the GP fault to the user space via a sigsegv. If running in vm86 mode, trap the GP fault within the kernel and give the userspace fake values for the aforementioned resources (most likely zeros). Also, UMIP will be able to be disabled via a kernel command-line parameter at boot. I would like to inquire about the current use of these instructions and whether it would be catastrophic for wine to lose access to them. Your feedback will be greatly appreciated. You can see the original patch post here [1]. http://www.spinics.net/lists/kernel/msg2377725.html Thanks and BR, Ricardo

2 6

Re: [PATCH v2] msvcrt: Implement nearbyint and nearbyintf
by Piotr Caban 18 Nov '16

18 Nov '16

Hi, it looks like your patch got corrupted by your mail client. Here are some hints about sending patches: https://wiki.winehq.org/Submitting_Patches#Sending_the_patch if you have any questions please let me know. Thanks, Piotr On 18/11/16 00:45, Stefan Silviu wrote: > It now has a fallback if the functions are missing. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41695 > > Signed-off-by: Stefan Silviu <sylviu44(a)gmail.com> > --- > configure | 2 ++ > configure.ac | 2 ++ > .../api-ms-win-crt-math-l1-1-0.spec | 4 ++-- > dlls/msvcrt/math.c | 24 ++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 ++ > dlls/ucrtbase/ucrtbase.spec | 4 ++-- > include/msvcrt/math.h | 3 +++ > 7 files changed, 37 insertions(+), 4 deletions(-) > > diff --git a/configure b/configure > index f91d64d..d347956 100755 > --- a/configure > +++ b/configure > @@ -17121,6 +17121,8 @@ for ac_func in \ > lrintf \ > lround \ > lroundf \ > + nearbyint \ > + nearbyintf \ > powl \ > remainder \ > remainderf \ > diff --git a/configure.ac b/configure.ac > index 2489ac0..9c03fc8 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2554,6 +2554,8 @@ AC_CHECK_FUNCS(\ > lrintf \ > lround \ > lroundf \ > + nearbyint \ > + nearbyintf \ > powl \ > remainder \ > remainderf \ > diff --git a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > index f886b97..b781276 100644 > --- a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > @@ -291,8 +291,8 @@ > @ stub nan > @ stub nanf > @ stub nanl > -@ stub nearbyint > -@ stub nearbyintf > +@ cdecl nearbyint(double) ucrtbase.nearbyint > +@ cdecl nearbyintf(float) ucrtbase.nearbyintf > @ stub nearbyintl > @ cdecl nextafter(double double) ucrtbase.nextafter > @ cdecl nextafterf(float float) ucrtbase.nextafterf > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index e87151a..32c32b0 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -1354,6 +1354,30 @@ double CDECL MSVCRT__yn(int order, double num) > } > > /********************************************************************* > + * _nearbyint (MSVCRT.@) > + */ > +double CDECL MSVCRT_nearbyint(double num) > +{ > + #ifdef HAVE_NEARBYINT > + return nearbyint(num); > + #else > + return num >= 0 ? floor(num + 0.5) : ceil(num - 0.5); > + #endif > +} > + > +/********************************************************************* > + * _nearbyintf (MSVCRT.@) > + */ > +float CDECL MSVCRT_nearbyintf(float num) > +{ > + #ifdef HAVE_NEARBYINTF > + return nearbyintf(num); > + #else > + return MSVCRT_nearbyint(num); > + #endif > +} > + > +/********************************************************************* > * _nextafter (MSVCRT.@) > */ > double CDECL MSVCRT__nextafter(double num, double next) > diff --git a/dlls/msvcrt/msvcrt.spec b/dlls/msvcrt/msvcrt.spec > index 0c1d4ad..d44e880 100644 > --- a/dlls/msvcrt/msvcrt.spec > +++ b/dlls/msvcrt/msvcrt.spec > @@ -837,6 +837,8 @@ > @ cdecl _msize(ptr) > # stub -arch=win32 _msize_debug(ptr long) > # stub -arch=win64 _msize_dbg(ptr long) > +@ cdecl nearbyint(double) MSVCRT_nearbyint > +@ cdecl nearbyintf(float) MSVCRT_nearbyintf > @ cdecl _nextafter(double double) MSVCRT__nextafter > @ cdecl -arch=arm,x86_64 _nextafterf(float float) MSVCRT__nextafterf > @ cdecl _onexit(ptr) MSVCRT__onexit > diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec > index 2aa0563..111de2e 100644 > --- a/dlls/ucrtbase/ucrtbase.spec > +++ b/dlls/ucrtbase/ucrtbase.spec > @@ -2432,8 +2432,8 @@ > @ stub nan > @ stub nanf > @ stub nanl > -@ stub nearbyint > -@ stub nearbyintf > +@ cdecl nearbyint(double) MSVCRT_nearbyint > +@ cdecl nearbyintf(float) MSVCRT_nearbyintf > @ stub nearbyintl > @ cdecl nextafter(double double) MSVCRT__nextafter > @ cdecl nextafterf(float float) MSVCRT__nextafterf > diff --git a/include/msvcrt/math.h b/include/msvcrt/math.h > index c76fe0d..5b42b4d 100644 > --- a/include/msvcrt/math.h > +++ b/include/msvcrt/math.h > @@ -148,6 +148,9 @@ float __cdecl fmodf(float, float); > > #define ldexpf(x,y) ((float)ldexp((double)(x),(y))) > > +double __cdecl nearbyint(double); > +float __cdecl nearbyintf(float); > + > float __cdecl _hypotf(float, float); > > int __cdecl _matherr(struct _exception*);

1 0

Re: [PATCH 2/2] winegstreamer: Make some strings static constants.
by Andrew Eikum 18 Nov '16

18 Nov '16

This adds a bunch of warnings for me: main.c:69:9: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] { { wNull, main.c:273:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] argv[0] = argv0; ^ main.c:274:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] argv[1] = argv1; Andrew On Thu, Nov 17, 2016 at 08:46:38AM -0700, Alex Henrie wrote: > Cc: Andrew Eikum <aeikum(a)codeweavers.com> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/winegstreamer/main.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/winegstreamer/main.c b/dlls/winegstreamer/main.c > index 2bb69f4..6c49572 100644 > --- a/dlls/winegstreamer/main.c > +++ b/dlls/winegstreamer/main.c > @@ -52,7 +52,7 @@ static const WCHAR wGstreamer_Mp3[] = > static const WCHAR wGstreamer_AudioConvert[] = > {'G','S','t','r','e','a','m','e','r',' ','A','u','d','i','o','C','o','n','v','e','r','t',' ','f','i','l','t','e','r',0}; > > -static WCHAR wNull[] = {'\0'}; > +static const WCHAR wNull[] = {'\0'}; > > static const AMOVIESETUP_MEDIATYPE amfMTstream[] = > { { &MEDIATYPE_Stream, &WINESUBTYPE_Gstreamer }, > @@ -262,8 +262,8 @@ DWORD Gstreamer_init(void) > static int inited; > > if (!inited) { > - char argv0[] = "wine"; > - char argv1[] = "--gst-disable-registry-fork"; > + static const char argv0[] = "wine"; > + static const char argv1[] = "--gst-disable-registry-fork"; > char **argv = HeapAlloc(GetProcessHeap(), 0, sizeof(char *)*3); > int argc = 2; > GError *err = NULL; > -- > 2.10.2 >

2 1

Re: winex11: Always use the Virtual Core Pointer for raw events
by Henri Verbeet 18 Nov '16

18 Nov '16

On 12 November 2016 at 17:14, Carlos Garnacho <carlosg(a)gnome.org> wrote: > Second, in the unlikely case that Wine managed to detect a master > pointer other than the VCP (this requires user intervention, creating > a second pointer/keyboard pair and assigning HW devices to it) This > second pointer would be unaffected by the core X calls performed by > Wine (eg. grabs,cursor). This could eg. result in Wine grabbing/confining > one pointer, while listening to raw events from another, which is > otherwise unaffected by the grab. > I'm not sure that's necessarily wrong, but using XIGrabDevice(), XIWarpPointer(), etc. would probably be enough to fix that. > The Virtual Core Pointer is a given, it always has ID=2, it's created > by default, it can't be removed, it's the one getting HW devices attached > to by default, and it will be the device implicitly used by the other > X core calls. It's the device Wine wants to listen to despite its initial > state. > That probably works in practice, but I can't think of anything in the protocol spec that guarantees the VCP has id 2. Did I miss something there? How about XIGetClientPointer(), would that do the right thing? > The main purpose of this patch is fixing master device detection over > Xwayland, which is affected by the relative axes check. Xwayland will > most usually emit pointer events as coming from a device with absolute > axes, only switching to emitting relative motion when a very specific > set of conditions are met (thought out for gaming basically). But most > usually these conditions don't apply yet when XI2 is enabled, so the > VCP is skipped and it ends up with xi2_core_pointer=0, thus ignoring > the relative motion that is later sent. > > But again, this is not Xwayland specific, it could happen as well with > the right conditions on traditional X servers. > Wouldn't the correct way to handle this kind of thing be to respond to XI_DeviceChanged and XI_HierarchyChanged events?

2 3

Re: [v4 PATCH 1/4] dpnet/test: Add IDirectPlay8Client EnumHost tests
by Stefan Dösinger 17 Nov '16

17 Nov '16

Am 2016-11-17 um 07:08 schrieb Alistair Leslie-Hughes: > + Sleep(1000); I think there should be ways to avoid this sleep. E.g. you could store the expected number of callbacks in a global variable and signal an event in the callback handler when it has been reached. If any additional callbacks are invoked report an error in the callback. In the main thread do a timed wait for the event and check for timeouts to catch cases where too few callback invocations take place. That way you limit the timeout to error cases. A one second sleep may not be long, but these things do sum up over the entire testsuite, so we should put in some effort to minimize the time make test requires. You also have some PCRAP uses in the code (PDPNMSG_ASYNC_OP_COMPLETE). Stefan

1 0

Re: [PATCH] msvcrt: Implement nearbyint and nearbyintf
by Piotr Caban 17 Nov '16

17 Nov '16

Hi Stefan, On 17/11/16 08:15, Stefan Silviu wrote: > /********************************************************************* > + * _nearbyint (MSVCRT.@) > + */ > +double CDECL MSVCRT_nearbyint(double num) > +{ > + return nearbyint(num); > +} > The nearbyint function is not available in C89 standard. Could you please implement the function without using it or do something similar as in MSVCR120_rint? Thank you, Piotr

2 2

Re: [v3 PATCH 4/4] dpnet: Add Sync support in IDirectPlay8Client EnumHost
by Marvin 17 Nov '16

17 Nov '16

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=26697 Your paranoid android. === wxppro (32 bit client) === client.c:254: Test failed: got 0x00000002 === w2003std (32 bit client) === client.c:254: Test failed: got 0x00000002 === wvistau64 (32 bit client) === client.c:254: Test failed: got 0x00000002 === w2008s64 (32 bit client) === client.c:254: Test failed: got 0x00000002 === w7u (32 bit client) === client.c:254: Test failed: got 0x00000002 === w7pro64 (32 bit client) === client.c:254: Test failed: got 0x00000002 === wvistau64 (64 bit client) === client.c:254: Test failed: got 0x00000002 === w2008s64 (64 bit client) === client.c:254: Test failed: got 0x00000002 === w7pro64 (64 bit client) === client.c:254: Test failed: got 0x00000002

1 0

Re: [v3 PATCH 2/4] dpnet: Add basic validation in IDirectPlay8Client EnumHosts
by Marvin 17 Nov '16

17 Nov '16

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=26696 Your paranoid android. === wxppro (32 bit client) === client.c:252: Test failed: got 0x00000002 === w2003std (32 bit client) === client.c:252: Test failed: got 0x00000002 === wvistau64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === w2008s64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === w7u (32 bit client) === client.c:244: Test failed: got 0x80004005 client.c:245: Test failed: got 0x00000002 client.c:251: Test failed: got 0x80004005 client.c:252: Test failed: got 0x00000002 === w7pro64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === wvistau64 (64 bit client) === client.c:252: Test failed: got 0x00000002 === w2008s64 (64 bit client) === client.c:252: Test failed: got 0x00000002 === w7pro64 (64 bit client) === client.c:252: Test failed: got 0x00000002

1 0

Re: [v3 PATCH 1/4] dpnet/test: Add IDirectPlay8Client EnumHost tests
by Marvin 17 Nov '16

17 Nov '16

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=26695 Your paranoid android. === wxppro (32 bit client) === client.c:252: Test failed: got 0x00000002 === w2003std (32 bit client) === client.c:252: Test failed: got 0x00000002 === wvistau64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === w2008s64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === w7u (32 bit client) === client.c:252: Test failed: got 0x00000002 === w7pro64 (32 bit client) === client.c:252: Test failed: got 0x00000002 === wvistau64 (64 bit client) === client.c:252: Test failed: got 0x00000002 === w2008s64 (64 bit client) === client.c:252: Test failed: got 0x00000002 === w7pro64 (64 bit client) === client.c:252: Test failed: got 0x00000002

1 0

Re: [PATCH] wininet: Resize buffer when call to InternetCanonicalizeUrlW fails in InternetCrackUrlW
by Sebastian Lackner 17 Nov '16

17 Nov '16

On 13.11.2016 21:15, Marcus Meissner wrote: > From: Michael Müller <michael(a)fds-team.de> > > Import from wine-staging > Fixes wine bug 40598 in staging > > Signed-off-by: Michael Mueller <michael(a)fds-team.de> > Signed-off-by: Marcus Meissner <meissner(a)suse.de> If the patch submission rules have not been changed at this WineConf, it is still not allowed to add Signed-off-by lines for other people. Also, the patch is most likely not the right way to fix it, as I already pointed out in https://www.winehq.org/pipermail/wine-patches/2016-July/152110.html: """ Reason for the failure is because after decoding a "/" is added, and it does not fit into the buffer anymore. Michael wrote a patch to dynamically allocate a buffer, however I do not think the "/" should be added in the first place. """ Regards, Sebastian

3 2

Re: [PATCH] urlmon: Fix buffer overflow in parse_canonicalize
by Marvin 17 Nov '16

17 Nov '16

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=26694 Your paranoid android. === w1064 (32 bit uri) === uri.c:7620: Test failed: Expected google.com.uk but got L"com.uk" on uri_tests[71].str_props[3]. uri.c:7620: Test failed: Expected google.uk.1 but got L"uk.1" on uri_tests[73].str_props[3]. uri.c:7618: Test failed: GetPropertyBSTR returned 0x00000000, expected 0x00000001. On uri_tests[76].str_props[3]. uri.c:7620: Test failed: Expected but got L".uk" on uri_tests[76].str_props[3]. uri.c:7620: Test failed: Expected google.com.[] but got L"com.[]" on uri_tests[77].str_props[3]. uri.c:7805: Test failed: Error: Expected google.com.uk but got L"com.uk" on uri_tests[71]. uri.c:7805: Test failed: Error: Expected google.uk.1 but got L"uk.1" on uri_tests[73]. uri.c:7803: Test failed: Error: GetDomain returned 0x00000000, expected 0x00000001 on uri_tests[76]. uri.c:7805: Test failed: Error: Expected but got L".uk" on uri_tests[76]. uri.c:7805: Test failed: Error: Expected google.com.[] but got L"com.[]" on uri_tests[77]. uri.c:8085: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[71].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 11 but got 4 on uri_tests[73].str_props[3]. uri.c:8083: Test failed: Error: GetPropertyLength returned 0x00000000, expected 0x00000001 on uri_tests[76].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 0 but got 3 on uri_tests[76].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[77].str_props[3]. uri.c:8152: Test failed: Error: Received flag for property 3 when not expected on uri_tests[76]. uri.c:8202: Test failed: Error: Wasn't expecting to have property 3 on uri_tests[76]. uri.c:10521: Test failed: Error: Expected google.com.uk but got L"com.uk" instead on uri_parse_tests[42]. uri.c:10524: Test failed: Error: Expected 13, but got 6 instead on uri_parse_tests[42]. === w1064 (64 bit uri) === uri.c:7620: Test failed: Expected google.com.uk but got L"com.uk" on uri_tests[71].str_props[3]. uri.c:7620: Test failed: Expected google.uk.1 but got L"uk.1" on uri_tests[73].str_props[3]. uri.c:7618: Test failed: GetPropertyBSTR returned 0x00000000, expected 0x00000001. On uri_tests[76].str_props[3]. uri.c:7620: Test failed: Expected but got L".uk" on uri_tests[76].str_props[3]. uri.c:7620: Test failed: Expected google.com.[] but got L"com.[]" on uri_tests[77].str_props[3]. uri.c:7805: Test failed: Error: Expected google.com.uk but got L"com.uk" on uri_tests[71]. uri.c:7805: Test failed: Error: Expected google.uk.1 but got L"uk.1" on uri_tests[73]. uri.c:7803: Test failed: Error: GetDomain returned 0x00000000, expected 0x00000001 on uri_tests[76]. uri.c:7805: Test failed: Error: Expected but got L".uk" on uri_tests[76]. uri.c:7805: Test failed: Error: Expected google.com.[] but got L"com.[]" on uri_tests[77]. uri.c:8085: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[71].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 11 but got 4 on uri_tests[73].str_props[3]. uri.c:8083: Test failed: Error: GetPropertyLength returned 0x00000000, expected 0x00000001 on uri_tests[76].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 0 but got 3 on uri_tests[76].str_props[3]. uri.c:8085: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[77].str_props[3]. uri.c:8152: Test failed: Error: Received flag for property 3 when not expected on uri_tests[76]. uri.c:8202: Test failed: Error: Wasn't expecting to have property 3 on uri_tests[76]. uri.c:10521: Test failed: Error: Expected google.com.uk but got L"com.uk" instead on uri_parse_tests[42]. uri.c:10524: Test failed: Error: Expected 13, but got 6 instead on uri_parse_tests[42].

2 1

[PATCH] winemapi: Directly use xdg-email if available, enabling file attachments.
by Jeremy White 16 Nov '16

16 Nov '16

Signed-off-by: Jeremy White <jwhite(a)codeweavers.com> --- This addresses https://bugs.winehq.org/show_bug.cgi?id=11770 for systems with xdg-email. --- dlls/winemapi/Makefile.in | 3 +- dlls/winemapi/sendmail.c | 45 +++++--- dlls/winemapi/winemapi_private.h | 28 +++++ dlls/winemapi/xdg-email.c | 230 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 291 insertions(+), 15 deletions(-) create mode 100644 dlls/winemapi/winemapi_private.h create mode 100644 dlls/winemapi/xdg-email.c diff --git a/dlls/winemapi/Makefile.in b/dlls/winemapi/Makefile.in index 813ee42..d6f79b4 100644 --- a/dlls/winemapi/Makefile.in +++ b/dlls/winemapi/Makefile.in @@ -3,4 +3,5 @@ IMPORTS = shlwapi shell32 mapi32 C_SRCS = \ main.c \ - sendmail.c + sendmail.c \ + xdg-email.c diff --git a/dlls/winemapi/sendmail.c b/dlls/winemapi/sendmail.c index 03a29ba..f7a63ca 100644 --- a/dlls/winemapi/sendmail.c +++ b/dlls/winemapi/sendmail.c @@ -36,6 +36,8 @@ #include "shlwapi.h" #include "wine/debug.h" +#include "winemapi_private.h" + WINE_DEFAULT_DEBUG_CHANNEL(winemapi); /* Escapes a string for use in mailto: URL */ @@ -70,23 +72,12 @@ static char *escape_string(char *in, char *empty_string) } /************************************************************************** - * MAPISendMail + * BrowserSendMail * - * Send a message using a native mail client. - * - * PARAMS - * session [I] Handle to a MAPI session. - * uiparam [I] Parent window handle. - * message [I] Pointer to a MAPIMessage structure. - * flags [I] Flags. - * reserved [I] Reserved, pass 0. - * - * RETURNS - * Success: SUCCESS_SUCCESS - * Failure: MAPI_E_FAILURE + * Send an email by forming a mailto uri and invoking a browser. * */ -ULONG WINAPI MAPISendMail(LHANDLE session, ULONG_PTR uiparam, +static ULONG BrowserSendMail(LHANDLE session, ULONG_PTR uiparam, lpMapiMessage message, FLAGS flags, ULONG reserved) { ULONG ret = MAPI_E_FAILURE; @@ -291,6 +282,32 @@ exit: return ret; } +/************************************************************************** + * MAPISendMail + * + * Send a message using a native mail client. + * + * PARAMS + * session [I] Handle to a MAPI session. + * uiparam [I] Parent window handle. + * message [I] Pointer to a MAPIMessage structure. + * flags [I] Flags. + * reserved [I] Reserved, pass 0. + * + * RETURNS + * Success: SUCCESS_SUCCESS + * Failure: MAPI_E_FAILURE + * + */ +ULONG WINAPI MAPISendMail(LHANDLE session, ULONG_PTR uiparam, + lpMapiMessage message, FLAGS flags, ULONG reserved) +{ + if (XDGMailAvailable()) + return XDGSendMail(session, uiparam, message, flags, reserved); + + return BrowserSendMail(session, uiparam, message, flags, reserved); +} + ULONG WINAPI MAPISendDocuments(ULONG_PTR uiparam, LPSTR delim, LPSTR paths, LPSTR filenames, ULONG reserved) { diff --git a/dlls/winemapi/winemapi_private.h b/dlls/winemapi/winemapi_private.h new file mode 100644 index 0000000..ac76ab3 --- /dev/null +++ b/dlls/winemapi/winemapi_private.h @@ -0,0 +1,28 @@ +/* + * + * Copyright 2016 Jeremy White + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#ifndef __WINEMAPI_PRIVATE_INCLUDED__ +#define __WINEMAPI_PRIVATE_INCLUDED__ + +ULONG XDGSendMail(LHANDLE session, ULONG_PTR uiparam, + lpMapiMessage message, FLAGS flags, ULONG reserved); +BOOLEAN XDGMailAvailable(void); + +#endif /* __WINEMAPI_PRIVATE_INCLUDED__ */ + diff --git a/dlls/winemapi/xdg-email.c b/dlls/winemapi/xdg-email.c new file mode 100644 index 0000000..6008d6e --- /dev/null +++ b/dlls/winemapi/xdg-email.c @@ -0,0 +1,230 @@ +/* + * MAPISendMail implementation for xdg-email + * + * Copyright 2016 Jeremy White for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include "config.h" +#include "wine/port.h" + +#include <stdarg.h> + +#define COBJMACROS + +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winnls.h" +#include "mapi.h" +#include "wine/debug.h" +#ifdef HAVE_UNISTD_H +#include <unistd.h> +#endif + +#include "winemapi_private.h" + +WINE_DEFAULT_DEBUG_CHANNEL(winemapi); + +static void add_argument(char **argv, int *argc, const char *arg, const char *param) +{ + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(arg) + 1); + strcpy(argv[(*argc)++], arg); + if (param) + { + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(param) + 1); + strcpy(argv[(*argc)++], param); + } +} + +static void add_target(char **argv, int *argc, ULONG class, const char *address) +{ + static const char smtp[] = "smtp:"; + + if (!strncasecmp(address, smtp, sizeof(smtp) - 1)) + address += sizeof(smtp) - 1; + + switch (class) + { + case MAPI_ORIG: + TRACE("From: %s\n (unused)", debugstr_a(address)); + break; + + case MAPI_TO: + TRACE("To: %s\n", debugstr_a(address)); + add_argument(argv, argc, address, NULL); + break; + + case MAPI_CC: + TRACE("CC: %s\n", debugstr_a(address)); + add_argument(argv, argc, "--cc", address); + break; + + case MAPI_BCC: + TRACE("BCC: %s\n", debugstr_a(address)); + add_argument(argv, argc, "--bcc", address); + break; + + default: + TRACE("Unknown recipient class: %d\n", class); + } +} + +static void add_file(char **argv, int *argc, const char *path, const char *file) +{ + WCHAR *fullname, *p; + char *unixpath; + int namelen = 1; + + if (path) + namelen += strlen(path) + 1; + if (file) + namelen += strlen(file); + + p = fullname = HeapAlloc(GetProcessHeap(), 0, namelen * sizeof(WCHAR)); + ZeroMemory(fullname, namelen * sizeof(WCHAR)); + if (path) + { + MultiByteToWideChar(CP_ACP, 0, path, -1, p, namelen); + p += namelen; + MultiByteToWideChar(CP_ACP, 0, "\\", 1, p, 1); + p ++; + } + if (file) + MultiByteToWideChar(CP_ACP, 0, file, -1, p, namelen - (p - fullname)); + + unixpath = wine_get_unix_file_name(fullname); + if (!unixpath) + TRACE("Cannot find unix path of '%s'; not attaching.\n", debugstr_w(fullname)); + HeapFree(GetProcessHeap(), 0, fullname); + if (!unixpath) + return; + + add_argument(argv, argc, "--attach", unixpath); + HeapFree(GetProcessHeap(), 0, unixpath); +} + +/************************************************************************** + * XDGIsAvailable + * + */ +BOOLEAN XDGMailAvailable(void) +{ +#ifdef HAVE_UNISTD_H + char *p, *q, *test; + int len; + int rc; + + for (p = getenv("PATH"); p; p = q) + { + while (*p == ':') + p++; + + if (!*p) + break; + + q = strchr(p, ':'); + len = q ? q - p : strlen(p); + + test = HeapAlloc(GetProcessHeap(), 0, len + strlen("xdg-email") + 1 + 1); + memcpy(test, p, len); + strcpy(test + len, "/"); + strcat(test, "xdg-email"); + + rc = access(test, X_OK); + HeapFree(GetProcessHeap(), 0, test); + + if (rc == 0) + return TRUE; + } +#endif + return FALSE; +} + +/************************************************************************** + * XDGSendMail + * + * Send a message using xdg-email mail client. + * + */ +ULONG XDGSendMail(LHANDLE session, ULONG_PTR uiparam, + lpMapiMessage message, FLAGS flags, ULONG reserved) +{ + int i; + int argc = 0; + int max_args; + char **argv = NULL; + ULONG ret = MAPI_E_FAILURE; + + TRACE("(0x%08lx 0x%08lx %p 0x%08x 0x%08x)\n", session, uiparam, message, flags, reserved); + + if (!message) + return MAPI_E_FAILURE; + + max_args = 1 + (2 + message->nRecipCount + message->nFileCount) * 2; + argv = HeapAlloc(GetProcessHeap(), 0, (max_args + 1) * sizeof(*argv)); + ZeroMemory(argv, (max_args + 1) * sizeof(*argv)); + + add_argument(argv, &argc, "xdg-email", NULL); + + if (message->lpOriginator) + TRACE("From: %s (unused)\n", debugstr_a(message->lpOriginator->lpszAddress)); + + for (i = 0; i < message->nRecipCount; i++) + { + if (!message->lpRecips) + { + WARN("Recipient %d missing\n", i); + goto exit; + } + + if (message->lpRecips[i].lpszAddress) + add_target(argv, &argc, message->lpRecips[i].ulRecipClass, + message->lpRecips[i].lpszAddress); + else + FIXME("Name resolution and entry identifiers not supported\n"); + } + + for (i = 0; i < message->nFileCount; i++) + { + TRACE("File Path: %s, name %s\n", debugstr_a(message->lpFiles[i].lpszPathName), + debugstr_a(message->lpFiles[i].lpszFileName)); + add_file(argv, &argc, message->lpFiles[i].lpszPathName, message->lpFiles[i].lpszFileName); + } + + if (message->lpszSubject) + { + TRACE("Subject: %s\n", debugstr_a(message->lpszSubject)); + add_argument(argv, &argc, "--subject", message->lpszSubject); + } + + if (message->lpszNoteText) + { + TRACE("Body: %s\n", debugstr_a(message->lpszNoteText)); + add_argument(argv, &argc, "--body", message->lpszNoteText); + } + + TRACE("Executing xdg-email; parameters:\n"); + for (i = 0; argv[i] && i <= max_args; i++) + TRACE(" %d: [%s]\n", i, argv[i]); + if (_spawnvp(_P_WAIT, "xdg-email", (const char **) argv) == 0) + ret = SUCCESS_SUCCESS; + +exit: + HeapFree(GetProcessHeap(), 0, argv); + return ret; +} + -- 2.1.4

2 1

Re: [PATCH] winemapi: Directly use xdg-email if available, enabling file attachments.
by Józef Kucia 16 Nov '16

16 Nov '16

On Thu, Nov 17, 2016, Jeremy White <jwhite(a)codeweavers.com> wrote: > +static void add_argument(char **argv, int *argc, const char *arg, const char *param) > +{ > + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(arg) + 1); > + strcpy(argv[(*argc)++], arg); > + if (param) > + { > + argv[(*argc)] = HeapAlloc(GetProcessHeap(), 0, strlen(param) + 1); > + strcpy(argv[(*argc)++], param); > + } > +} It looks like a memory leak.

1 0

Re: [PATCH] ntdll: Make LdrUnloadDLL() a stub for musl libc.
by Alexandre Julliard 16 Nov '16

16 Nov '16

He X <xw897002528(a)gmail.com> writes: > @@ -2898,6 +2898,7 @@ static void MODULE_DecRefCount( WINE_MODREF *wm ) > */ > NTSTATUS WINAPI LdrUnloadDll( HMODULE hModule ) > { > +#ifndef UNLOAD_AFTER_DLCLOSE > WINE_MODREF *wm; > NTSTATUS retv = STATUS_SUCCESS; > > @@ -2932,6 +2933,10 @@ NTSTATUS WINAPI LdrUnloadDll( HMODULE hModule ) > RtlLeaveCriticalSection( &loader_section ); > > return retv; > +#else > + TRACE("stab for musl\n"); > + return STATUS_SUCCESS; > +#endif You can't do that, unloading dlls is necessary in many cases. The corresponding .so not being unloaded could probably be detected by using destructors, though fixing musl may be preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 PATCH 1/3] dpnet/test: Add IDirectPlay8Client EnumHost tests
by Alexandre Julliard 16 Nov '16

16 Nov '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +static HRESULT lastAsyncCode = E_FAIL; > +static DPNHANDLE lastAsyncHandle = 0xdeadbeef; > + > +#define CHECK_LAST_ASYNC_OP(hr, handle) \ > + ok(lastAsyncCode == hr, "got 0x%08x\n", lastAsyncCode); \ > + ok(lastAsyncHandle == handle, "got 0x%08x\n", handle); \ > + lastAsyncCode = E_FAIL; lastAsyncHandle = 0xdeadbeef; Please don't define such macros. In this case you should simply spell it out explicitly, it's not a lot of code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 PATCH] winex11.drv: import X11's "text/html" as "HTML Format"
by Alexandre Julliard 16 Nov '16

16 Nov '16

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > +static char *standardize_text_html( const char *data, size_t size ) > +{ > + char *textHtml = NULL; > + > + /* Firefox uses UTF-16LE with byte order mark. Convert to UTF-8 without the BOM. */ > + if (size >= 2 && ((BYTE*)data)[0] == 0xff && ((BYTE*)data)[1] == 0xfe) > + { > + INT textHtmlSize = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR)&data[2], (size-2)/2, NULL, 0, NULL, NULL); > + textHtml = HeapAlloc(GetProcessHeap(), 0, textHtmlSize); > + if (textHtml) > + WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR)&data[2], (size-2)/2, textHtml, textHtmlSize, NULL, NULL); > + else > + ERR("out of memory\n"); > + } > + return textHtml; It seems to me that you should still import it even if it's not in Firefox format. -- Alexandre Julliard julliard(a)winehq.org

1 0

Question about wineconf 2016 decisions
by CARLOS RODRIGUEZ 16 Nov '16

16 Nov '16

Hi After see alexander julliard wineconf 2016 decisions Only i have ask if CSMT can arrive in wine 2.0 or will be postponed to next wine development cicle wine 2.1 Thanks

3 2

build error on wininet.h on wine testbot
by Daniel Lehman 16 Nov '16

16 Nov '16

I'm getting the errors below when submitting a patch to test bot, even though the patch doesn't modify wininet.h full log is https://urldefense.proofpoint.com/v2/url?u=http-3A__testbot.winehq.org_JobD… am I doing something wrong? Thanks daniel Applying patch + git apply --verbose /home/winetest/tools/testbot/var/../var/staging/patch.diff Checking patch dlls/urlmon/tests/uri.c... Checking patch dlls/urlmon/uri.c... Applied patch dlls/urlmon/tests/uri.c cleanly. Applied patch dlls/urlmon/uri.c cleanly. Making test executable + time make -j4 -C dlls/urlmon/tests make: Entering directory `/home/winetest/tools/testbot/var/build-mingw32/dlls/urlmon/tests' i686-w64-mingw32-gcc -c -o uri.o ../../../../wine/dlls/urlmon/tests/uri.c -I. -I../../../../wine/dlls/urlmon/tests \ -I../../../include -I../../../../wine/include -D__WINESRC__ -D_REENTRANT -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -D_WIN32 In file included from ../../../../wine/dlls/urlmon/tests/uri.c:33:0: ../../../../wine/include/wininet.h:1:1: error: stray '\35' in program ../../../../wine/include/wininet.h:1:3: warning: null character(s) ignored [enabled by default] ../../../../wine/include/wininet.h:1:1: error: stray '\210' in program ../../../../wine/include/wininet.h:1:1: error: stray '\377' in program ../../../../wine/include/wininet.h:1:1: error: stray '\377' in program ../../../../wine/include/wininet.h:1:1: error: stray '\200' in program ../../../../wine/include/wininet.h:1:1: error: unknown type name 'b' ../../../../wine/include/wininet.h:1:1: error: stray '\36' in program ../../../../wine/include/wininet.h:1:11: warning: null character(s) ignored [enabled by default] ../../../../wine/include/wininet.h:1:1: error: stray '\210' in program ../../../../wine/include/wininet.h:1:1: error: stray '\377' in program ...

2 1

Steam in Windows 7 mode
by Alex Henrie 16 Nov '16

16 Nov '16

Hi all, Everybody at WineConf (myself included) seemed pretty happy about the idea to have Wine use Windows 7 mode by default. However, it looks like Steam does not accept the -no-cef-sandbox parameter in Windows Vista and later. This means that if we switch to Windows 7, most parts of Steam will crash. I see a few options: 1. Ask the Steam developers to make -no-cef-sandbox work in all versions of Windows. 2. Tell users to switch to Windows XP mode before using Steam. 3. Commit some nasty hack to handle the syscall and continue normal processing. This needs further discussion. -Alex

2 1

Re: [17/23] wined3d: Implement return instruction.
by Andrew Wesie 16 Nov '16

16 Nov '16

Is the correct thing to add a test to dlls/d3d11/tests/d3d11.c that illustrates the bug and shows that the patch fixes the bug? -Andrew On Mon, Nov 14, 2016 at 5:07 PM, Marvin <testbot(a)winehq.org> wrote: > 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 "Rejected". > > This means that the patch has been rejected by a reviewer. You should > have received a mail explaining why it was rejected. You need to fix > the issue and resend the patch, or if you are convinced that your > patch is good as is, you should reply to the rejection message with > your counterarguments. > > 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. >

2 1

Debugging wine and finding the cause of a crash
by Fabian Maurer 16 Nov '16

16 Nov '16

I'm currently trying to get a program to work that doesn't work with wine, causing an access-violation at some unreadable address. The "+seh" output shows that it's the first crash, and "+relay" doesn't help much, since the last calls are "user32.GetKeyState" and similar. I already tried debugging the program, but at the place of the crash there aren't any wine functions called, so I assume it's some earlier parts (e.g. during loading) causing the issue. How do I go about finding which wine functions are the culprit? Any tips for that, how do you investigate such issues? It would be easy if it crashed directly after calling a WinApi function, but since it seems to crash much later in a completely different part of the code, I don't really know how to proceed.

2 2

Re: [PATCH 2/2] ntdll: Added TokenIsAppContainer semi-stub implementation.
by Marvin 15 Nov '16

15 Nov '16

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=26665 Your paranoid android. === w1064 (32 bit security) === security.c:4035: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4039: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4048: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4035: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4039: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4048: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: [PATCH 1/2] advapi32: Added TokenIsAppContainer tests.
by Marvin 15 Nov '16

15 Nov '16

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=26664 Your paranoid android. === w1064 (32 bit security) === security.c:4036: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4040: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4049: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4036: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4040: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4049: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: [PATCH] winegstreamer: Fix memory leak in amt_from_gst_caps_video.
by Andrew Eikum 15 Nov '16

15 Nov '16

This is an improvement, but I think we should go further and fix leaks in all of the failure cases. The problem is we're using the amt_from_gst_caps_video return value inconsistently. In accept_caps_sink, we unconditionally free the resulting AM_MEDIA_TYPE. But in setcaps_sink, we only free it, via the pin->pmt assignment, if amt_from_gst_caps_video succeeds. I think we should always free the allocated memory in the failure cases in amt_from_gst_caps_video, and then only free the resulting AMT in the calling functions if amt_from_gst_caps_video succeeded. The resulting AMT should never be used or freed if amt_from_gst_caps_video fails. Note that amt_from_gst_caps_audio has the same inconsistent return type handling. I would accept a separate patch to fix this handling, too. (Unlike for video, it doesn't currently matter in practice because of amt_from_gst_caps_audio's implementation.) Does that make sense? Andrew On Mon, Nov 14, 2016 at 11:43:21PM -0700, Alex Henrie wrote: > Cc: Andrew Eikum <aeikum(a)codeweavers.com> > > Coverity #713781, "Variable vih going out of scope leaks the storage it > points to." > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/winegstreamer/gstdemux.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/dlls/winegstreamer/gstdemux.c b/dlls/winegstreamer/gstdemux.c > index a6a41ab..5d97510 100644 > --- a/dlls/winegstreamer/gstdemux.c > +++ b/dlls/winegstreamer/gstdemux.c > @@ -179,18 +179,21 @@ static gboolean amt_from_gst_caps_audio(GstCaps *caps, AM_MEDIA_TYPE *amt) > > static gboolean amt_from_gst_caps_video(GstCaps *caps, AM_MEDIA_TYPE *amt) > { > - VIDEOINFOHEADER *vih = CoTaskMemAlloc(sizeof(*vih)); > - BITMAPINFOHEADER *bih = &vih->bmiHeader; > + VIDEOINFOHEADER *vih; > + BITMAPINFOHEADER *bih; > gint32 width = 0, height = 0, nom = 0, denom = 0; > GstVideoInfo vinfo; > > if (!gst_video_info_from_caps (&vinfo, caps)) > return FALSE; > width = vinfo.width; > height = vinfo.height; > nom = vinfo.fps_n; > denom = vinfo.fps_d; > > + vih = CoTaskMemAlloc(sizeof(*vih)); > + bih = &vih->bmiHeader; > + > amt->formattype = FORMAT_VideoInfo; > amt->pbFormat = (BYTE*)vih; > amt->cbFormat = sizeof(*vih); > -- > 2.10.2 >

2 1

Re: [resend PATCH 2/4] oledb32: IErrorRecords uses 0-based index to access record info
by Alistair Leslie-Hughes 15 Nov '16

15 Nov '16

Hi Nikolay, On 15/11/16 03:56, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > > + hr = IErrorRecords_GetRecordCount(errrecs, &cnt); > + ok(hr == S_OK, "got %08x\n", hr); > + ok(cnt == 0, "expected 2 got %d\n", cnt); The comment here is incorrect. Best Regards Alistair.

2 1

Re: [PATCH] cabinet: Properly initialize our internal fci structure v2(bug 36115)(valgrind)
by Huw Davies 14 Nov '16

14 Nov '16

On 14 Nov 2016, at 16:46, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > We did not initialize all items for our internal fci structure. > This should fix bug 36115 > > v2: > Remove comments, as suggested by Huw > > -- > bye bye ... Detlef > > Signed-off-by: Detlef Riekenberg <wine.dev(a)web.de> > --- > dlls/cabinet/fci.c | 19 +------------------ > 1 file changed, 1 insertion(+), 18 deletions(-) > > diff --git a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > index 70d4f3f..03fbf46 100644 > --- a/dlls/cabinet/fci.c > +++ b/dlls/cabinet/fci.c > @@ -1036,6 +1036,7 @@ HFCI __cdecl FCICreate( > return NULL; > } > > + memset(p_fci_internal, 0, sizeof(FCI_Int)); I also suggested changing the sizeof(FCI_Int) -> sizeof(*p_fci_internal), but maybe that wasn’t very clear. Huw.

1 0

WineConf decisions
by Alexandre Julliard 14 Nov '16

14 Nov '16

At this year's WineConf we again had good constructive discussions about the development process, and decided a number of things: - Version numbering will change to a sligthly shorter scheme. The next stable release will be called 2.0. Stable release updates will follow the existing scheme: 2.0.1, 2.0.2, etc. For the developemnt branch we will drop the intermediate number: releases will be numbered 2.1, 2.2, 2.3, etc. and the next stable release in late 2017 will be called 3.0. - Code freeze for the 2.0 release will start after 1.9.24, in 3-4 weeks, with a final release targeted around the end of the year. - Michael Stefaniuc has agreed to continue maintaining the stable branch, and will be in charge of the 2.0.x releases. - Since it sometimes takes months for the stable release to get into distributions, we'll look into providing binary packages of the stable branch to make it easier for users to stay up to date. - The default reported Windows version will be upgraded to Windows 7. This will be done on the development branch soon after 2.0 is released, so that we have the time to catch regressions and address them before the next stable release. - To further the integration of WineHQ and Wine-Staging, we'll look into merging the Staging website into the Wine Wiki. We'll also merge the IRC channels, and encourage people to discuss Staging issues on #winehq and #winehackers, with #wine-staging being retired at some point. - To make sure that no patch falls off the list unreviewed, we are going to implement a mechanism to automatically assign a reviewer from the MAINTAINERS pool when a patch has been in New state for a week without action. - Since reviewers assigned at random may not always be comfortable with fully signing off on a patch, we discussed adding an Acked-by header as a weaker version of Signed-off-by. We finally decided that for now, an informal mail to wine-devel would be good enough. We may revisit that decision if a formal header makes automation easier. I'm hoping that these improvements will make things better for everybody. As always, feedback is encouraged, especially from people who couldn't make it to WineConf. As we implement these changes, please let us know how we are doing, and where we can do better. -- Alexandre Julliard julliard(a)winehq.org

1 0

AppDB Maintainership and Updates
by Jeremy Newman 14 Nov '16

14 Nov '16

Hey all! Just wanted to let you all know that at WineConf we decided that I should once again take up the mantle of AppDB codebase maintainer. Woo! I'll be in charge of reviewing and approving AppDB patches from now on. If you want to submit patches, please send them to the wine-patches mailing list with the subject prefix of [AppDB]. Bugs and feature requests should be filed on Bugzilla as usual. Discussion can happen here on wine-devel, IRC #winehackers, or preferably on the Forums in the new "Website Issues" forum. I've started the process of cleaning up some of the code and moving things around. Please bear with me as I'll be doing this in whatever spare time I can find. I created a ToDo page in the Wiki that will track the various things that I've agreed to work on. If it is not listed there, then it is open for someone else to jump on. https://wiki.winehq.org/AppDB_ToDo_List -N

1 0

Re: [17/23] wined3d: Implement return instruction.
by Matteo Bruni 14 Nov '16

14 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > @@ -6079,8 +6101,26 @@ static GLuint shader_glsl_generate_vshader(const struct wined3d_context *context > /* Base Shader Body */ > shader_generate_main(shader, buffer, reg_maps, function, &priv_ctx); > > + shader_addline(buffer, "}\n"); > + > + TRACE("Compiling shader object %u.\n", shader_id); > + shader_glsl_compile(gl_info, shader_id, buffer->buffer); > + > + return shader_id; > +} This breaks < SM4 shaders, those don't have an explicit return instruction at the end. In general, each patch should pass the wine tests. Please run the d3d tests and make sure that none are broken by your patchset. Specifically, this patch breaks the d3d9 visual test pretty badly. It looks like there are more failures introduced by other patches in the series but I haven't tracked them down. > +static void shader_glsl_prologue_vs(const struct wined3d_shader_context *ctx) I think this should actually be "epilogue".

1 0

Re: [11/23] wined3d: Implement primitive restart index.
by Matteo Bruni 14 Nov '16

14 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/directx.c | 3 +++ > dlls/wined3d/glsl_shader.c | 14 ++++++++++++++ > dlls/wined3d/wined3d_gl.h | 2 ++ > 3 files changed, 19 insertions(+) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index a8c8c9f..c930cf6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -121,6 +121,7 @@ static const struct wined3d_extension_map gl_extension_map[] = > {"GL_ARB_draw_elements_base_vertex", ARB_DRAW_ELEMENTS_BASE_VERTEX }, > {"GL_ARB_draw_instanced", ARB_DRAW_INSTANCED }, > {"GL_ARB_ES2_compatibility", ARB_ES2_COMPATIBILITY }, > + {"GL_ARB_ES3_compatibility", ARB_ES3_COMPATIBILITY }, > {"GL_ARB_explicit_attrib_location", ARB_EXPLICIT_ATTRIB_LOCATION }, > {"GL_ARB_fragment_coord_conventions", ARB_FRAGMENT_COORD_CONVENTIONS}, > {"GL_ARB_fragment_program", ARB_FRAGMENT_PROGRAM }, > @@ -228,6 +229,7 @@ static const struct wined3d_extension_map gl_extension_map[] = > {"GL_NV_half_float", NV_HALF_FLOAT }, > {"GL_NV_light_max_exponent", NV_LIGHT_MAX_EXPONENT }, > {"GL_NV_point_sprite", NV_POINT_SPRITE }, > + {"GL_NV_primitive_restart", NV_PRIMITIVE_RESTART }, > {"GL_NV_register_combiners", NV_REGISTER_COMBINERS }, > {"GL_NV_register_combiners2", NV_REGISTER_COMBINERS2 }, > {"GL_NV_texgen_reflection", NV_TEXGEN_REFLECTION }, > @@ -3125,6 +3127,7 @@ static void load_gl_funcs(struct wined3d_gl_info *gl_info) > USE_GL_FUNC(glMapBuffer) /* OpenGL 1.5 */ > USE_GL_FUNC(glPointParameteri) /* OpenGL 1.4 */ > USE_GL_FUNC(glPointParameteriv) /* OpenGL 1.4 */ > + USE_GL_FUNC(glPrimitiveRestartIndex) > USE_GL_FUNC(glShaderSource) /* OpenGL 2.0 */ > USE_GL_FUNC(glStencilFuncSeparate) /* OpenGL 2.0 */ > USE_GL_FUNC(glStencilOpSeparate) /* OpenGL 2.0 */ AFAICS this function was added in OpenGL 3.1 and there is no specific ARB extension for it. Maybe adding a new WINED3D_GL_ entry to flag the availability of the function is a good idea. Also you probably want to MAP_GL_FUNCTION() the NV variant to the core one and add an entry for GL_ARB_ES3_compatibility to core_extensions. > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index f136536..27a5533 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -8613,6 +8613,20 @@ static void shader_glsl_init_context_state(struct wined3d_context *context) > > gl_info->gl_ops.gl.p_glEnable(GL_PROGRAM_POINT_SIZE); > checkGLcall("GL_PROGRAM_POINT_SIZE"); > + if (gl_info->supported[ARB_ES3_COMPATIBILITY]) > + { > + /* We prefer this method because it correctly handles 16-bit and 32-bit indices. */ > + gl_info->gl_ops.gl.p_glEnable(GL_PRIMITIVE_RESTART_FIXED_INDEX); > + checkGLcall("GL_PRIMITIVE_RESTART_FIXED_INDEX"); > + } > + else if (gl_info->supported[NV_PRIMITIVE_RESTART] && GL_EXTCALL(glPrimitiveRestartIndex)) > + { > + /* FIXME: Does this handle 16-bit indices correctly? */ > + GL_EXTCALL(glPrimitiveRestartIndex(0xFFFFFFFF)); > + checkGLcall("glPrimitiveRestartIndex"); > + gl_info->gl_ops.gl.p_glEnable(GL_PRIMITIVE_RESTART); > + checkGLcall("GL_PRIMITIVE_RESTART"); Probably not, but nothing prevents you to use 0xffff for 16-bit indices and force re-setting the restart index when changing between 16-bit and 32-bit indices.

2 2

Re: [08/23] wined3d: Allow viewport to be out-of-bounds if using offscreen target.
by Matteo Bruni 14 Nov '16

14 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/state.c | 42 ++++++++++++++++++++++-------------------- > 1 file changed, 22 insertions(+), 20 deletions(-) > > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index cd3763c..ed20e325 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -4617,26 +4617,6 @@ static void viewport_miscpart(struct wined3d_context *context, const struct wine > struct wined3d_viewport vp = state->viewport; > unsigned int width, height; > > - if (target) > - { > - if (vp.width > target->width) > - vp.width = target->width; > - if (vp.height > target->height) > - vp.height = target->height; > - > - wined3d_rendertarget_view_get_drawable_size(target, context, &width, &height); > - } > - else if (depth_stencil) > - { > - width = depth_stencil->width; > - height = depth_stencil->height; > - } > - else > - { > - FIXME("No attachments draw calls not supported.\n"); > - return; > - } > - > gl_info->gl_ops.gl.p_glDepthRange(vp.min_z, vp.max_z); > checkGLcall("glDepthRange"); > /* Note: GL requires lower left, DirectX supplies upper left. This is > @@ -4644,7 +4624,29 @@ static void viewport_miscpart(struct wined3d_context *context, const struct wine > if (context->render_offscreen) > gl_info->gl_ops.gl.p_glViewport(vp.x, vp.y, vp.width, vp.height); > else > + { > + if (target) > + { > + if (vp.width > target->width) > + vp.width = target->width; > + if (vp.height > target->height) > + vp.height = target->height; > + > + wined3d_rendertarget_view_get_drawable_size(target, context, &width, &height); > + } > + else if (depth_stencil) > + { > + width = depth_stencil->width; > + height = depth_stencil->height; > + } > + else > + { > + FIXME("No attachments draw calls not supported.\n"); > + return; > + } > + > gl_info->gl_ops.gl.p_glViewport(vp.x, (height - (vp.y + vp.height)), vp.width, vp.height); > + } > checkGLcall("glViewport"); > } You need to make the same change to viewport_miscpart_cc() (you can blame me for that). Again, it would be very nice to have a testcase for this. Extending viewport_test() in d3d9/tests/visual.c and adding similar tests to the other d3d versions shouldn't be too hard.

2 2

Re: [PATCH] hidclass: All reports read or written to user space lead with a reportId
by Sebastian Lackner 14 Nov '16

14 Nov '16

On 14.11.2016 14:35, Aric Stewart wrote: > This is a little confusing because reports to and from the device > itself only have a leading reportId if the reportid is not 0. > Otherwise there is no leading reportId. So we need to add a 0 reportId > to reports coming from such a device and strip the leading 0 from > reports written to the device. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hidclass.sys/descriptor.c | 31 ++++----------- > dlls/hidclass.sys/device.c | 90 ++++++++++++++++++++++++++++-------------- > 2 files changed, 67 insertions(+), 54 deletions(-) > > > > 0001-hidclass-All-reports-read-or-written-to-user-space-lea.txt > > > diff --git a/dlls/hidclass.sys/descriptor.c b/dlls/hidclass.sys/descriptor.c > index 9a26f0f4..8bcda43 100644 > --- a/dlls/hidclass.sys/descriptor.c > +++ b/dlls/hidclass.sys/descriptor.c > @@ -887,10 +887,8 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > new_report(wine_report, input_features[0]); > data->dwInputReportCount++; > > - if (input_features[0]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + /* Room for the reportID */ > + bitOffset = 8; > > for (i = 0; i < i_count; i++) > { > @@ -901,10 +899,7 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > new_report(wine_report, input_features[i]); > data->dwInputReportCount++; > bitLength = max(bitOffset, bitLength); > - if (input_features[i]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + bitOffset = 8; > } > build_elements(wine_report, input_features[i], &bitOffset); > count_elements(input_features[i], &data->caps.NumberInputButtonCaps, > @@ -922,10 +917,7 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > data->dwOutputReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > new_report(wine_report, output_features[0]); > data->dwOutputReportCount++; > - if (output_features[0]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + bitOffset = 8; > > for (i = 0; i < o_count; i++) > { > @@ -936,10 +928,7 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > new_report(wine_report, output_features[i]); > data->dwOutputReportCount++; > bitLength = max(bitOffset, bitLength); > - if (output_features[0]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + bitOffset = 8; > } > build_elements(wine_report, output_features[i], &bitOffset); > count_elements(output_features[i], &data->caps.NumberOutputButtonCaps, > @@ -957,10 +946,7 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > data->dwFeatureReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > new_report(wine_report, feature_features[0]); > data->dwFeatureReportCount++; > - if (feature_features[0]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + bitOffset = 8; > > for (i = 0; i < f_count; i++) > { > @@ -971,10 +957,7 @@ static WINE_HIDP_PREPARSED_DATA* build_PreparseData( > new_report(wine_report, feature_features[i]); > data->dwFeatureReportCount++; > bitLength = max(bitOffset, bitLength); > - if (feature_features[0]->caps.ReportID != 0) > - bitOffset = 8; > - else > - bitOffset = 0; > + bitOffset = 8; > } > build_elements(wine_report, feature_features[i], &bitOffset); > count_elements(feature_features[i], &data->caps.NumberFeatureButtonCaps, > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index 5dd5ebb..6454b67 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -197,6 +197,28 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > IoDeleteDevice(device); > } > > +static NTSTATUS copy_packet_into_buffer(HID_XFER_PACKET *packet, BYTE* buffer, ULONG buffer_length, ULONG *out_length) > +{ > + *out_length = 0; > + if (buffer_length > packet->reportBufferLen) > + { > + if (packet->reportId != 0) > + { > + memcpy(buffer, packet->reportBuffer, packet->reportBufferLen); > + *out_length = packet->reportBufferLen; The length check is a bit too strict in this case. You are returning STATUS_BUFFER_OVERFLOW even when the buffer is sufficient (buffer_length == packet->reportBufferLen). > + } > + else > + { > + buffer[0] = 0; > + memcpy(&buffer[1], packet->reportBuffer, packet->reportBufferLen); > + *out_length = packet->reportBufferLen + 1; > + } > + return STATUS_SUCCESS; > + } > + else > + return STATUS_BUFFER_OVERFLOW; > +} > + > static void HID_Device_processQueue(DEVICE_OBJECT *device) > { > LIST_ENTRY *entry; > @@ -217,20 +239,14 @@ static void HID_Device_processQueue(DEVICE_OBJECT *device) > RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > if (buffer_size) > { > + NTSTATUS hr; Maybe its just me, but I think "hr" is really a very bad name for NTSTATUS codes. ;) > + ULONG out_length; > IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > packet->reportBuffer = (BYTE *)packet + sizeof(*packet); > TRACE_(hid_report)("Processing Request (%i)\n",ptr); > - if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > - { > - memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > - irp->IoStatus.Information = packet->reportBufferLen; > - irp->IoStatus.u.Status = STATUS_SUCCESS; > - } > - else > - { > - irp->IoStatus.Information = 0; > - irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > - } > + hr = copy_packet_into_buffer(packet, irp->AssociatedIrp.SystemBuffer, irpsp->Parameters.Read.Length, &out_length); > + irp->IoStatus.u.Status = hr; > + irp->IoStatus.Information = out_length; > } > else > { > @@ -331,7 +347,10 @@ static DWORD CALLBACK hid_device_thread(void *args) > if (!exit_now && irp->IoStatus.u.Status == STATUS_SUCCESS) > { > packet->reportBufferLen = irp->IoStatus.Information; > - packet->reportId = packet->reportBuffer[0]; > + if (ext->preparseData->InputReports[0].reportID) > + packet->reportId = packet->reportBuffer[0]; > + else > + packet->reportId = 0; > RingBuffer_Write(ext->ring_buffer, packet); > HID_Device_processQueue(device); > } > @@ -461,9 +480,17 @@ static NTSTATUS HID_set_to_device(DEVICE_OBJECT *device, IRP *irp) > NTSTATUS rc; > > TRACE_(hid_report)("Device %p Buffer length %i Buffer %p\n", device, irpsp->Parameters.DeviceIoControl.InputBufferLength, irp->AssociatedIrp.SystemBuffer); > - packet.reportBuffer = irp->AssociatedIrp.SystemBuffer; > - packet.reportId = ((char*)irp->AssociatedIrp.SystemBuffer)[0]; > - packet.reportBufferLen = irpsp->Parameters.DeviceIoControl.InputBufferLength; > + packet.reportId = ((BYTE*)irp->AssociatedIrp.SystemBuffer)[0]; > + if (packet.reportId == 0) > + { > + packet.reportBuffer = &((BYTE*)irp->AssociatedIrp.SystemBuffer)[1]; > + packet.reportBufferLen = irpsp->Parameters.DeviceIoControl.InputBufferLength - 1; > + } > + else > + { > + packet.reportBuffer = irp->AssociatedIrp.SystemBuffer; > + packet.reportBufferLen = irpsp->Parameters.DeviceIoControl.InputBufferLength; > + } > TRACE_(hid_report)("(id %i, len %i buffer %p)\n", packet.reportId, packet.reportBufferLen, packet.reportBuffer); > > rc = call_minidriver(irpsp->Parameters.DeviceIoControl.IoControlCode, > @@ -636,20 +663,15 @@ NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > if (buffer_size) > { > IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation( irp ); > + NTSTATUS hr; Same here. > + ULONG out_length; > packet->reportBuffer = (BYTE *)packet + sizeof(*packet); > TRACE_(hid_report)("Got Packet %p %i\n", packet->reportBuffer, packet->reportBufferLen); > - if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > - { > - memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > - irp->IoStatus.Information = packet->reportBufferLen; > - irp->IoStatus.u.Status = STATUS_SUCCESS; > - } > - else > - { > - irp->IoStatus.Information = 0; > - irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > - } > - IoCompleteRequest( irp, IO_NO_INCREMENT ); > + > + hr = copy_packet_into_buffer(packet, irp->AssociatedIrp.SystemBuffer, irpsp->Parameters.Read.Length, &out_length); > + irp->IoStatus.Information = out_length; > + irp->IoStatus.u.Status = hr; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > } > else > { > @@ -671,9 +693,17 @@ NTSTATUS WINAPI HID_Device_write(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = 0; > > TRACE_(hid_report)("Device %p Buffer length %i Buffer %p\n", device, irpsp->Parameters.Write.Length, irp->AssociatedIrp.SystemBuffer); > - packet.reportBuffer = irp->AssociatedIrp.SystemBuffer; > - packet.reportId = ((char*)irp->AssociatedIrp.SystemBuffer)[0]; > - packet.reportBufferLen = irpsp->Parameters.Write.Length; > + packet.reportId = ((BYTE*)irp->AssociatedIrp.SystemBuffer)[0]; > + if (packet.reportId == 0) > + { > + packet.reportBuffer = &((BYTE*)irp->AssociatedIrp.SystemBuffer)[1]; > + packet.reportBufferLen = irpsp->Parameters.Write.Length - 1; Besides the fact that the code looks suspicious (couldn't a 0 byte also have a different meaning?) this will probably break the udev backend. As documented in https://www.kernel.org/doc/Documentation/hid/hidraw.txt, the write() command expects that the first byte is 0 if the device does not use numbered reports. > + } > + else > + { > + packet.reportBuffer = irp->AssociatedIrp.SystemBuffer; > + packet.reportBufferLen = irpsp->Parameters.Write.Length; > + } > TRACE_(hid_report)("(id %i, len %i buffer %p)\n", packet.reportId, packet.reportBufferLen, packet.reportBuffer); > > rc = call_minidriver(IOCTL_HID_WRITE_REPORT, device, NULL, 0, &packet, sizeof(packet)); > > >

2 4

Re: [12/23] wined3d: Clear WINED3D_BUFFER_DISCARD flag in unmap.
by Henri Verbeet 14 Nov '16

14 Nov '16

On 13 November 2016 at 19:35, Andrew Wesie <awesie(a)gmail.com> wrote: > @@ -1248,6 +1248,7 @@ static void wined3d_buffer_unmap(struct wined3d_buffer *buffer) > context_release(context); > > buffer_clear_dirty_areas(buffer); > + buffer->flags &= ~WINED3D_BUFFER_DISCARD; Does filtering redundant WINED3D_MAP_DISCARD maps still work after this? Why is this change needed?

1 0

Re: [10/23] d3d11: Reset base vertex index to zero when not using indexed draw.
by Henri Verbeet 14 Nov '16

14 Nov '16

On 13 November 2016 at 19:35, Andrew Wesie <awesie(a)gmail.com> wrote: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/d3d11/device.c | 4 ++++ > 1 file changed, 4 insertions(+) > I think this shouldn't be needed when you do the state invalidation in wined3d_cs_exec_draw(). Ideally we'd probably just get rid of wined3d_device_set_base_vertex_index(), but d3d8 stateblocks complicate that.

1 0

Re: [09/23] wined3d: Fix mapping of SV_VertexID to gl_VertexID.
by Henri Verbeet 14 Nov '16

14 Nov '16

On 13 November 2016 at 19:35, Andrew Wesie <awesie(a)gmail.com> wrote: > @@ -481,7 +481,7 @@ void wined3d_cs_emit_draw(struct wined3d_cs *cs, int base_vertex_idx, unsigned i > > op = cs->ops->require_space(cs, sizeof(*op)); > op->opcode = WINED3D_CS_OP_DRAW; > - op->base_vertex_idx = base_vertex_idx; > + op->base_vertex_idx = indexed ? base_vertex_idx : 0; This change seems questionable. Why is it needed? > @@ -1988,7 +1988,11 @@ void CDECL wined3d_device_set_base_vertex_index(struct wined3d_device *device, I > { > TRACE("device %p, base_index %d.\n", device, base_index); > > - device->update_state->base_vertex_index = base_index; > + if (device->update_state->base_vertex_index != base_index) > + { > + device->update_state->base_vertex_index = base_index; > + device_invalidate_state(device, STATE_BASEVERTEXINDEX); > + } > } This should happen in wined3d_cs_exec_draw(). (The background is that we're working on executing that on a different thread, and state invalidation should generally happen in that same thread.) > @@ -1424,6 +1425,12 @@ static void shader_glsl_load_constants(void *shader_priv, struct wined3d_context > checkGLcall("glUniform4fv"); > } > > + if (update_mask & WINED3D_SHADER_CONST_BASE_VERTEX) > + { > + GL_EXTCALL(glUniform1i(prog->vs.base_vertex_location, state->base_vertex_index)); > + checkGLcall("glUniform1i"); > + } > @@ -1793,7 +1800,8 @@ static void shader_glsl_declare_generic_vertex_attribute(struct wined3d_string_b > > if (e->sysval_semantic == WINED3D_SV_VERTEX_ID) > { > - shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID), 0.0, 0.0, 0.0);\n", > + shader_addline(buffer, "uniform int base_vertex;\n"); > + shader_addline(buffer, "vec4 vs_in%u = vec4(intBitsToFloat(gl_VertexID - base_vertex), 0.0, 0.0, 0.0);\n", > index); > return; > } Does this do the right thing when ARB_draw_elements_base_vertex is not supported?

1 0

Re: [00/23] Fixes to support Overwatch
by Matteo Bruni 14 Nov '16

14 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > This is the first set of patches to support running Overwatch under WINE. > There are additional patches necessary but I am still preparing those for > release. Wow, that's very cool! Thank you for your work! You can expect your patches to be reviewed over the next few days and get either sign-offs or comments about things to improve. Going forward, in general I suggest you to limit your patch series to 5 patches or so (depending on how it makes the most sense), it makes it easier to the reviewers. I'm going to reply to a few patches in your series with the things I noticed at a quick look...

2 1

Re: [PATCH] wined3d: Add Polaris GPUs and their driver.
by Henri Verbeet 14 Nov '16

14 Nov '16

On 13 November 2016 at 23:10, Grazvydas Ignotas <notasas(a)gmail.com> wrote: > - {HW_VENDOR_AMD, CARD_AMD_RADEON_R9, "AMD Radeon R9 290", DRIVER_AMD_R600, 4096}, > + {HW_VENDOR_AMD, CARD_AMD_RADEON_R9, "AMD Radeon R9 290", DRIVER_AMD_RX, 4096}, Is that change intentional?

2 4

Re: [PATCH v2] hidclass.sys: Handle POP and PUSH in device descriptors
by Sebastian Lackner 14 Nov '16

14 Nov '16

On 14.11.2016 15:08, Aric Stewart wrote: > + if (!list_empty(&caps_stack)) > + { > + struct caps_stack *entry, *cursor; > + ERR("%i unpopped device caps on the stack\n", list_count(&caps_stack)); > + LIST_FOR_EACH_ENTRY_SAFE(entry, cursor, &caps_stack, struct caps_stack, entry) > + list_remove(&entry->entry); I assume you also wanted to deallocate the remaining blocks? > + }

2 1

Status of HID in Wine
by Aric Stewart 14 Nov '16

14 Nov '16

Hello everyone, So with this the last few commits I can officially say that WINE now has a fully functioning HID stack for Linux hidraw devices. Thanks to Sebastian Lackner and Alexandre for all the help, reviews and attention paid. It is working and in the state it is now because of their assistance. This means that applications that use hid.dll or direct device access to HID devices will start seeing and being able to interact with devices. This is very exciting but is just the very first step. Of course any application trying to do HID directly would be a wonderful test case, I am sure there are many many things that will need to be refined and added before a real application starts being happy. I do have a very rough, quick, poorly coded test case for HID controllers available to the curious. https://www.codeweavers.com/xfer/aric/HID/hid.exe There are still manual steps required before things will start working. 1) By default no hidraw devices on Linux are given any access to users. So you will need to had rw permission to the /dev/hidraw<X> device that you want to have accessible in Wine. Or if you want to be wild and crazy you can add a new udev rule to add permission to all the devices as they are added. 2) The winebus service is not started by default yet. so you will need to start winebus. (wine net start winebus) This makes things a little complicated. I would recommend testing with a process like this: wine cmd net start winebus <test application> Or you an change the service start for winebus in the registry [System\\CurrentControlSet\\Services\\WineBus] "Start"=dword:00000002 I would love comment, reports, anything as people test various devices and programs. As for more platforms, patches for OS/X have just been submitted so that IOHID devices will work on Mac. Then I have a set of patches adding linux event devices as well. Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly) So tell me how things work! thanks, -aric

2 2

Re: uiautomationcore: add stub dll, with UiaClientsAreListening
by Sebastian Lackner 14 Nov '16

14 Nov '16

On 10.11.2016 08:39, Austin English wrote: > +@ stub UiaClientsAreListening You forgot to add the function to the spec file. Regards, Sebastian

1 0

Re: [PATCH] hidclass.sys: Handle POP and PUSH in device descriptors
by Nikolay Sivov 14 Nov '16

14 Nov '16

> + if (list_count(&caps_stack)) > + { > + struct caps_stack *entry, *cursor; > + ERR("%i unpopped device caps on the stack\n", list_count(&caps_stack)); > + LIST_FOR_EACH_ENTRY_SAFE(entry, cursor, &caps_stack, struct caps_stack, entry) > + list_remove(&entry->entry); > + } > + If you only want to check if there's any elements left, it's faster to do list_empty().

1 0

Re: [PATCH 2/4] include: Add d3d11 error codes.
by Henri Verbeet 14 Nov '16

14 Nov '16

On 14 November 2016 at 00:26, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +cpp_quote("#define _FACD3D11 (0x87c)") Does that really need a cpp_quote()?

1 0

Re: [PATCH 1/4] ddraw: Use wined3d_device_process_vertices for execute buffers (v2).
by Henri Verbeet 14 Nov '16

14 Nov '16

On 13 November 2016 at 22:12, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -627,29 +544,58 @@ static HRESULT WINAPI d3d_execute_buffer_Unlock(IDirect3DExecuteBuffer *iface) > static HRESULT WINAPI d3d_execute_buffer_SetExecuteData(IDirect3DExecuteBuffer *iface, D3DEXECUTEDATA *data) ... > + memcpy(&buffer->data, data, data->dwSize); It's not a new issue, but should be blindly accept "dwSize" here?

1 0

Re: [v2] cmd: Command chain fixes
by Hugh McMaster 14 Nov '16

14 Nov '16

On Monday, 14 November 2016 6:42 AM, Flávio J. Saraiva wrote: > I'd like to cancel/recall this patch, which is a partial fix. > > I have detected many issues that can't be properly fixed until the > parsing stage is redone, such as this one, so it's better to only > tackle them after redoing the parsing stage. > > I wanted to keep the tests, but didn't understand how to properly add > them as TODOs. (if it's even possible) Tests in cmd.exe can be marked as todo_wine by using the syntax @todo_wine@ at the start of the relevant line. The wiki page on cmd conformance tests has more information. [1] Thanks for working on this area. Hugh [1] https://wiki.winehq.org/Cmd_Conformance_Tests

1 0

Re: [PATCH] ntdll: Make LdrUnloadDLL() a stub for musl libc.
by Austin English 14 Nov '16

14 Nov '16

On Nov 14, 2016 1:24 AM, "He X" <xw897002528(a)gmail.com> wrote: > > https://bugs.winehq.org/show_bug.cgi?id=41703 Hi Wang, As musl's FAQ points out, you should be checking for the broken behavior explicitly, or fix musl itself: http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F Thanks for looking into this!

1 0

Re: [PATCH] cabinet: Properly initialize our internal fci structure (bug 36115)(valgrind)
by Huw Davies 14 Nov '16

14 Nov '16

Hi Detlef, It was nice to hear you today :-) > On 13 Nov 2016, at 16:58, Detlef Riekenberg <wine.dev(a)web.de> wrote: > diff --git a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > index 70d4f3f..5f2e4e7 100644 > --- a/dlls/cabinet/fci.c > +++ b/dlls/cabinet/fci.c > @@ -1036,6 +1036,8 @@ HFCI __cdecl FCICreate( > return NULL; > } > > + /* start with a clean structure */ There’s no need for this comment, the code is obvious > + memset(p_fci_internal, 0, sizeof(FCI_Int)); sizeof(*p_fci_internal) > p_fci_internal->magic = FCI_INT_MAGIC; > p_fci_internal->perf = perf; > p_fci_internal->fileplaced = pfnfiledest; > @@ -1050,26 +1052,9 @@ HFCI __cdecl FCICreate( > p_fci_internal->gettemp = pfnfcigtf; > p_fci_internal->ccab = *pccab; > p_fci_internal->pccab = pccab; > - p_fci_internal->fPrevCab = FALSE; > - p_fci_internal->fNextCab = FALSE; > - p_fci_internal->fSplitFolder = FALSE; > - p_fci_internal->fGetNextCabInVain = FALSE; > p_fci_internal->pv = pv; > - p_fci_internal->cdata_in = 0; > - p_fci_internal->cCompressedBytesInFolder = 0; > - p_fci_internal->cFolders = 0; > - p_fci_internal->cFiles = 0; > - p_fci_internal->cDataBlocks = 0; > p_fci_internal->data.handle = -1; > - p_fci_internal->fNewPrevious = FALSE; > - p_fci_internal->estimatedCabinetSize = 0; > - p_fci_internal->statusFolderTotal = 0; > - p_fci_internal->folders_size = 0; > - p_fci_internal->files_size = 0; > - p_fci_internal->placed_files_size = 0; > - p_fci_internal->pending_data_size = 0; > - p_fci_internal->folders_data_size = 0; > - p_fci_internal->compression = tcompTYPE_NONE; > + /* the memset selected tcompTYPE_NONE */ Again, this comment doesn’t add anything. > p_fci_internal->compress = compress_NONE; > > list_init( &p_fci_internal->folders_list );

1 0

Re: [06/23] ntdll: Map empty page if needed inside system mappings.
by Matteo Bruni 13 Nov '16

13 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Some anti-debug protections will try to read all of the memory > for a loaded system DLL. This patch will handle the page fault when > it attempts to read the space between sections. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/virtual.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index e826fa0..f70e9fc 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1512,6 +1512,11 @@ NTSTATUS virtual_handle_fault( LPCVOID addr, DWORD err, BOOL on_signal_stack ) > /* ignore fault if page is writable now */ > if (VIRTUAL_GetUnixProt( *vprot ) & PROT_WRITE) ret = STATUS_SUCCESS; > } > + if (err == 0 && (view->protect & VPROT_SYSTEM)) > + { > + wine_anon_mmap(page, page_size, PROT_READ, MAP_FIXED); > + ret = STATUS_SUCCESS; > + } > if (!on_signal_stack && (*vprot & VPROT_GUARD)) > { > VIRTUAL_SetProt( view, page, page_size, *vprot & ~VPROT_GUARD ); This looks like a much nicer solution than my hack attached to the bug. I don't have time right now to check for all the implications of this patch, when / if I can get around to do a proper review I'll sign it off, for what it might be worth.

1 0

Re: [18/23] wined3d: Add support for flat interpolation in shaders.
by Matteo Bruni 13 Nov '16

13 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> It looks like you're never declaring shader outputs as flat. Is the potential mismatch with the shader input declarations a problem? BTW, I find it a bit surprising that flat varyings are actually used in SM4+ applications, AFAIK there is no way to mark inputs / outputs as flat in HLSL, which would suggest some kind of manual tinkering with the shader bytecode is required to use them.

3 2

Re: [14/23] wined3d: Increase vertex and fragment sampler limit.
by Matteo Bruni 13 Nov '16

13 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/wined3d_private.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index d23b7ef..97f3265 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -176,8 +176,8 @@ static inline enum complex_fixup get_complex_fixup(struct color_fixup_desc fixup > #define MAX_STREAM_OUT 4 > #define MAX_STREAMS 16 > #define MAX_TEXTURES 8 > -#define MAX_FRAGMENT_SAMPLERS 16 > -#define MAX_VERTEX_SAMPLERS 4 > +#define MAX_FRAGMENT_SAMPLERS 32 > +#define MAX_VERTEX_SAMPLERS 32 > #define MAX_COMBINED_SAMPLERS (MAX_FRAGMENT_SAMPLERS + MAX_VERTEX_SAMPLERS) > #define MAX_ACTIVE_LIGHTS 8 > #define MAX_CLIP_DISTANCES WINED3DMAXUSERCLIPPLANES I don't think this is how we want to solve this. See bug 41213 comment 6 and 8 for my point of view on the matter.

1 0

Re: [09/23] wined3d: Fix mapping of SV_VertexID to gl_VertexID.
by Matteo Bruni 13 Nov '16

13 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > SV_VertexID does not have base vertex index applied, but gl_VertexID > does. Fix the vertex ID by subtracting a uniform that is set to the > base vertex index before each draw. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/wined3d/cs.c | 2 +- > dlls/wined3d/device.c | 6 +++++- > dlls/wined3d/glsl_shader.c | 13 ++++++++++++- > dlls/wined3d/state.c | 7 ++++++- > dlls/wined3d/wined3d_private.h | 1 + > 5 files changed, 25 insertions(+), 4 deletions(-) > > diff --git a/dlls/wined3d/cs.c b/dlls/wined3d/cs.c > index 7af0b81..e71c873 100644 > --- a/dlls/wined3d/cs.c > +++ b/dlls/wined3d/cs.c > @@ -481,7 +481,7 @@ void wined3d_cs_emit_draw(struct wined3d_cs *cs, int base_vertex_idx, unsigned i > > op = cs->ops->require_space(cs, sizeof(*op)); > op->opcode = WINED3D_CS_OP_DRAW; > - op->base_vertex_idx = base_vertex_idx; > + op->base_vertex_idx = indexed ? base_vertex_idx : 0; > op->start_idx = start_idx; > op->index_count = index_count; > op->start_instance = start_instance; This should probably be a separate patch. Otherwise it seems good to me.

1 0

Re: [04/23] ntdll: Fix privileged instruction exception code.
by Matteo Bruni 13 Nov '16

13 Nov '16

2016-11-13 12:35 GMT-06:00 Andrew Wesie <awesie(a)gmail.com>: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index af16cfd..e2440a6 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2652,7 +2652,6 @@ static void segv_handler( int signal, siginfo_t *siginfo, void *sigcontext ) > WORD err = ERROR_sig(ucontext); > if ((err & 7) == 2 && handle_interrupt( err >> 3, rec, win_context )) break; > rec->ExceptionCode = err ? EXCEPTION_ACCESS_VIOLATION : EXCEPTION_PRIV_INSTRUCTION; > - rec->ExceptionCode = EXCEPTION_ACCESS_VIOLATION; The patch is most likely correct but it would be nice to have a Wine test triggering this codepath.

1 0

Re: [PATCH 5/7] ddraw: Discard the dst vertex buffer if possible.
by Henri Verbeet 13 Nov '16

13 Nov '16

On 30 October 2016 at 15:02, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Once we have buffer->buffer copies working we can load the source data > into a buffer in SetExecuteData and never have to lock the destination > buffer. In general I think wined3d_device_copy_sub_resource_region() is supposed to work for buffers. Is there something in particular that's broken?

2 1

Re: [PATCH] wininet: Resize buffer when call to InternetCanonicalizeUrlW fails in InternetCrackUrlW
by Marvin 13 Nov '16

13 Nov '16

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

2 1

Re: wineconsole: Correctly handle TrueType font widths
by Akihiro Sagawa 13 Nov '16

13 Nov '16

On Tue, 1 Nov 2016 11:59:30 +0000, Hugh McMaster wrote: > - config->cell_width = tm.tmMaxCharWidth; > + if (tm.tmPitchAndFamily & (TMPF_VECTOR | TMPF_TRUETYPE)) > + config->cell_width = tm.tmAveCharWidth; > + else > + config->cell_width = tm.tmMaxCharWidth; > + Hi Hugh, Why don't you use tmAveCharWidth value for raster (bitmap) fonts? Japanese fixed-pitch bitmap font, such as FixedSys (jvgafix.fon) or Terminal (not avaialble in wine), has a half value of tmMaxCharWidth for tmAveCharWidth. In other words, FixedSys shows tmAveCharWidth = 8, tmMaxCharWidth = 16. This works good in DBCS console window because full-width character (e.g. Kanji) occupies two cells. Thanks, Akihiro Sagawa

3 8

Re: d3drm: Avoid shift overflow when using RGBA_MAKE.
by Henri Verbeet 10 Nov '16

10 Nov '16

On 9 November 2016 at 14:09, Thomas Faber <thomas.faber(a)reactos.org> wrote: > This causes warnings on Arch Linux. > gcc (GCC) 6.2.1 20160830 > > In file included from ../../include/d3drmdef.h:25:0, > from ../../include/d3drmobj.h:25, > from ../../include/d3drm.h:27, > from d3drm_private.h:24, > from frame.c:30: > frame.c: In function ‘d3drm_frame3_SetSceneBackgroundRGB’: > ../../include/d3dtypes.h:56:51: error: result of ‘255 << 24’ requires 33 > bits to represent, but ‘int’ only has 32 bits [-Werror=shift-overflow=] > #define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | > ((g) << 8) | (b))) > ^ > frame.c:2007:30: note: in expansion of macro ‘RGBA_MAKE’ > frame->scenebackground = RGBA_MAKE((BYTE)(red * 255.0f), > ^~~~~~~~~ > frame.c: In function ‘d3drm_frame_create’: > ../../include/d3dtypes.h:56:51: error: result of ‘255 << 24’ requires 33 > bits to represent, but ‘int’ only has 32 bits [-Werror=shift-overflow=] > #define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | > ((g) << 8) | (b))) > ^ > frame.c:2952:31: note: in expansion of macro ‘RGBA_MAKE’ > object->scenebackground = RGBA_MAKE(0, 0, 0, 0xff); > ^~~~~~~~~ > cc1: all warnings being treated as errors > I've just sent a different patch (https://source.winehq.org/patches/data/127691), that hopefully also addresses this.

2 1

Re: [PATCH 3/3] dpnet: Implement IDirectPlay8Client Enumhost when called synchronously
by Marvin 10 Nov '16

10 Nov '16

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=26583 Your paranoid android. === w7u (32 bit client) === client.c:247: Test failed: got 0x80004005 client.c:247: Test failed: got 0x00000002 client.c:251: Test failed: got 0x80004005 client.c:251: Test failed: got 0x00000003

1 0

invalid wininet.h on the testbot?
by Donat Enikeev 09 Nov '16

09 Nov '16

Hi Guys, Seems testbot can't build tests depending on <wininet.h> I submitted a patch fixing crypt32/chain test failures on linux, and got errors like this: In file included from ../../../../wine/dlls/crypt32/tests/chain.c:28:0: ../../../../wine/include/wininet.h:1:1: error: stray ‘\35’ in program ../../../../wine/include/wininet.h:1:3: warning: null character(s) ignored [enabled by default] Job: https://testbot.winehq.org/JobDetails.pl?Key=26545&log_101=1#k101 The patch does nothing with <wininet.h>, it contains fresh cs.stanford.edu certificates chain, correspondent adjustments, and some broken() removals To confirm that I submitted dummy patch adding only /***/ in one line, and met same problem (job: https://testbot.winehq.org/JobDetails.pl?Key=26548) Best, Donnie

1 0

Re: [PATCH] dpnet: Implement IDirectPlay8Client EnumHosts
by Bruno Jesus 09 Nov '16

09 Nov '16

On Mon, Nov 7, 2016 at 6:24 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > This patch allows the dpnet examples and various games to find the > correct server running on the local network. (Server is either on > windows or using native directplay). Hi, thanks for the wonderful work. Can you share a few game titles (better with demo available) that can be used to test? > Feedback welcome. (Improvements, howto split the patch into smaller chunks). Some ideas below, this is not really a review as I don't understand some mechanics, it is more like a set of questions that may or may not help you. > Changes to CancelAsyncOperation have be obmitted, as it deserves a patch > of it's own. Currently no application tested seems to care if the operation > isn't cancelled. > > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dpnet/client.c | 399 ++++++++++++++++++++++++++++++++++++++++++++- > dlls/dpnet/dpnet_private.h | 25 +++ > dlls/dpnet/dppacket.h | 240 +++++++++++++++++++++++++++ > dlls/dpnet/tests/client.c | 81 ++++++++- > 4 files changed, 738 insertions(+), 7 deletions(-) > create mode 100644 dlls/dpnet/dppacket.h > > diff --git a/dlls/dpnet/client.c b/dlls/dpnet/client.c > index b92d940..1227be6 100644 > --- a/dlls/dpnet/client.c > +++ b/dlls/dpnet/client.c > @@ -29,10 +29,12 @@ > #include "wingdi.h" > #include "winuser.h" > #include "objbase.h" > +#include "ws2tcpip.h" > #include "wine/debug.h" > > #include "dplay8.h" > #include "dpnet_private.h" > +#include "dppacket.h" > > WINE_DEFAULT_DEBUG_CHANNEL(dpnet); > > @@ -92,6 +94,21 @@ static ULONG WINAPI IDirectPlay8ClientImpl_Release(IDirectPlay8Client *iface) > > if (!ref) > { > + struct async_tasks *cursor, *cursor2; > + > + SetEvent(This->closeevent); > + closesocket(This->sock); > + > + LIST_FOR_EACH_ENTRY_SAFE(cursor, cursor2, &This->tasks, struct async_tasks, entry) > + { > + IDirectPlay8Address_Release(cursor->device); > + list_remove(&cursor->entry); > + heap_free(cursor); > + } > + > + CloseHandle(This->datathread); > + CloseHandle(This->closeevent); > + > heap_free(This->username); > heap_free(This->data); > heap_free(This); > @@ -130,6 +147,263 @@ static HRESULT WINAPI IDirectPlay8ClientImpl_EnumServiceProviders(IDirectPlay8Cl > return DPN_OK; > } > > +static SOCKET find_free_socket(void) This function does more than finding a free socket, it also configures it as expected by directplay, what about "setup_socket"? > +{ > + SOCKET sock; > + struct sockaddr_in addr; > + int value; > + int port = 2302; > + ULONG l = 1; Where does this number 2302 comes from? A comment would be useful here, the ULONG variable deserves a better name, what about discarding the "value" variable and using only the ULONG in favor of it? There is a mandatory cast in setsockopt so it wouldn't be a problem. As a style choice I would group the int declarations in the same line. > + sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); > + if(sock == INVALID_SOCKET) > + { > + ERR("Cannot create socket.\n"); We all known this should never happen but since we have the ERR what about adding the WSAGetLastError() to it? > + return sock; > + } > + > + memset(&addr, 0, sizeof(addr)); > + addr.sin_family = AF_INET; > + addr.sin_port = htons(port); > + addr.sin_addr.s_addr = htonl(INADDR_ANY); > + > + value = 1; > + setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *)&value, sizeof(value)); > + ioctlsocket(sock, FIONBIO, &l); As commented above what about using the ULONG in both functions? Also, why not do this only after a successful bind? > + > + while(port < 2400) Yet another magic number, just add a comment stating this is the final checked port for directplay (if that is what this means). > + { > + if(!bind(sock, (struct sockaddr*)&addr, sizeof(addr))) > + { > + TRACE("bound to port (%d) successful.\n", port); > + return sock; > + } > + if(WSAGetLastError() == WSAEADDRINUSE) > + addr.sin_port = htons(++port); > + else > + break; > + } > + > + ERR("No free ports available.\n"); The previous TRACE call was not capitalized, both ERR calls have the first word capitalized, is it better to always start in uppercase or lowercase? This applies to the rest of the TRACE calls that are mixing upper/lowercase > + closesocket(sock); > + sock = INVALID_SOCKET; > + > + return sock; Maybe rewrite the socket() call check using a block or goto to use a single return point in the function? > +} > + > +struct dpthread_data > +{ > + SOCKET sock; > + DWORD bufsize; > + > + HANDLE event; > + PFNDPNMESSAGEHANDLER msghandler; > + > + struct list *tasks; > +}; > + > +static DWORD WINAPI data_thread(void *threaddata) > +{ > + struct dpthread_data *tdata = (struct dpthread_data *)threaddata; > + struct sockaddr_in addr; > + int addrlen; > + WORD payloadvalue = 0; > + char *buffer = heap_alloc(tdata->bufsize); Is it work to check the allocation? > + int buflen; > + int received; > + struct async_tasks *cursor; > + struct ENUM_QUERY query; > + > + /* This data doesn't change */ > + query.lead = 0x00; > + query.command = PACKET_ENUM_QUERY; > + query.type = PACKET_QUERY_GUID; > + > + TRACE("data thread start.\n"); > + > + while(TRUE) > + { > + if(list_count(tdata->tasks)) > + { > + LIST_FOR_EACH_ENTRY(cursor, tdata->tasks, struct async_tasks, entry) > + { > + if(cursor->retrycnt && (GetTickCount() - cursor->starttime) >= cursor->retrytime) > + { > + int err; > + > + TRACE("Sending Enum Query Request.\n"); Is it worth to also display the current retrycnt? > + > + query.payload = payloadvalue++; > + query.application = cursor->app_guid; > + > + addr.sin_family = AF_INET; > + addr.sin_port = htons(DPNA_DPNSVR_PORT); > + /* TODO - Support a single host */ > + addr.sin_addr.s_addr = INADDR_BROADCAST; > + > + err = sendto(tdata->sock, (void *)&query, sizeof(query), 0, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)); Double space after "0, ". > + if(err == -1) > + ERR("sendto failed (%d).\n", WSAGetLastError()); > + else > + TRACE("sent (%d).\n", err); This TRACE is not necessary since we already have a trace before and an ERR in case of problems. > + > + if(cursor->retrycnt != INFINITE) > + cursor->retrycnt--; > + > + cursor->starttime = GetTickCount(); > + } > + } > + > + /* Query Enumeration Packets */ > + buflen = tdata->bufsize; > + addrlen = sizeof(addr); > + received = recvfrom(tdata->sock, buffer, buflen, 0, (struct sockaddr *)&addr, &addrlen); > + if(received >= (int)sizeof(struct ENUM_HEADER)) There is no else to catch recvfrom errors, probably intentional since this is an UDP socket, right? > + { > + struct ENUM_HEADER *header = (struct ENUM_HEADER *)buffer; > + > + if(header->lead == 0) > + { > + /* Enum Query */ > + switch(header->command) > + { > + case PACKET_ENUM_QUERY: > + { > + TRACE("Ignoring EnumQuery Packet.\n"); > + break; > + } > + /* Enum response */ > + case PACKET_ENUM_RESPONSE: > + { > + DPNMSG_ENUM_HOSTS_RESPONSE response; > + DPN_APPLICATION_DESC desc; > + struct ENUM_QUERY_RESPONSE *data = (struct ENUM_QUERY_RESPONSE *)header; > + IDirectPlay8Address *sender = NULL; > + char ip[INET6_ADDRSTRLEN] = {0}; Is it possible to be really an IPv6? > + int port; > + HRESULT ret; > + > + TRACE("PACKET_ENUM_RESPONSE.\n"); > + > + if(received <= sizeof(struct ENUM_QUERY_RESPONSE)) > + { > + ERR("May not have received enough data.\n"); > + SetEvent(tdata->event); > + break; Is the <= intentional? In my imagination it would be correct to receive == sizeof(struct). This should only happen due to game bugs, right? > + } > + > + memset(&response, 0, sizeof(DPNMSG_ENUM_HOSTS_RESPONSE)); > + memset(&desc, 0, sizeof(DPN_APPLICATION_DESC)); > + > + response.dwSize = sizeof(DPNMSG_ENUM_HOSTS_RESPONSE); > + > + ret = DPN_OK; > + > + LIST_FOR_EACH_ENTRY(cursor, tdata->tasks, struct async_tasks, entry) This is the very same loop in the beginning of the function, what are these tasks and why do we need to run through all of them while inside the outer loop on the same struct? > + { > + if(IsEqualGUID(&cursor->app_guid, &data->application) || > + IsEqualGUID(&cursor->app_guid, &IID_NULL)) /* all applications */ > + { Just a style preference, why not invert the if condition to reduce the code indentation? > + /* > + * We need to create an Address Object with the Port and IP address. > + * Applications are required to AddRef this object if they want to keep a reference. > + */ > + ret = DPNET_CreateDirectPlay8Address(NULL, NULL, &IID_IDirectPlay8Address, (void**)&sender); > + if(FAILED(ret)) > + break; > + > + inet_ntop(addr.sin_family, &addr.sin_addr, ip, sizeof(ip)); > + port = ntohs(addr.sin_port); > + TRACE("Server IP address %s:%d\n", ip, port); > + > + if(FAILED(IDirectPlay8Address_AddComponent(sender, DPNA_KEY_HOSTNAME, &ip, strlen(ip)+1, DPNA_DATATYPE_STRING_ANSI))) > + { > + ERR("Failed to add DPNA_KEY_HOSTNAME\n"); > + IDirectPlay8Address_Release(sender); > + SetEvent(tdata->event); > + break; If CreateDirectPlay8Address fails you are not calling SetEvent, is that intentional? Because if IDirectPlay8Address_AddComponent fails you call SetEvent. > + } > + if(FAILED(IDirectPlay8Address_AddComponent(sender, DPNA_KEY_PORT, &port, sizeof(DWORD), DPNA_DATATYPE_DWORD))) > + { > + ERR("Failed to add DPNA_KEY_PORT\n"); > + IDirectPlay8Address_Release(sender); > + SetEvent(tdata->event); > + break; > + } > + > + response.pAddressSender = sender; > + response.pApplicationDescription = &desc; > + response.pAddressDevice = cursor->device; > + > + desc.guidInstance = data->instance; > + desc.guidApplication = data->application; > + desc.dwCurrentPlayers = data->current_players; > + desc.dwMaxPlayers = data->max_players; > + > + if(data->session_offset && data->session_offset < received) > + desc.pwszSessionName = (WCHAR*)(((char*)data)+data->session_offset+sizeof(struct ENUM_HEADER)); > + > + if(tdata->msghandler) > + ret = tdata->msghandler(NULL, DPN_MSGID_ENUM_HOSTS_RESPONSE, &response); If all the above was only made if a msghandler is present can you simply ignore all data received when msghandler is not present? > + > + IDirectPlay8Address_Release(sender); > + > + if(cursor->retrycnt != INFINITE) > + cursor->retrycnt = 0; > + > + /* If a userhandler function returns anything other than DPN_OK we need to stop. */ > + if(ret != DPN_OK) > + break; > + } > + } > + > + if(ret != DPN_OK) > + SetEvent(tdata->event); Why can't you SetEvent inside the previous ret != DPN_OK since it is breaking the inner loop anyway? > + > + break; > + } > + default: > + { > + FIXME("Unsupported query command 0x%08x.\n", header->command); > + } > + } > + } > + else > + { > + struct DFRAME_PACKET *dframe = (struct DFRAME_PACKET *)buffer; > + FIXME("DFRAME received - command 0x%08x, control 0x%08x.\n", dframe->command, dframe->control); > + } > + } > + > + LIST_FOR_EACH_ENTRY(cursor, tdata->tasks, struct async_tasks, entry) > + { > + if(!cursor->retrycnt && (GetTickCount() - cursor->starttime) >= cursor->timeout) > + { > + list_remove( &cursor->entry ); > + IDirectPlay8Address_Release(cursor->device); > + if(cursor->aysncmutex) > + { > + TRACE("Removing async event\n"); > + SetEvent(cursor->aysncmutex); > + } > + /* TODO - Send DPN_MSGID_ASYNC_OP_COMPLETE if not ASYNC */ > + heap_free(cursor); > + } > + } > + } > + > + if(WaitForSingleObject(tdata->event, 500) != WAIT_TIMEOUT) > + { > + TRACE("Event Signaled.\n"); > + break; > + } > + } > + > + heap_free(buffer); > + > + return 0; > +} > + > static HRESULT WINAPI IDirectPlay8ClientImpl_EnumHosts(IDirectPlay8Client *iface, > PDPN_APPLICATION_DESC const pApplicationDesc, IDirectPlay8Address * const pAddrHost, > IDirectPlay8Address * const pDeviceInfo, void * const pUserEnumData, > @@ -137,9 +411,111 @@ static HRESULT WINAPI IDirectPlay8ClientImpl_EnumHosts(IDirectPlay8Client *iface > const DWORD dwTimeOut, void * const pvUserContext, DPNHANDLE * const pAsyncHandle, > const DWORD dwFlags) > { > - IDirectPlay8ClientImpl *This = impl_from_IDirectPlay8Client(iface); > - FIXME("(%p):(%p,%p,%x): Stub\n", This, pvUserContext, pAsyncHandle, dwFlags); > - return DPN_OK; > + IDirectPlay8ClientImpl *This = impl_from_IDirectPlay8Client(iface); > + HRESULT hr; > + HANDLE async_mutex = NULL; > + struct async_tasks *task; > + > + TRACE("(%p):(%p,%p,%p,%p,%u,%u,%u,%u,%p,%p,%x)\n", This, pApplicationDesc, pAddrHost, pDeviceInfo, pUserEnumData, > + dwUserEnumDataSize, dwEnumCount, dwRetryInterval, dwTimeOut, pvUserContext, pAsyncHandle, dwFlags); > + > + if(!This->msghandler) > + return DPNERR_UNINITIALIZED; > + > + if(dwFlags & DPNENUMHOSTS_SYNC) > + { > + if(pAsyncHandle) > + return DPNERR_INVALIDPARAM; > + > + FIXME("Flag DPNENUMHOSTS_SYNC currently not supported (%u, %u, %u).\n", dwEnumCount, dwRetryInterval, dwTimeOut); > + } > + > + if(dwUserEnumDataSize > This->spcaps.dwMaxEnumPayloadSize) > + return DPNERR_ENUMQUERYTOOLARGE; > + > + if(This->sock == INVALID_SOCKET) > + { > + This->sock = find_free_socket(); > + if(This->sock == INVALID_SOCKET) > + return DPNERR_USERCANCEL; /* Pretend the user cancalled this operation. */ > + } > + > + if(!This->closeevent) > + { > + This->closeevent = CreateEventA( NULL, TRUE, FALSE, NULL); > + if(!This->closeevent) > + { > + WARN("Failed to create Event\n"); > + closesocket(This->sock); > + This->sock = INVALID_SOCKET; > + return DPNERR_GENERIC; > + } > + } > + > + task = heap_alloc(sizeof(struct async_tasks)); > + if(!task) > + { > + closesocket(This->sock); > + This->sock = INVALID_SOCKET; > + return E_OUTOFMEMORY; Shoud you destroy the closeevent too? > + } > + > + task->handle = PtrToUlong(task); > + task->type = enumhost; > + task->app_guid = pApplicationDesc->guidApplication; > + task->starttime = 0; > + task->retrycnt = !dwEnumCount ? This->spcaps.dwDefaultEnumCount : dwEnumCount; > + task->retrytime = dwRetryInterval == INFINITE ? This->spcaps.dwDefaultEnumRetryInterval : dwRetryInterval; > + task->timeout = dwTimeOut == 0 ? This->spcaps.dwDefaultEnumTimeout : dwTimeOut; !dwEnumCount but dwTimeout == 0, style inconsistency? > + if(dwFlags & DPNENUMHOSTS_SYNC) > + async_mutex = CreateMutexA(NULL, FALSE, NULL); > + > + task->aysncmutex = async_mutex; > + hr = IDirectPlay8Address_Duplicate(pDeviceInfo, &task->device); > + if(FAILED(hr)) > + { > + ERR("Failed to duplicate Device address (0x%08x).\n", hr); > + > + closesocket(This->sock); > + This->sock = INVALID_SOCKET; > + heap_free(task); > + > + return E_OUTOFMEMORY; Free closeevent? Free async_mutex? > + } > + > + list_add_tail(&This->tasks, &task->entry); > + > + if(!This->datathread) > + { > + struct dpthread_data *tdata = heap_alloc(sizeof(struct dpthread_data)); > + if(!tdata) > + { > + closesocket(This->sock); > + This->sock = INVALID_SOCKET; > + > + list_remove( &task->entry ); > + IDirectPlay8Address_Release(task->device); > + heap_free(task); > + > + return E_OUTOFMEMORY; > + } > + > + tdata->sock = This->sock; > + tdata->bufsize = This->spcaps.dwSystemBufferSize; > + tdata->msghandler = This->msghandler; > + tdata->event = This->closeevent; > + tdata->tasks = &This->tasks; > + > + This->datathread = CreateThread(NULL, 0, &data_thread, tdata, 0, 0); > + } > + > + if(async_mutex) > + WaitForSingleObject(async_mutex,INFINITE); > + > + if(pAsyncHandle) > + *pAsyncHandle = task->handle; > + > + return (dwFlags & DPNENUMHOSTS_SYNC) ? DPN_OK : DPNSUCCESS_PENDING; > } > > static HRESULT WINAPI IDirectPlay8ClientImpl_CancelAsyncOperation(IDirectPlay8Client *iface, > @@ -256,8 +632,23 @@ static HRESULT WINAPI IDirectPlay8ClientImpl_GetServerAddress(IDirectPlay8Client > static HRESULT WINAPI IDirectPlay8ClientImpl_Close(IDirectPlay8Client *iface, const DWORD dwFlags) > { > IDirectPlay8ClientImpl *This = impl_from_IDirectPlay8Client(iface); > + struct async_tasks *cursor, *cursor2; > FIXME("(%p):(%x): Stub\n", This, dwFlags); > > + SetEvent(This->closeevent); > + > + LIST_FOR_EACH_ENTRY_SAFE(cursor, cursor2, &This->tasks, struct async_tasks, entry) > + { > + IDirectPlay8Address_Release(cursor->device); > + list_remove(&cursor->entry); > + heap_free(cursor); > + } > + > + CloseHandle(This->datathread); > + This->datathread = NULL; > + CloseHandle(This->closeevent); > + This->closeevent = NULL; > + > This->msghandler = NULL; > > return DPN_OK; > @@ -376,6 +767,8 @@ HRESULT DPNET_CreateDirectPlay8Client(IClassFactory *iface, IUnknown *pUnkOuter, > > client->IDirectPlay8Client_iface.lpVtbl = &DirectPlay8Client_Vtbl; > client->ref = 1; > + client->sock = INVALID_SOCKET; > + list_init(&client->tasks); > > init_dpn_sp_caps(&client->spcaps); > > diff --git a/dlls/dpnet/dpnet_private.h b/dlls/dpnet/dpnet_private.h > index 89e0777..763b1c2 100644 > --- a/dlls/dpnet/dpnet_private.h > +++ b/dlls/dpnet/dpnet_private.h > @@ -41,6 +41,26 @@ typedef struct IDirectPlay8AddressImpl IDirectPlay8AddressImpl; > typedef struct IDirectPlay8LobbiedApplicationImpl IDirectPlay8LobbiedApplicationImpl; > typedef struct IDirectPlay8ThreadPoolImpl IDirectPlay8ThreadPoolImpl; > > +enum async_type { enumhost, connection, sendmsg }; > + > +struct async_tasks > +{ > + DPNHANDLE handle; > + BYTE type; > + > + IDirectPlay8Address *device; > + > + PFNDPNMESSAGEHANDLER msghandler; > + GUID app_guid; > + DWORD starttime; > + DWORD retrycnt; > + DWORD retrytime; > + DWORD timeout; > + HANDLE aysncmutex; > + > + struct list entry; > +}; > + > /* ------------------ */ > /* IDirectPlay8Client */ > /* ------------------ */ > @@ -62,6 +82,11 @@ struct IDirectPlay8ClientImpl > DWORD datasize; > > DPN_SP_CAPS spcaps; > + > + SOCKET sock; > + HANDLE closeevent; > + HANDLE datathread; > + struct list tasks; > }; > > /* ------------------- */ > diff --git a/dlls/dpnet/dppacket.h b/dlls/dpnet/dppacket.h > new file mode 100644 > index 0000000..297640a > --- /dev/null > +++ b/dlls/dpnet/dppacket.h > @@ -0,0 +1,240 @@ > +/* > + * dpnet packet structures > + * > + * Copyright 2016 Alistair Leslie-Hughes > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > +#ifndef __WINE_DPNET_PACKET_H > +#define __WINE_DPNET_PACKET_H > + > +#include <pshpack1.h> > + > +struct ENUM_HEADER > +{ > + BYTE lead; > + BYTE command; > + WORD payload; > +}; > + > +struct ENUM_QUERY > +{ > + BYTE lead; > + BYTE command; > + WORD payload; > + BYTE type; > + GUID application; > +}; > + > +struct ENUM_QUERY_RESPONSE > +{ > + BYTE lead; > + BYTE command; > + WORD payload; > + DWORD reply_offset; > + DWORD response_size; > + DWORD desc_size; > + DWORD desc_flags; > + DWORD max_players; > + DWORD current_players; > + DWORD session_offset; > + DWORD session_size; > + DWORD Password_offset; > + DWORD Password_size; > + DWORD reserved_offset; > + DWORD reserved_size; > + DWORD application_offset; > + DWORD application_size; > + GUID instance; > + GUID application; > +}; This file seems to be private, so can we have all struct attributes starting in lowercase? > + > +struct DFRAME_PACKET > +{ > + BYTE command; > + BYTE control; > + BYTE seq; > + BYTE nseq; > +}; > + > +/* 2.2.1.8 DN_ACK_CONNECT_INFO */ > +struct DN_ACK_CONNECT_INFO > +{ > + DWORD type; > +}; > + > +struct DFRAME_PACKET_KEEPALIVE > +{ > + BYTE command; > + BYTE control; > + BYTE seq; > + BYTE nseq; > + DWORD session; > +}; > + > +struct DN_MESSAGE_CONNECT > +{ > + BYTE command; > + BYTE opcode; > + BYTE msgid; > + BYTE rspid; > + DWORD protocol; > + DWORD session; > + DWORD timestamp; > +}; > + > + > +struct SACK_PACKET > +{ > + BYTE command; > + BYTE opcode; > + BYTE flags; > + BYTE retry; > + BYTE nseq; > + BYTE nrcv; > + WORD padding; > + DWORD timestamp; > +}; > + > +/* 2.2.1.1 DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO */ > +struct DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO > +{ > + DWORD type; > + DWORD flags; > + DWORD version; > + DWORD name_offset; > + DWORD name_size; > + DWORD data_offset; > + DWORD data_size; > + DWORD pwd_offset; > + DWORD pwd_size; > + DWORD connect_offset; > + DWORD connect_size; > + DWORD url_offset; > + DWORD url_size; > + GUID instance; > + GUID application; > +}; > + > +struct DN_INTERNAL_MESSAGE_PLAYER_CONNECT_INFO_EX > +{ > + DWORD type; > + DWORD flags; > + DWORD version; > + DWORD name_offset; > + DWORD name_size; > + DWORD data_offset; > + DWORD data_size; > + DWORD pwd_offset; > + DWORD pwd_size; > + DWORD connect_offset; > + DWORD connect_size; > + DWORD url_offset; > + DWORD url_size; > + GUID instance; > + GUID application; > + DWORD alt_address_offset; > + DWORD alt_address_size; > +}; > + > +/* 2.2.1.4 DN_SEND_CONNECT_INFO */ > +struct DN_SEND_CONNECT_INFO > +{ > + DWORD type; /* DN_MSG_INTERNAL_SEND_CONNECT_INFO */ > + DWORD reply_offset; > + DWORD reply_size; > + DWORD size; > + DWORD flags; > + DWORD max_players; > + DWORD cur_players; > + DWORD session_offset; > + DWORD session_size; > + DWORD password_offset; > + DWORD password_size; > + DWORD reserved_offset; > + DWORD reserved_size; > + DWORD appdata_offset; > + DWORD appdata_size; > + GUID instance; > + GUID application; > + DWORD dpnid; > + DWORD version; > + DWORD ver_not_used; > + DWORD entry_count; > + DWORD membership_count; > +}; > + > +#define PACKET_ENUM_QUERY 0x02 > +#define PACKET_ENUM_RESPONSE 0x03 > + > +#define PACKET_QUERY_GUID 0x01 > +#define PACKET_QUERY_NO_GUID 0x02 > + > +#define APPLICATIONDESCSIZE 0x00000050 > + > +#define PACKET_COMMAND_DATA 0x01 > +#define PACKET_COMMAND_RELIABLE 0x02 > +#define PACKET_COMMAND_SEQUENTIAL 0x04 > +#define PACKET_COMMAND_POLL 0x08 > +#define PACKET_COMMAND_NEW_MSG 0x10 > +#define PACKET_COMMAND_END_MSG 0x20 > +#define PACKET_COMMAND_USER_1 0x40 > +#define PACKET_COMMAND_USER_2 0x80 > +#define PACKET_COMMAND_CFRAME PACKET_COMMAND_USER_2 > + > +#define PACKET_CONTROL_RETRY 0x01 > +#define PACKET_CONTROL_KEEPALIVE_OR_CORRELATE 0x02 > +#define PACKET_CONTROL_COALESCE 0x04 > +#define PACKET_CONTROL_END_STREAM 0x08 > +#define PACKET_CONTROL_SACK1 0x10 > +#define PACKET_CONTROL_SACK2 0x20 > +#define PACKET_CONTROL_SEND1 0x40 > +#define PACKET_CONTROL_SEND2 0x80 > + > +#define PROTOCOL_VERSION 0x00010006 > + > +#define FRAME_EXOPCODE_CONNECT 0x01 > +#define FRAME_EXOPCODE_CONNECTED 0x02 > +#define FRAME_EXOPCODE_CONNECTED_SIGNED 0x03 > +#define FRAME_EXOPCODE_HARD_DISCONNECT 0x04 > +#define FRAME_EXOPCODE_SACK 0x06 > + > +#define PACKET_SIGNING_FAST 0x00000001 > +#define PACKET_SIGNING_FULL 0x00000002 > + > +#define SACK_FLAGS_RESPONSE 0x01 > +#define SACK_FLAGS_SACK_MASK1 0x02 > +#define SACK_FLAGS_SACK_MASK2 0x04 > +#define SACK_FLAGS_SEND_MASK1 0x08 > +#define SACK_FLAGS_SEND_MASK2 0x10 > + > +#define DN_MSG_INTERNAL_PLAYER_CONNECT_INFO 0x000000C1 > +#define DN_MSG_INTERNAL_SEND_CONNECT_INFO 0x000000C2 > +#define DN_MSG_INTERNAL_ACK_CONNECT_INFO 0x000000C3 > + > +#define DP_OBECT_TYPE_CLIENT 0x00000002 > +#define DP_OBECT_TYPE_PEER 0x00000004 > + > +#define DP_OBECT_NET_VER_8_0 0x00000001 > +#define DP_OBECT_NET_VER_8_1 0x00000002 > +#define DP_OBECT_NET_VER_POCKETPC 0x00000003 > +#define DP_OBECT_NET_VER_W2K3 0x00000005 > +#define DP_OBECT_NET_VER_8_2 0x00000006 > +#define DP_OBECT_NET_VER_9_0 0x00000007 > +#define DP_OBECT_NET_VER_9_0A 0x00000008 This file seems to be adding way more stuff than you are using currently, is it better to add as things are developed? > +#include "poppack.h" > + > +#endif > diff --git a/dlls/dpnet/tests/client.c b/dlls/dpnet/tests/client.c > index 4753d74..608f0e5 100644 > --- a/dlls/dpnet/tests/client.c > +++ b/dlls/dpnet/tests/client.c > @@ -29,9 +29,29 @@ static IDirectPlay8Client* client = NULL; > static IDirectPlay8LobbiedApplication* lobbied = NULL; > static const GUID appguid = { 0xcd0c3d4b, 0xe15e, 0x4cf2, { 0x9e, 0xa8, 0x6e, 0x1d, 0x65, 0x48, 0xc5, 0xa5 } }; > > +static HRESULT lastAsyncCode = E_FAIL; > +static DPNHANDLE lastAsyncHandle = 0; > + > +#define CHECK_LAST_ASYNC_OP(hr, handle) \ > + ok(lastAsyncCode == hr, "got 0x%08x\n", lastAsyncCode); \ > + ok(lastAsyncHandle == handle, "got 0x%08x\n", handle); \ > + lastAsyncCode = E_FAIL; lastAsyncHandle = 0; > + > static HRESULT WINAPI DirectPlayMessageHandler(PVOID context, DWORD message_id, PVOID buffer) > { > - trace("DirectPlayMessageHandler: 0x%08x\n", message_id); > + switch(message_id) > + { > + case DPN_MSGID_ASYNC_OP_COMPLETE: > + { > + PDPNMSG_ASYNC_OP_COMPLETE async_msg = (PDPNMSG_ASYNC_OP_COMPLETE)buffer; > + lastAsyncCode = async_msg->hResultCode; > + lastAsyncHandle = async_msg->hAsyncOp; > + break; > + } > + default: > + trace("DirectPlayMessageHandler: 0x%08x\n", message_id); > + > + } > return S_OK; > } > > @@ -144,16 +164,22 @@ static void test_enum_service_providers(void) > static void test_enum_hosts(void) > { > HRESULT hr; > + IDirectPlay8Client *client2; > IDirectPlay8Address *host = NULL; > IDirectPlay8Address *local = NULL; > DPN_APPLICATION_DESC appdesc; > - DPNHANDLE async = 0; > + DPNHANDLE async = 0, async2 = 0; > static const WCHAR localhost[] = {'1','2','7','.','0','.','0','.','1',0}; > + DPN_SP_CAPS caps; > + char *data; > > memset( &appdesc, 0, sizeof(DPN_APPLICATION_DESC) ); > appdesc.dwSize = sizeof( DPN_APPLICATION_DESC ); > appdesc.guidApplication = appguid; > > + hr = CoCreateInstance(&CLSID_DirectPlay8Client, NULL, CLSCTX_INPROC_SERVER, &IID_IDirectPlay8Client, (void **)&client2); > + ok(hr == S_OK, "CoCreateInstance failed with 0x%x\n", hr); > + > hr = CoCreateInstance( &CLSID_DirectPlay8Address, NULL, CLSCTX_ALL, &IID_IDirectPlay8Address, (LPVOID*)&local); > ok(hr == S_OK, "IDirectPlay8Address failed with 0x%08x\n", hr); > > @@ -170,16 +196,63 @@ static void test_enum_hosts(void) > DPNA_DATATYPE_STRING); > ok(hr == S_OK, "IDirectPlay8Address failed with 0x%08x\n", hr); > > + caps.dwSize = sizeof(DPN_SP_CAPS); > + > + hr = IDirectPlay8Client_GetSPCaps(client, &CLSID_DP8SP_TCPIP, &caps, 0); > + ok(hr == DPN_OK, "got %x\n", hr); > + data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, caps.dwMaxEnumPayloadSize + 1); > + > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, NULL, 0, 2, 1000, 1000, NULL, &async, DPNENUMHOSTS_SYNC); > + ok(hr == DPNERR_INVALIDPARAM, "got 0x%08x\n", hr); > + > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, data, caps.dwMaxEnumPayloadSize + 1, > + INFINITE, 0, INFINITE, NULL, &async, DPNENUMHOSTS_SYNC); > + ok(hr == DPNERR_INVALIDPARAM, "got 0x%08x\n", hr); > + > + async = 0; > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, data, caps.dwMaxEnumPayloadSize + 1, INFINITE, 0, > + INFINITE, NULL, &async, 0); > + ok(hr == DPNERR_ENUMQUERYTOOLARGE, "got 0x%08x\n", hr); > + ok(!async, "Handle returned\n"); > + > + async = 0; > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, data, caps.dwMaxEnumPayloadSize, INFINITE, 0, INFINITE, > + NULL, &async, 0); > + ok(hr == DPNSUCCESS_PENDING, "got 0x%08x\n", hr); > + ok(async, "No Handle returned\n"); > + > + /* This CancelAsyncOperation doesn't generate a DPN_MSGID_ASYNC_OP_COMPLETE */ > + hr = IDirectPlay8Client_CancelAsyncOperation(client, async, 0); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + HeapFree(GetProcessHeap(), 0, data); > + > + /* No Initialize has been called on client2. */ > + hr = IDirectPlay8Client_EnumHosts(client2, &appdesc, host, local, NULL, 0, INFINITE, 0, INFINITE, NULL, &async, 0); > + ok(hr == DPNERR_UNINITIALIZED, "IDirectPlay8Client_EnumHosts failed with 0x%08x\n", hr); > + > /* Since we are running asynchronously, EnumHosts returns DPNSUCCESS_PENDING. */ > hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, NULL, 0, INFINITE, 0, INFINITE, NULL, &async, 0); > - todo_wine ok(hr == DPNSUCCESS_PENDING, "IDirectPlay8Client_EnumServiceProviders failed with 0x%08x\n", hr); > - todo_wine ok(async, "No Handle returned\n"); > + ok(hr == DPNSUCCESS_PENDING, "IDirectPlay8Client_EnumHosts failed with 0x%08x\n", hr); > + ok(async, "No Handle returned\n"); > + > + hr = IDirectPlay8Client_EnumHosts(client, &appdesc, host, local, NULL, 0, INFINITE, 0, INFINITE, NULL, &async2, 0); > + ok(hr == DPNSUCCESS_PENDING, "IDirectPlay8Client_EnumHosts failed with 0x%08x\n", hr); > + ok(async2, "No Handle returned\n"); > + ok(async2 != async, "Same handle returned.\n"); > + > + Sleep(500); > > hr = IDirectPlay8Client_CancelAsyncOperation(client, async, 0); > ok(hr == S_OK, "IDirectPlay8Client_CancelAsyncOperation failed with 0x%08x\n", hr); > + todo_wine { CHECK_LAST_ASYNC_OP(DPNERR_USERCANCEL, async); } > + > + hr = IDirectPlay8Client_CancelAsyncOperation(client, async2, 0); > + ok(hr == S_OK, "IDirectPlay8Client_CancelAsyncOperation failed with 0x%08x\n", hr); > + todo_wine { CHECK_LAST_ASYNC_OP(DPNERR_USERCANCEL, async2); } > > IDirectPlay8Address_Release(local); > IDirectPlay8Address_Release(host); > + IDirectPlay8Client_Release(client2); > } > > static void test_get_sp_caps(void) > -- > 1.9.1 > > >

1 0

Re: [PATCH] winex11.drv: import X11's "text/html" as "HTML Format" (try 2)
by Alexandre Julliard 08 Nov '16

08 Nov '16

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > + hClipData = GlobalAlloc(GMEM_MOVEABLE | GMEM_DDESHARE, clipDataSize); > + if (hClipData) > + { > + char *htmlFormat = GlobalLock(hClipData); > + snprintf(htmlFormat, clipDataSize, "%s%s%s%s", description, startFragment, textHtml, endFragment); > + TRACE("incoming \"HTML Format\" with these contents:\n%s\n", htmlFormat); > + GlobalUnlock(hClipData); > + } This should be GMEM_FIXED now. Please check how it's done in other functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] user32: Check for PeekMessage failure in MENU_SuspendPopup.
by Alexandre Julliard 08 Nov '16

08 Nov '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=41508 > > The entire MENU_SuspendPopup function is just an optimization to try to > improve performance if the left or right arrow key is held down. If the > next message is not recognized, it should be processed and removed > normally, without optimization. Probably what you want is to add handling of WM_SYSKEYDOWN instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] d2d1/tests: Some tests for GetRect() and GetRoundedRect()
by Henri Verbeet 08 Nov '16

08 Nov '16

On 8 November 2016 at 15:05, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d2d1/tests/d2d1.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 88 insertions(+), 1 deletion(-) > This could probably be split into two patches, although I don't feel too strongly about it. > + set_rect(&rect, 0.0f, 0.0f, 0.0f, 0.0f); > + hr = ID2D1Factory_CreateRectangleGeometry(factory, &rect, &geometry); > + ok(SUCCEEDED(hr), "Failed to create geometry, hr %#x.\n", hr); > + ID2D1RectangleGeometry_GetRect(geometry, &rect2); > + ok(!memcmp(&rect, &rect2, sizeof(rect)), "Got wrong rectangle.\n"); We tend to go with "unexpected" instead of "wrong", although that's just fwiw. I do think it would be helpful to print the contents of "rect2" here when the test fails.

1 0

Re: [PATCH 4/5] wined3d: Use unsynchronized buffer updates only if there has been at least one buffer map.
by Henri Verbeet 08 Nov '16

08 Nov '16

On 4 November 2016 at 13:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Fixes bc019fcbbd7f0014280a292bc58ef618cfbe34c7. We cannot use > unsynchronized updates when the application haven't called map at all. > Mostly out of curiosity, how is this triggered in practice? Also, would it make sense to track synchronised/unsynchronised in buffer_invalidate_bo_range() instead?

2 2

Re: [PATCH 3/5] d3d10core/tests: Fix test failures in test_render_target_views().
by Henri Verbeet 08 Nov '16

08 Nov '16

On 8 November 2016 at 12:11, Józef Kucia <jkucia(a)codeweavers.com> wrote: > The initial texture data is not necessarily initialized to 0. > That's different from at least d3d9. It probably also implies we can skip clearing the initial texture contents for d3d10+.

1 0

Re: [PATCH 5/5] d3d8/tests: Accept broken behavior for lost device tests.
by Marvin 08 Nov '16

08 Nov '16

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=26524 Your paranoid android. === w8 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480.

1 0

Re: [v2 PATCH] user32/msgbox: Support WM_COPY Message
by Nikolay Sivov 08 Nov '16

08 Nov '16

On 08.11.2016 13:44, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=17205 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/user32/msgbox.c | 86 +++++++++++++++++++-- > dlls/user32/tests/dialog.c | 187 ++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 267 insertions(+), 6 deletions(-) > > diff --git a/dlls/user32/msgbox.c b/dlls/user32/msgbox.c > index 2ba98c9..4735b8a 100644 > --- a/dlls/user32/msgbox.c > +++ b/dlls/user32/msgbox.c > @@ -44,6 +44,11 @@ struct ThreadWindows > HWND *handles; > }; > > +/* Index the order the buttons need to appear to an ID* constant */ > +static const int buttonOrder[10] = { IDYES, IDNO, IDOK, IDABORT, IDRETRY, > + IDCANCEL, IDIGNORE, IDTRYAGAIN, > + IDCONTINUE, IDHELP }; > + > static BOOL CALLBACK MSGBOX_EnumProc(HWND hwnd, LPARAM lParam) > { > struct ThreadWindows *threadWindows = (struct ThreadWindows *)lParam; > @@ -77,11 +82,6 @@ static void MSGBOX_OnInit(HWND hwnd, LPMSGBOXPARAMSW lpmb) > WCHAR *buffer = NULL; > const WCHAR *ptr; > > - /* Index the order the buttons need to appear to an ID* constant */ > - static const int buttonOrder[10] = { IDYES, IDNO, IDOK, IDABORT, IDRETRY, > - IDCANCEL, IDIGNORE, IDTRYAGAIN, > - IDCONTINUE, IDHELP }; > - > nclm.cbSize = sizeof(nclm); > SystemParametersInfoW (SPI_GETNONCLIENTMETRICS, 0, &nclm, 0); > > @@ -319,6 +319,77 @@ static void MSGBOX_OnInit(HWND hwnd, LPMSGBOXPARAMSW lpmb) > HeapFree( GetProcessHeap(), 0, buffer ); > } > > +static void MSGBOX_CopyToClipboard( HWND hwnd ) > +{ > + int i; > + static const WCHAR line[] = {'-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-', > + '-','-','-','-','-','-','-','-','\r','\n', 0}; > + static const WCHAR crlf[] = {'\r','\n', 0}; > + static const WCHAR spaces[] = {' ',' ',' ', 0}; > + int lenTitle = GetWindowTextLengthW(hwnd) + 1; > + int lenMsg = GetWindowTextLengthW(GetDlgItem(hwnd, MSGBOX_IDTEXT)) + 1; > + > + /* > + --------------------------- > + Dialog Title > + --------------------------- > + Dialog Message > + --------------------------- > + Button(s) Text. OK > + --------------------------- > + */ > + int len = ((sizeof(crlf) * 3) + (sizeof(line) * 4) + lenTitle + lenMsg) * sizeof(WCHAR); This will allocate more than you need. > + WCHAR *text = HeapAlloc( GetProcessHeap(), 0, len); Maybe return right here if allocation failed? Also please use consistent formatting regarding spaces. > + if(text) > + { > + lstrcpyW(text, line); > + if (GetWindowTextW(hwnd, text + lstrlenW(text), lenTitle)) > + { > + HGLOBAL hMem; > + WCHAR *data; > + > + lstrcatW(text, crlf); > + lstrcatW(text, line); > + GetWindowTextW(GetDlgItem(hwnd, MSGBOX_IDTEXT), text + lstrlenW(text), lenMsg); There is GetDlgItemText() for that. > + lstrcatW(text, crlf); > + lstrcatW(text, line); > + > + for (i = 0; i < (sizeof(buttonOrder) / sizeof(buttonOrder[0])); i++) > + { > + HWND hItem = GetDlgItem(hwnd, buttonOrder[i]); > + if (GetWindowLongW(hItem, GWL_STYLE) & WS_VISIBLE) > + { Does IsWindowVisible() work here? > + WCHAR buffer[1024] = {0}; This looks excessive for a button text string. > > case WM_COMMAND: > switch (LOWORD(wParam)) > diff --git a/dlls/user32/tests/dialog.c b/dlls/user32/tests/dialog.c > index a37c678..0bb7dca 100644 > --- a/dlls/user32/tests/dialog.c > +++ b/dlls/user32/tests/dialog.c > @@ -40,6 +40,7 @@ > #include "winbase.h" > #include "wingdi.h" > #include "winuser.h" > +#include "winnls.h" > > #define MAXHWNDS 1024 > static HWND hwnd [MAXHWNDS]; > @@ -1392,6 +1393,187 @@ static void test_MessageBoxFontTest(void) > DestroyWindow(hDlg); > } > > +static const char msgbox_title[] = "%5!z9ZXw*ia;57n/FGl.bCH,Su\"mfKN;foCqAU\'j6AmoJgAc_D:Z0A\'E6PF_O/w"; What's the idea behind such title? If you're trying to create a unique window title, I don't think it has to be that unique. > +static WCHAR expectedOK[] = > +{ > +'-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','\r','\n', > +'%','5','!','z','9','Z','X','w','*','i','a',';','5','7','n','/','F','G','l','.','b','C','H',',','S','u','"','m','f', > +'K','N',';','f','o','C','q','A','U','\'','j','6','A','m','o','J','g','A','c','_','D',':','Z','0','A','\'','E','6','P', > +'F','_','O','/','w','\r','\n', > +'-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','\r','\n', > +'M','e','s','s','a','g','e','\r','\n', > +'-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','\r','\n', > +'O','K',' ',' ',' ','\r','\n', > +'-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','-','\r','\n', 0 > +}; Instead of expected strings you can as well duplicate your implementation logic and generate expected result. This will help testing with localized dialogs. > + > +DWORD WINAPI WorkerThread(void *param) Please please use more specific name. > + { > + succeeded = lstrcmpW(expected, text) == 0; > + if(!succeeded) > + { > + ok(0, "%s\n", wine_dbgstr_w(text)); > + ok(0, "%s\n", wine_dbgstr_w(expected)); > + } > + } Could this simply be ok(!lstrcmpW(), "..."); ? > + > +static void test_MessageBox_WM_COPY_Test(void) > +{ > + DWORD tid = 0; > + > + non_english = (PRIMARYLANGID(GetUserDefaultLangID()) != LANG_ENGLISH); > + trace("non_english %d\n", non_english); > + > + CreateThread(NULL, 0, WorkerThread, &expectedOK, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_OK); > + > + CreateThread(NULL, 0, WorkerThread, &expectedOkCancel, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_OKCANCEL); > + > + CreateThread(NULL, 0, WorkerThread, &expectedAbortRetryIgnore, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_ABORTRETRYIGNORE); > + > + CreateThread(NULL, 0, WorkerThread, &expectedYesNo, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_YESNO); > + > + CreateThread(NULL, 0, WorkerThread, &expectedYesNoCancel, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_YESNOCANCEL); > + > + CreateThread(NULL, 0, WorkerThread, &expectedRetryCancel, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_RETRYCANCEL); > + > + CreateThread(NULL, 0, WorkerThread, &expectedCancelTryContinue, 0, &tid); > + MessageBoxA(NULL, "Message", msgbox_title, MB_CANCELTRYCONTINUE); > +} This could be a loop over possible button values.

1 0

Re: [PATCH] netapi32/test: Add trace to help narrow down failing test.
by Hans Leidekker 08 Nov '16

08 Nov '16

On Tue, 2016-11-08 at 10:07 +0000, Alistair Leslie-Hughes wrote: > Based off a test run with extra traces > https://testbot.winehq.org/JobDetails.pl?Key=26512&log_201=1#k201 > the intermittently failing test is in test_DavGetUNCFromHTTPPath. The failure is a timeout, so you're likely to find a random test. I think we should concentrate on the earlier tests and figure out where all that time is spent.

2 1

Re: [PATCH] user32/msgbox: Support WM_COPY Message
by Dmitry Timoshkov 08 Nov '16

08 Nov '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +static void MSGBOX_CopyToClipbaord( HWND hwnd ) A typo in the name. > + static const WCHAR carriage[] = {'\r','\n', 0}; A usual name would be crlf[W]. -- Dmitry.

1 0

Re: [PATCH] netapi32/test: Add trace to help narrow down failing test.
by Nikolay Sivov 08 Nov '16

08 Nov '16

On 08.11.2016 13:07, Alistair Leslie-Hughes wrote: > Based off a test run with extra traces > https://testbot.winehq.org/JobDetails.pl?Key=26512&log_201=1#k201 > the intermittently failing test is in test_DavGetUNCFromHTTPPath. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/netapi32/tests/access.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/netapi32/tests/access.c b/dlls/netapi32/tests/access.c > index f095d77..0fab0de 100644 > --- a/dlls/netapi32/tests/access.c > +++ b/dlls/netapi32/tests/access.c > @@ -688,6 +688,7 @@ static void test_DavGetUNCFromHTTPPath(void) > for (i = 0; i < sizeof(tests)/sizeof(tests[0]); i++) > { > buf[0] = 0; > + trace("test: %d\n", i); > size = tests[i].size; > ret = pDavGetUNCFromHTTPPath( tests[i].path, buf, &size ); > ok( ret == tests[i].ret, "%u: expected %u got %u\n", i, tests[i].ret, ret ); ok() lines already print failed test index, and in case of a crash manual test as you is enough.

1 0

Re: [PATCH] vbscript: Coerce datatype in StrComp
by Marvin 08 Nov '16

08 Nov '16

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=26507 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Constructive podium thumping at Wineconf?
by Jeremy White 08 Nov '16

08 Nov '16

Hey all, As is tradition, on Saturday I plan to review the winehq test regime, and pound my fist on the table until people commit to fixing tests. We've spent the past few years managing the transition to qemu. I've been using this page to triage that progress: https://www.winehq.org/~jwhite/latest.html That reflects issues with our tests on Windows on qemu, excluding Windows 8 and Windows 10 (although it looks like I could perhaps add Windows 8 back into the mix, as the bleeding does not seem that bad any longer). We've stalled out at about 13 issues; we don't seem to be able to get below that. (There are 8 'old' issues, and 5 new ones, in case anyone wants to go look, including ones from ddraw, kernel32, netapi32, and user32). Prior to the qemu drive, the original goal was to get at least one Linux machine known to run the tests cleanly. The further hope would be that if we had a known set of 'good' test machines, then we could require that every patch succeed when run on those machines. We've made sporadic progress on that, but we did purchase a set of hardware with the intent of making that hardware run those tests cleanly. I see that we've driven those down to about 20 per system. Those machines are 'portable', for generous definitions of portable. But we could bring one or both them to Wineconf and work directly on them if we liked. Would that be useful? And, more broadly, is there some other way to consider this that would be more useful? Is there useful prep we can do that will give way to more constructive sessions at Wineconf? Cheers, Jeremy

2 1

Re: [PATCH resend 5/7] winebus.sys: reports for iohid
by Sebastian Lackner 07 Nov '16

07 Nov '16

On 04.11.2016 13:46, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > v2-0005-winebus.sys-reports-for-iohid.txt > > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index e1a97ef..7208117 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -119,6 +119,13 @@ static DWORD CFNumberToDWORD(CFNumberRef num) > return dwNum; > } > > +static void handle_IOHIDDeviceIOHIDReportCallback(void * inContext, > + IOReturn inResult, void * inSender, IOHIDReportType inType, > + uint32_t inReportID, uint8_t * inReport, CFIndex inReportLength) I would suggest to use parameter names without "in" prefix. Also, there usually shouldn't be any space between "*" and the following variable name. > +{ It might be better to store the DEVICE_OBJECT in a local variable before passing it to the next function, to ensure the types are checked correctly. Otherwise it remains unnoticed when the signature of process_hid_report changes in the future. > + process_hid_report(inContext, inReport, inReportLength); > +} > + > static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > { > ULONG_PTR dev1 = (ULONG_PTR)*(IOHIDDeviceRef*)get_platform_private(device); > @@ -179,7 +186,17 @@ static NTSTATUS get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DW > > static NTSTATUS begin_report_processing(DEVICE_OBJECT *device) > { > - return STATUS_NOT_IMPLEMENTED; > + DWORD length; > + uint8_t *buffer; > + IOHIDDeviceRef dev = *(IOHIDDeviceRef*)get_platform_private(device); > + CFNumberRef num; To be compatible with the rest of the code, this should only start processing once. You might have to store the state of report processing in the platform struct. > + > + num = IOHIDDeviceGetProperty(dev, CFSTR(kIOHIDMaxInputReportSizeKey)); > + length = CFNumberToDWORD(num); > + buffer = HeapAlloc(GetProcessHeap(), 0, length); You might want to do some error checking here. > + > + IOHIDDeviceRegisterInputReportCallback(dev, buffer, length, handle_IOHIDDeviceIOHIDReportCallback, device); > + return STATUS_SUCCESS; > } > > static NTSTATUS set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > @@ -244,6 +261,9 @@ static void handle_RemovalCallback(void *inContext, IOReturn inResult, void *inS > { > DEVICE_OBJECT *device; > TRACE("OS/X IOHID Device Removed %p\n", inIOHIDDeviceRef); > + IOHIDDeviceRegisterInputReportCallback(inIOHIDDeviceRef, NULL, 0, NULL, NULL); > + /* Note: Yes, we leak the buffer. But according to research there is no > + safe way to deallocate that buffer. */ Is it a problem when IOHIDDeviceRegisterInputReportCallback is called, although report processing was never started? And why isn't it safe to deallocate the buffer here? I don't think you will get additional reports when the device has been removed. > device = bus_find_hid_device(&iohid_vtbl, inIOHIDDeviceRef); > if (device) > { > > >

2 1

Re: [PATCH v3 1/7] winebus.sys: Add OS/X IOHID bus
by Sebastian Lackner 07 Nov '16

07 Nov '16

On 04.11.2016 13:45, Aric Stewart wrote: > v2: remove Unload code as it will never be triggered > v3: Suggestions from Ken Thomases > Merge Implement adding IOHID devices into this patch > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/Makefile.in | 3 +- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_iohid.c | 255 +++++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 3 + > 4 files changed, 261 insertions(+), 1 deletion(-) > create mode 100644 dlls/winebus.sys/bus_iohid.c > > > > v2-0001-winebus.sys-Add-OS-X-IOHID-bus.txt > > > diff --git a/dlls/winebus.sys/Makefile.in b/dlls/winebus.sys/Makefile.in > index 9d3a0c2..ac02533 100644 > --- a/dlls/winebus.sys/Makefile.in > +++ b/dlls/winebus.sys/Makefile.in > @@ -1,9 +1,10 @@ > MODULE = winebus.sys > IMPORTS = ntoskrnl setupapi > -EXTRALIBS = $(UDEV_LIBS) > +EXTRALIBS = $(IOKIT_LIBS) $(UDEV_LIBS) > EXTRAINCL = $(UDEV_CFLAGS) > EXTRADLLFLAGS = -Wb,--subsystem,native > > C_SRCS = \ > + bus_iohid.c \ > bus_udev.c \ > main.c > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 45a65e2..effbd4a 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -18,6 +18,7 @@ > > /* Busses */ > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > > /* Native device function table */ > typedef struct > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > new file mode 100644 > index 0000000..e47ed13 > --- /dev/null > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -0,0 +1,255 @@ > +/* Bus like function for mac HID devices > + * > + * Copyright 2016 CodeWeavers, Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "config.h" > +#include "wine/port.h" > + > +#include <stdarg.h> > + > +#if defined(HAVE_IOKIT_HID_IOHIDLIB_H) > +#define DWORD UInt32 > +#define LPDWORD UInt32* > +#define LONG SInt32 > +#define LPLONG SInt32* > +#define E_PENDING __carbon_E_PENDING > +#define ULONG __carbon_ULONG > +#define E_INVALIDARG __carbon_E_INVALIDARG > +#define E_OUTOFMEMORY __carbon_E_OUTOFMEMORY > +#define E_HANDLE __carbon_E_HANDLE > +#define E_ACCESSDENIED __carbon_E_ACCESSDENIED > +#define E_UNEXPECTED __carbon_E_UNEXPECTED > +#define E_FAIL __carbon_E_FAIL > +#define E_ABORT __carbon_E_ABORT > +#define E_POINTER __carbon_E_POINTER > +#define E_NOINTERFACE __carbon_E_NOINTERFACE > +#define E_NOTIMPL __carbon_E_NOTIMPL > +#define S_FALSE __carbon_S_FALSE > +#define S_OK __carbon_S_OK > +#define HRESULT_FACILITY __carbon_HRESULT_FACILITY > +#define IS_ERROR __carbon_IS_ERROR > +#define FAILED __carbon_FAILED > +#define SUCCEEDED __carbon_SUCCEEDED > +#define MAKE_HRESULT __carbon_MAKE_HRESULT > +#define HRESULT __carbon_HRESULT > +#define STDMETHODCALLTYPE __carbon_STDMETHODCALLTYPE > +#define PAGE_SHIFT __carbon_PAGE_SHIFT > +#include <IOKit/IOKitLib.h> > +#include <IOKit/hid/IOHIDLib.h> > +#undef ULONG > +#undef E_INVALIDARG > +#undef E_OUTOFMEMORY > +#undef E_HANDLE > +#undef E_ACCESSDENIED > +#undef E_UNEXPECTED > +#undef E_FAIL > +#undef E_ABORT > +#undef E_POINTER > +#undef E_NOINTERFACE > +#undef E_NOTIMPL > +#undef S_FALSE > +#undef S_OK > +#undef HRESULT_FACILITY > +#undef IS_ERROR > +#undef FAILED > +#undef SUCCEEDED > +#undef MAKE_HRESULT > +#undef HRESULT > +#undef STDMETHODCALLTYPE > +#undef DWORD > +#undef LPDWORD > +#undef LONG > +#undef LPLONG > +#undef E_PENDING > +#undef PAGE_SHIFT > +#endif /* HAVE_IOKIT_HID_IOHIDLIB_H */ > + > +#define NONAMELESSUNION > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windef.h" > +#include "winbase.h" > +#include "winternl.h" > +#include "winioctl.h" > +#include "ddk/wdm.h" > +#include "wine/debug.h" > + > +#include "bus.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +#ifdef HAVE_IOHIDMANAGERCREATE > + > +static DRIVER_OBJECT *iohid_driver_obj = NULL; > +static IOHIDManagerRef hid_manager; > + > +static const WCHAR busidW[] = {'I','O','H','I','D',0}; > + > +#include "initguid.h" > +DEFINE_GUID(GUID_DEVCLASS_IOHID, 0x989D309D,0x0470,0x4E1A,0x89,0x38,0x50,0x1F,0x42,0xBD,0x9A,0xCD); > + > +static void CFStringToWSTR(CFStringRef cstr, LPWSTR wstr, int length) > +{ > + int len = min(CFStringGetLength(cstr), length-1); > + CFStringGetCharacters(cstr, CFRangeMake(0, len), wstr); Are you sure it doesn't cause a compiler warning? Winemac code always uses casts from WCHAR* to UniChar*. > + wstr[len] = 0; > +} > + > +static DWORD CFNumberToDWORD(CFNumberRef num) > +{ > + int dwNum = 0; > + if (num) > + CFNumberGetValue(num, kCFNumberIntType, &dwNum); > + return dwNum; > +} > + > +static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > +{ > + return 0; > +} > + > +static NTSTATUS get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > +{ > + *written = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS get_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *read) > +{ > + *read = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS set_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > +{ > + *written = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static const platform_vtbl iohid_vtbl = { Usually "{" is on the next line. > + compare_platform_device, > + get_reportdescriptor, > + get_string, > + begin_report_processing, > + set_output_report, > + get_feature_report, > + set_feature_report, > +}; > + > +static void handle_DeviceMatchingCallback(void *inContext, IOReturn inResult, void *inSender, IOHIDDeviceRef inIOHIDDeviceRef) Those parameter names sound a bit unusual. Why is there always an "in" prefix in front? And why are there two spaces in front of "inIOHIDDeviceRef"? > +{ > + DEVICE_OBJECT *device; > + DWORD vid, pid, version; > + CFStringRef str = NULL; > + WCHAR serial_string[256]; > + BOOL is_gamepad; > + > + TRACE("OS/X IOHID Device Added %p\n", inIOHIDDeviceRef); > + > + vid = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDVendorIDKey))); > + pid = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDProductIDKey))); > + version = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDVersionNumberKey))); > + str = IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDSerialNumberKey)); > + if (str) CFStringToWSTR(str, serial_string, sizeof(serial_string) / sizeof(WCHAR)); > + > + is_gamepad = (IOHIDDeviceConformsTo(inIOHIDDeviceRef, kHIDPage_GenericDesktop, kHIDUsage_GD_GamePad) || > + IOHIDDeviceConformsTo(inIOHIDDeviceRef, kHIDPage_GenericDesktop, kHIDUsage_GD_Joystick)); > + > + device = bus_create_hid_device(iohid_driver_obj, busidW, vid, pid, version, 0, str?serial_string:NULL, is_gamepad, &GUID_DEVCLASS_IOHID, &iohid_vtbl, sizeof(inIOHIDDeviceRef)); > + if (!device) > + ERR("Failed to create device\n"); > + else > + { > + IOHIDDeviceRef* ext = get_platform_private(device); > + *ext = inIOHIDDeviceRef; I think it would be better to use a struct, even if you only want to store one value at the moment. Also, please use a helper function to avoid casts in the rest of the driver code, similar to how it is done for udev. > + IoInvalidateDeviceRelations(device, BusRelations); > + } > +} > + > +/* This puts the relevant run loop for event handling into a WINE thread */ > +static DWORD CALLBACK runloop_thread(VOID *args) Usually you should always use lowercase "void" in Wine code. > +{ > + DRIVER_OBJECT *driver = (DRIVER_OBJECT*)args; > + CFRunLoopRef run_loop = CFRunLoopGetCurrent(); > + > + IOHIDManagerSetDeviceMatching(hid_manager, NULL); > + IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, handle_DeviceMatchingCallback, driver); There is no need to pass "driver" as context when you don't use it in the callback. > + IOHIDManagerScheduleWithRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > + if (IOHIDManagerOpen( hid_manager, 0 ) != kIOReturnSuccess) > + { > + ERR("Couldn't open IOHIDManager.\n"); > + IOHIDManagerUnscheduleFromRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > + CFRelease(hid_manager); > + return 0; > + } > + > + CFRunLoopRun(); > + TRACE("Run Loop exiting\n"); > + > + IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, NULL, NULL); > + IOHIDManagerUnscheduleFromRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); Can you be sure that run_loop is still valid here? > + CFRelease(hid_manager); > + return 1; > +} > + > +NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + HANDLE run_loop_handle; > + > + TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > + > + iohid_driver_obj = driver; > + driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; > + hid_manager = IOHIDManagerCreate(kCFAllocatorDefault, 0L); > + if (!(run_loop_handle = CreateThread(NULL, 0, runloop_thread, driver, 0, NULL))) > + { > + ERR("Failed to initialize IOHID Manager thread\n"); > + iohid_driver_obj = NULL; > + CFRelease(hid_manager); > + return STATUS_UNSUCCESSFUL; > + } > + > + CloseHandle(run_loop_handle); > + return STATUS_SUCCESS; > +} > + > +#else > + > +NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + WARN("IOHID Support not compiled into Wine.\n"); > + return STATUS_NOT_IMPLEMENTED; > +} > + > +#endif /* HAVE_IOHIDMANAGERCREATE */ > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 791ccbb..ed95435 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -628,10 +628,13 @@ NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > static UNICODE_STRING udev = {sizeof(udevW) - sizeof(WCHAR), sizeof(udevW), (WCHAR *)udevW}; > + static const WCHAR iohidW[] = {'\\','D','r','i','v','e','r','\\','I','O','H','I','D',0}; > + static UNICODE_STRING iohid = {sizeof(iohidW) - sizeof(WCHAR), sizeof(iohidW), (WCHAR *)iohidW}; > > TRACE( "(%p, %s)\n", driver, debugstr_w(path->Buffer) ); > > IoCreateDriver(&udev, udev_driver_init); > + IoCreateDriver(&iohid, iohid_driver_init); > > return STATUS_SUCCESS; > } > > >

2 1

Re: [PATCH 1/2] crypt32: Import system root certs into volatile registry keys instead of dedicated root store.
by Jacek Caban 07 Nov '16

07 Nov '16

It was me sending changed Donat's patches with messed From header. Sorry about that. Same for 2/2 patch. Jacek

2 3

Re: rsaenh/tests: Don't initialize the environment, the tests that follow do that.
by Marvin 07 Nov '16

07 Nov '16

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=26484 Your paranoid android. === w864 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

3 3

Re: [PATCH resend 7/7] winebus.sys: IOCTL_HID_GET_FEATURE for iohid
by Sebastian Lackner 07 Nov '16

07 Nov '16

On 04.11.2016 13:47, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 33 +++++++++++++++++++++++++++++---- > 1 file changed, 29 insertions(+), 4 deletions(-) > > > > v2-0007-winebus.sys-IOCTL_HID_GET_FEATURE-for-iohid.txt > > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index 59c02ea..402451c 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -218,14 +218,39 @@ static NTSTATUS set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, > > static NTSTATUS get_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *read) > { > - *read = 0; > - return STATUS_NOT_IMPLEMENTED; > + IOReturn ret; > + CFIndex report_length = length; > + IOHIDDeviceRef dev = *(IOHIDDeviceRef*)get_platform_private(device); > + > + ret = IOHIDDeviceGetReport(dev, kIOHIDReportTypeFeature, id, report, &report_length); > + if (ret == kIOReturnSuccess) > + { > + *read = report_length; > + return STATUS_SUCCESS; > + } > + else > + { > + *read = 0; > + return STATUS_UNSUCCESSFUL; > + } > } > > static NTSTATUS set_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > { > - *written = 0; > - return STATUS_NOT_IMPLEMENTED; > + IOReturn result; > + IOHIDDeviceRef dev = *(IOHIDDeviceRef*)get_platform_private(device); > + > + result = IOHIDDeviceSetReport(dev, kIOHIDReportTypeFeature, id, report, length); The line above has 5 space indentation. > + if (result == kIOReturnSuccess) > + { > + *written = length; > + return STATUS_SUCCESS; > + } > + else > + { > + *written = 0; > + return STATUS_UNSUCCESSFUL; > + } > } > > static const platform_vtbl iohid_vtbl = { > > >

1 0

Re: [PATCH resend 3/7] winebus.sys: IOCTL_HID_GET_DEVICE_DESCRIPTOR for iohid
by Sebastian Lackner 07 Nov '16

07 Nov '16

On 04.11.2016 13:46, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > v2-0003-winebus.sys-IOCTL_HID_GET_DEVICE_DESCRIPTOR-for-ioh.txt > > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index 3cd0b19..380cdb4 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -127,7 +127,18 @@ static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > > static NTSTATUS get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length) > { > - return STATUS_NOT_IMPLEMENTED; > + IOHIDDeviceRef dev = *(IOHIDDeviceRef*)get_platform_private(device); > + CFDataRef data = IOHIDDeviceGetProperty(dev, CFSTR(kIOHIDReportDescriptorKey)); Is it always guaranteed that this returns valid data? If not, it might be better to check the returned CFTypeRef. > + int data_length = CFDataGetLength(data); > + const UInt8 *ptr; > + > + *out_length = data_length; > + if (length < data_length) > + return STATUS_BUFFER_TOO_SMALL; > + > + ptr = CFDataGetBytePtr(data); > + memcpy(buffer, ptr, data_length); > + return STATUS_SUCCESS; > } > > static NTSTATUS get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length) > > >

1 0

Re: [PATCH v2 2/7] winebus.sys: Implement removing IOHID devices
by Sebastian Lackner 07 Nov '16

07 Nov '16

On 04.11.2016 13:45, Aric Stewart wrote: > v2: Suggestions from Ken Thomases > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > v2-0002-winebus.sys-Implement-removing-IOHID-devices.txt > > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index e47ed13..3cd0b19 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -120,7 +120,9 @@ static DWORD CFNumberToDWORD(CFNumberRef num) > > static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > { > - return 0; > + ULONG_PTR dev1 = (ULONG_PTR)*(IOHIDDeviceRef*)get_platform_private(device); > + ULONG_PTR dev2 = (ULONG_PTR)platform_dev; > + return dev1 - dev2; As already mentioned, the int return value is not sufficient to hold the difference between the two ULONG_PTR values. > } > > static NTSTATUS get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length) > @@ -196,6 +198,18 @@ static void handle_DeviceMatchingCallback(void *inContext, IOReturn inResult, vo > } > } > > +static void handle_RemovalCallback(void *inContext, IOReturn inResult, void *inSender, IOHIDDeviceRef inIOHIDDeviceRef) Similar to patch 1, you could probably use better parameter names here. > +{ > + DEVICE_OBJECT *device; > + TRACE("OS/X IOHID Device Removed %p\n", inIOHIDDeviceRef); > + device = bus_find_hid_device(&iohid_vtbl, inIOHIDDeviceRef); > + if (device) > + { > + IoInvalidateDeviceRelations(device, RemovalRelations); > + bus_remove_hid_device(device); > + } > +} > + > /* This puts the relevant run loop for event handling into a WINE thread */ > static DWORD CALLBACK runloop_thread(VOID *args) > { > @@ -204,6 +218,7 @@ static DWORD CALLBACK runloop_thread(VOID *args) > > IOHIDManagerSetDeviceMatching(hid_manager, NULL); > IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, handle_DeviceMatchingCallback, driver); > + IOHIDManagerRegisterDeviceRemovalCallback(hid_manager, handle_RemovalCallback, driver); The context parameter is also not really used here. > IOHIDManagerScheduleWithRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > if (IOHIDManagerOpen( hid_manager, 0 ) != kIOReturnSuccess) > { > @@ -217,6 +232,7 @@ static DWORD CALLBACK runloop_thread(VOID *args) > TRACE("Run Loop exiting\n"); > > IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, NULL, NULL); > + IOHIDManagerRegisterDeviceRemovalCallback(hid_manager, NULL, NULL); > IOHIDManagerUnscheduleFromRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > CFRelease(hid_manager); > return 1; > > >

1 0

Re: [PATCH 4/4] d2d1: Added support for D2D1_DRAW_TEXT_OPTIONS_ENABLE_COLOR_FONT
by Henri Verbeet 07 Nov '16

07 Nov '16

On 5 November 2016 at 22:12, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1574,14 +1575,89 @@ static HRESULT STDMETHODCALLTYPE d2d_text_renderer_DrawGlyphRun(IDWriteTextRende > > if (desc) > WARN("Ignoring glyph run description %p.\n", desc); > - if (context->options & ~D2D1_DRAW_TEXT_OPTIONS_NO_SNAP) > + if (context->options & ~(D2D1_DRAW_TEXT_OPTIONS_NO_SNAP|D2D1_DRAW_TEXT_OPTIONS_ENABLE_COLOR_FONT)) > FIXME("Ignoring options %#x.\n", context->options); "D2D1_DRAW_TEXT_OPTIONS_NO_SNAP | D2D1_DRAW_TEXT_OPTIONS_ENABLE_COLOR_FONT" > + if (FAILED(hr = DWriteCreateFactory(DWRITE_FACTORY_TYPE_SHARED, &IID_IDWriteFactory2, > + (IUnknown **)&dwrite_factory))) > + { > + ERR("Failed to create dwrite factory, hr %#x.\n", hr); > + return hr; This leaks "brush". > + hr = IDWriteFactory2_TranslateColorGlyphRun(dwrite_factory, baseline_origin_x, baseline_origin_y, > + glyph_run, desc, measuring_mode, (DWRITE_MATRIX *)&render_target->drawing_state.transform, 0, &layers); > + IDWriteFactory2_Release(dwrite_factory); > + if (FAILED(hr)) > + { > + ERR("Failed to create color glyph run enumerator, hr %#x.\n", hr); > + return hr; > + } Likewise. > + while (1) for (;;) > + if (color_run->paletteIndex == 0xffff) > + color_brush = brush; > + else > + ID2D1RenderTarget_CreateSolidColorBrush(&render_target->ID2D1RenderTarget_iface, > + &color_run->runColor, NULL, (ID2D1SolidColorBrush **)&color_brush); CreateSolidColorBrush() can fail.

1 0

Re: [PATCH] vbscript: Call GetItemInfo() with original item name
by Jacek Caban 07 Nov '16

07 Nov '16

Hi Nikolay, On 05.11.2016 22:53, Nikolay Sivov wrote: > diff --git a/programs/wscript/tests/run.js b/programs/wscript/tests/run.js > index db0d6f9..2d544ab 100644 > --- a/programs/wscript/tests/run.js > +++ b/programs/wscript/tests/run.js This deserves tests inside vbscript tests that shows the exact problem. I send a patch with such test, please send wscript tests as a separated patch. Thanks, Jacek

1 0

Re: [PATCH] user32: Add support for class versions
by Nikolay Sivov 07 Nov '16

07 Nov '16

On 05.11.2016 16:36, Ivan Akulinchev wrote: > Signed-off-by: Ivan Akulinchev <ivan.akulinchev(a)gmail.com> > --- > dlls/comctl32/comctl32.manifest | 1 - > dlls/comctl32/theming.c | 15 +++++++-- > dlls/user32/class.c | 73 +++++++++++++++++++++++++++++++++++++---- > dlls/user32/user_private.h | 2 ++ > dlls/user32/win.c | 7 ++-- > 5 files changed, 86 insertions(+), 12 deletions(-) > Hi, thanks for looking into this. > diff --git a/dlls/comctl32/comctl32.manifest b/dlls/comctl32/comctl32.manifest > index 4c86137..5aa55a3 100644 > --- a/dlls/comctl32/comctl32.manifest > +++ b/dlls/comctl32/comctl32.manifest > @@ -12,7 +12,6 @@ > <windowClass>NativeFontCtl</windowClass> > <windowClass>ReBarWindow32</windowClass> > <windowClass>ScrollBar</windowClass> > - <windowClass>Static</windowClass> > <windowClass>SysAnimate32</windowClass> > <windowClass>SysDateTimePick32</windowClass> > <windowClass>SysHeader32</windowClass> Something tells me we'll need opposite logic here, if versioned classes support are to be added one by one. > diff --git a/dlls/comctl32/theming.c b/dlls/comctl32/theming.c > index 93d6fe6..b78ecc9 100644 > --- a/dlls/comctl32/theming.c > +++ b/dlls/comctl32/theming.c > @@ -28,6 +28,7 @@ > #include "comctl32.h" > #include "uxtheme.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > > WINE_DEFAULT_DEBUG_CHANNEL(theming); > > @@ -124,8 +125,6 @@ void THEMING_Initialize (void) > static const WCHAR refDataPropName[] = > { 'C','C','3','2','T','h','e','m','i','n','g','D','a','t','a',0 }; > > - if (!IsThemeActive()) return; > - > atSubclassProp = GlobalAddAtomW (subclassPropName); > atRefDataProp = GlobalAddAtomW (refDataPropName); > > @@ -142,6 +141,18 @@ void THEMING_Initialize (void) > } > originalProcs[i] = class.lpfnWndProc; > class.lpfnWndProc = subclassProcs[i]; > + > + /* > + * FIXME: The Dialog class ('#32770') should NOT be overridden here. > + * > + * Temporarily ignore this issue using the hack below... > + */ > + if (strcmpiW(subclasses[i].className, dialogClass) != 0) > + { > + /* If not a dialog (see above), make the class global */ > + class.style |= CS_GLOBALCLASS; > + class.hInstance = NULL; > + } > > if (!class.lpfnWndProc) > { All theming.c should go when transition is complete, because once you're able to create 6.0.0.0!Static it will support theme drawing API regardless if theming is enabled or not. > diff --git a/dlls/user32/class.c b/dlls/user32/class.c > index 0b3582e..5b16008 100644 > --- a/dlls/user32/class.c > +++ b/dlls/user32/class.c > @@ -411,6 +411,42 @@ static CLASS *CLASS_RegisterClass( LPCWSTR name, HINSTANCE hInstance, BOOL local > return classPtr; > } > > +/*********************************************************************** > + * CLASS_GetVersionedName > + * > + * Return a versioned class name, like "6.0.2600.2982!Button". > + */ > +LPCWSTR CLASS_GetVersionedName( LPCWSTR name ) > +{ > + ACTCTX_SECTION_KEYED_DATA data = { sizeof(data) }; > + > + static const WCHAR staticW[] = { 'S','t','a','t','i','c',0 }; > + > + if (!name) > + return NULL; > + > + if (IS_INTRESOURCE( name )) > + return name; > + > + /* > + * FIXME: I disabled the Static class in comctl32.manifest (because it is > + * not implemented there yet), however I still get "6.0.2600.2982!Static". > + * > + * Is it a FindActCtxSectionString bug? > + */ > + if (strcmpiW( name, staticW ) == 0) > + return name; This needs separate investigation if it's truly happens without Static present in manifest. > + > + if (FindActCtxSectionStringW( 0, NULL, 3, name, &data )) > + { > + BYTE *res = (BYTE *)data.lpData; > + ULONG offset = *(ULONG *)(res + sizeof(ULONG) * 2 + sizeof(DWORD)); > + return (LPCWSTR)(res + offset); > + } > + > + return name; This makes sense, but please use types from ntdll/actctx.c (just duplicate what you need in user32, same as it's done in ole32 and kernel32 already). Also 3 here stands for ACTIVATION_CONTEXT_SECTION_WINDOW_CLASS_REDIRECTION. > +} > + > > /*********************************************************************** > * register_builtin > @@ -576,10 +612,12 @@ ATOM WINAPI RegisterClassExA( const WNDCLASSEXA* wc ) > > if (!IS_INTRESOURCE(wc->lpszClassName)) > { > + LPCWSTR versioned_name; > WCHAR name[MAX_ATOM_LEN + 1]; > > if (!MultiByteToWideChar( CP_ACP, 0, wc->lpszClassName, -1, name, MAX_ATOM_LEN + 1 )) return 0; > - classPtr = CLASS_RegisterClass( name, instance, !(wc->style & CS_GLOBALCLASS), > + versioned_name = CLASS_GetVersionedName( name ); > + classPtr = CLASS_RegisterClass( versioned_name, instance, !(wc->style & CS_GLOBALCLASS), > wc->style, wc->cbClsExtra, wc->cbWndExtra ); > } Why do you need this in -A call too? > else > @@ -619,6 +657,7 @@ ATOM WINAPI RegisterClassExW( const WNDCLASSEXW* wc ) > ATOM atom; > CLASS *classPtr; > HINSTANCE instance; > + LPCWSTR versioned_name; > > GetDesktopWindow(); /* create the desktop window to trigger builtin class registration */ > > @@ -630,7 +669,9 @@ ATOM WINAPI RegisterClassExW( const WNDCLASSEXW* wc ) > } > if (!(instance = wc->hInstance)) instance = GetModuleHandleW( NULL ); > > - if (!(classPtr = CLASS_RegisterClass( wc->lpszClassName, instance, !(wc->style & CS_GLOBALCLASS), > + versioned_name = CLASS_GetVersionedName( wc->lpszClassName ); > + > + if (!(classPtr = CLASS_RegisterClass( versioned_name, instance, !(wc->style & CS_GLOBALCLASS), > wc->style, wc->cbClsExtra, wc->cbWndExtra ))) > return 0; > This part I looks wrong. Why would it register something that is not what user asked for? My understanding is that comctl32 itself should register its versioned classes (and in ideal v5 vs v6 separation only v6 module should be doing that). So comctl32 is loaded, it registers regular classes first, like Listview, then it registered versioned names like 6.0.0.0!Listview. What RegisterClassExW should probably check is if target class in current context is already registered, so if application tries to register ClassName, and context has redirection set as 6.0.0.0!ClassName, registration should fail. I think it should be possible to add a test for that: - create temporary context with window class redirection section; - manually register corresponding versioned class name; - activate context; - see what happens if you try to register non-version class. I vaguely remember I tried something like that on Windows years ago, and as expected it breaks this whole redirection scheme, because if 6.x.x.x!Button is already registered by the time context is activated comctl32 won't be able to register it again. > @@ -678,6 +719,7 @@ BOOL WINAPI UnregisterClassA( LPCSTR className, HINSTANCE hInstance ) > BOOL WINAPI UnregisterClassW( LPCWSTR className, HINSTANCE hInstance ) > { > CLASS *classPtr = NULL; > + LPCWSTR versioned_name = CLASS_GetVersionedName( className ); > > GetDesktopWindow(); /* create the desktop window to trigger builtin class registration */ > > @@ -685,7 +727,7 @@ BOOL WINAPI UnregisterClassW( LPCWSTR className, HINSTANCE hInstance ) > { > req->instance = wine_server_client_ptr( hInstance ); > if (!(req->atom = get_int_atom_value(className)) && className) > - wine_server_add_data( req, className, strlenW(className) * sizeof(WCHAR) ); > + wine_server_add_data( req, versioned_name, strlenW(versioned_name) * sizeof(WCHAR) ); > if (!wine_server_call_err( req )) classPtr = wine_server_get_ptr( reply->client_ptr ); > } > SERVER_END_REQ; > @@ -1192,10 +1234,15 @@ BOOL WINAPI GetClassInfoExA( HINSTANCE hInstance, LPCSTR name, WNDCLASSEXA *wc ) > > if (!IS_INTRESOURCE(name)) > { > + LPCWSTR versioned_name; > WCHAR nameW[MAX_ATOM_LEN + 1]; > if (!MultiByteToWideChar( CP_ACP, 0, name, -1, nameW, sizeof(nameW)/sizeof(WCHAR) )) > return FALSE; > - classPtr = CLASS_FindClass( nameW, hInstance ); > + versioned_name = CLASS_GetVersionedName( nameW ); > + classPtr = CLASS_FindClass( versioned_name, hInstance ); > + /* FIXME: I believe we shouldn't fall back to the normal class. Fill > + * free to remove it if necessary. */ > + if (!classPtr) classPtr = CLASS_FindClass( nameW, hInstance ); > } > else classPtr = CLASS_FindClass( (LPCWSTR)name, hInstance ); > > @@ -1230,6 +1277,7 @@ BOOL WINAPI GetClassInfoExW( HINSTANCE hInstance, LPCWSTR name, WNDCLASSEXW *wc > { > ATOM atom; > CLASS *classPtr; > + LPCWSTR versioned_name; > > TRACE("%p %s %p\n", hInstance, debugstr_w(name), wc); > > @@ -1241,10 +1289,21 @@ BOOL WINAPI GetClassInfoExW( HINSTANCE hInstance, LPCWSTR name, WNDCLASSEXW *wc > > if (!hInstance) hInstance = user32_module; > > - if (!(classPtr = CLASS_FindClass( name, hInstance ))) > + versioned_name = CLASS_GetVersionedName( name ); > + > + classPtr = CLASS_FindClass( versioned_name, hInstance ); > + if (!classPtr) > { > - SetLastError( ERROR_CLASS_DOES_NOT_EXIST ); > - return FALSE; > + /* > + * FIXME: It's not correct to fall back to the normal class, but our > + * comctl32 implementation depends on it... > + */ > + classPtr = CLASS_FindClass( name, hInstance ); > + if (!classPtr) > + { > + SetLastError( ERROR_CLASS_DOES_NOT_EXIST ); > + return FALSE; > + } > } > wc->style = classPtr->style; > wc->lpfnWndProc = WINPROC_GetProc( classPtr->winproc, TRUE ); GetClassInfo part looks okay. It shouldn't break anything even if we had it today, except that it adds bogus context lookup that is a waste of time. > diff --git a/dlls/user32/user_private.h b/dlls/user32/user_private.h > index 0b5b2ac..0c212ce 100644 > --- a/dlls/user32/user_private.h > +++ b/dlls/user32/user_private.h > @@ -281,6 +281,8 @@ extern void SPY_EnterMessage( INT iFlag, HWND hwnd, UINT msg, WPARAM wParam, LPA > extern void SPY_ExitMessage( INT iFlag, HWND hwnd, UINT msg, > LRESULT lReturn, WPARAM wParam, LPARAM lParam ) DECLSPEC_HIDDEN; > > +extern LPCWSTR CLASS_GetVersionedName( LPCWSTR name ) DECLSPEC_HIDDEN; > + > #include "pshpack1.h" > > typedef struct > diff --git a/dlls/user32/win.c b/dlls/user32/win.c > index a7be4a3..42676b5 100644 > --- a/dlls/user32/win.c > +++ b/dlls/user32/win.c > @@ -1740,9 +1740,11 @@ HWND WINAPI DECLSPEC_HOTPATCH CreateWindowExA( DWORD exStyle, LPCSTR className, > if (!IS_INTRESOURCE(className)) > { > WCHAR bufferW[256]; > + LPCWSTR versioned_name; > if (!MultiByteToWideChar( CP_ACP, 0, className, -1, bufferW, sizeof(bufferW)/sizeof(WCHAR) )) > return 0; > - return wow_handlers.create_window( (CREATESTRUCTW *)&cs, bufferW, instance, FALSE ); > + versioned_name = CLASS_GetVersionedName( bufferW ); > + return wow_handlers.create_window( (CREATESTRUCTW *)&cs, versioned_name, instance, FALSE ); > } > /* Note: we rely on the fact that CREATESTRUCTA and */ > /* CREATESTRUCTW have the same layout. */ > @@ -1760,6 +1762,7 @@ HWND WINAPI DECLSPEC_HOTPATCH CreateWindowExW( DWORD exStyle, LPCWSTR className, > HINSTANCE instance, LPVOID data ) > { > CREATESTRUCTW cs; > + LPCWSTR versioned_name = CLASS_GetVersionedName( className ); > > cs.lpCreateParams = data; > cs.hInstance = instance; > @@ -1774,7 +1777,7 @@ HWND WINAPI DECLSPEC_HOTPATCH CreateWindowExW( DWORD exStyle, LPCWSTR className, > cs.lpszClass = className; > cs.dwExStyle = exStyle; > > - return wow_handlers.create_window( &cs, className, instance, TRUE ); > + return wow_handlers.create_window( &cs, versioned_name, instance, TRUE ); > } > Looks fine, but it could go to WIN_CreateWindowEx(). There's one potentially very important thing about all this, according to docs every winproc call is guaranteed to happen under correct context. So basically if you send a message while particular context was activated, if this window belongs to different thread docs imply that context is temporary activated around winproc call on that receiving thread. I was unable to make this happen, maybe a fresh pair of eyes will be helpful.

4 6

Re: [PATCH] d3dx10: Parially implement async data loaders interfaces
by Matteo Bruni 06 Nov '16

06 Nov '16

2016-11-06 19:45 GMT+01:00 Nikolay Sivov <nsivov(a)codeweavers.com>: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d3dx10_43/async.c | 296 ++++++++++++++++++++++++++++++++++++++++-- > dlls/d3dx10_43/tests/d3dx10.c | 36 ++--- > 2 files changed, 306 insertions(+), 26 deletions(-) > > diff --git a/dlls/d3dx10_43/async.c b/dlls/d3dx10_43/async.c > index f49eb92..a9cbde5 100644 > --- a/dlls/d3dx10_43/async.c > +++ b/dlls/d3dx10_43/async.c > +/* Memory data loader. */ > +static HRESULT WINAPI memorydataloader_Load(ID3DX10DataLoader *loader) > +{ > + TRACE("loader %p\n", loader); We usually put a period at the end of trace messages. By the way, these comments don't add much IMO, it's pretty clear where each interface implementation starts and ends. > +static HRESULT WINAPI memorydataloader_Decompress(ID3DX10DataLoader *iface, void **data, SIZE_T *size) > +{ > + struct asyncdataloader *loader = impl_from_ID3DX10DataLoader(iface); > + > + FIXME("loader %p, data %p, size %p semi-stub\n", loader, data, size); > + > + *data = loader->data; > + *size = loader->size; > + > + return S_OK; > +} Why the fixme? What's still missing here? > +static HRESULT WINAPI filedataloader_Load(ID3DX10DataLoader *iface) > +{ > + struct asyncdataloader *loader = impl_from_ID3DX10DataLoader(iface); > + HANDLE mapping; > + > + TRACE("loader %p\n", loader); > + > + if (loader->u.file == INVALID_HANDLE_VALUE) > + return D3D10_ERROR_FILE_NOT_FOUND; > + > + if (loader->data) > + return S_OK; > + > + GetFileSize(loader->u.file, (DWORD*)&loader->size); > + mapping = CreateFileMappingW(loader->u.file, NULL, PAGE_READONLY, 0, 0, NULL); > + if (!mapping) > + return E_FAIL; > + > + loader->data = MapViewOfFile(mapping, FILE_MAP_READ, 0, 0, 0); > + CloseHandle(mapping); > + if (!loader->data) > + return E_FAIL; > + > + return S_OK; > +} Creating and keeping a file mapping open might not be correct. What happens on Windows if e.g. you try to delete the file after Load() but before Decompress()? The issue might also be between Decompress() and Destroy(). I guess I'd like some more tests for the file and the resource loaders... > + if (!(rsrc = FindResourceA(module, resource, (LPSTR)RT_RCDATA))) Please avoid LPtypes and casting away const, here and below.

2 2

Re: [PATCH] ntdll: Add a simple test for RtlDosApplyFileIsolationRedirection_Ustr
by Nikolay Sivov 06 Nov '16

06 Nov '16

On 06.11.2016 4:54, Ivan Akulinchev wrote: > Signed-off-by: Ivan Akulinchev <ivan.akulinchev(a)gmail.com> > --- > dlls/ntdll/tests/Makefile.in | 1 + > dlls/ntdll/tests/sxs.c | 141 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 142 insertions(+) > create mode 100644 dlls/ntdll/tests/sxs.c > > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index fc352dd..7fe1a70 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -21,5 +21,6 @@ C_SRCS = \ > rtlbitmap.c \ > rtlstr.c \ > string.c \ > + sxs.c \ > threadpool.c \ > time.c > diff --git a/dlls/ntdll/tests/sxs.c b/dlls/ntdll/tests/sxs.c > new file mode 100644 > index 0000000..e04803b > --- /dev/null > +++ b/dlls/ntdll/tests/sxs.c > @@ -0,0 +1,141 @@ > +/* > + * Tests for the Windows side-by-side assemblies. > + * > + * Copyright 2016 Ivan Akulinchev > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "winnls.h" > +#include "winternl.h" > + > +#include "wine/test.h" > + > +static NTSTATUS (WINAPI *pRtlDosApplyFileIsolationRedirection_Ustr)(ULONG, > + PUNICODE_STRING, > + PUNICODE_STRING, > + PUNICODE_STRING, > + PUNICODE_STRING, > + PUNICODE_STRING *, > + PULONG, > + PULONG, > + PULONG); > + > +static const CHAR manifest_name[] = "winsxs.manifest"; > + > +/* Note: '\n' is intentionally skipped. */ > +static const CHAR manifest[] = > + "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>" > + "<assembly xmlns=\"urn:schemas-microsoft-com:asm.v1\" manifestVersion=\"1.0\">" > + " <assemblyIdentity type=\"win32\"" > + " name=\"Wine.NtDll.Tests\"" > + " version=\"1.0.0.0\"" > + " processorArchitecture=\"*\" />" > + " <dependency>" > + " <dependentAssembly>" > + " <assemblyIdentity type=\"win32\"" > + " name=\"microsoft.windows.common-controls\"" > + " version=\"6.0.0.0\"" > + " processorArchitecture=\"*\"" > + " publicKeyToken=\"6595b64144ccf1df\"" > + " language=\"*\" />" > + " </dependentAssembly>" > + " </dependency>" > + "</assembly>"; > + > +static void test_rtl_dos_apply_file_isolation_redirect(void) > +{ > + NTSTATUS status; > + WCHAR buffer[MAX_PATH]; > + UNICODE_STRING original_name; > + UNICODE_STRING extension; > + UNICODE_STRING unknown1; > + UNICODE_STRING unknown2; > + UNICODE_STRING *path; > + > + static const WCHAR original_nameW[] = {'c','o','m','c','t','l','3','2',0}; > + static const WCHAR extensionW[] = {'.','d','l','l',0}; > + static const WCHAR emptyW[] = {'\0',0}; > + > + RtlInitUnicodeString(&original_name, original_nameW); > + RtlInitUnicodeString(&extension, extensionW); > + RtlInitUnicodeString(&unknown2, emptyW); > + > + unknown1.Buffer = buffer; > + unknown1.Length = 0; > + unknown1.MaximumLength = MAX_PATH; > + > + status = pRtlDosApplyFileIsolationRedirection_Ustr(1, &original_name, &extension, &unknown1, > + &unknown2, &path, NULL, NULL, NULL); Where does this prototype come from and why do we need this function in a first place?

2 2

Re: [PATCH] vbscript: Call GetItemInfo() with original item name
by Marvin 06 Nov '16

06 Nov '16

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=26469 Your paranoid android. === w1064 (64 bit) === run.c:190: Test failed: test.JS: L"WScript.FullName = " run.c:190: Test failed: test.JS: L"WScript.Path = "

1 0

Re: [PATCH 2/2] crypt32: importing system root certs into volatile registry keys instead of dedicated RootStore
by Jacek Caban 04 Nov '16

04 Nov '16

Hi Donat, The patch looks mostly good, I have just two final comments. On 10/28/16 5:16 PM, Donat Enikeev wrote: > -WINECRYPT_CERTSTORE *CRYPT_RootOpenStore(HCRYPTPROV hCryptProv, DWORD dwFlags) > +void CRYPT_ImportSystemRootCertsToReg(void) > { > - TRACE("(%ld, %08x)\n", hCryptProv, dwFlags); > + HCERTSTORE store = NULL; > + HKEY key; > + LONG rc; > + HANDLE mutex; > > - if (dwFlags & CERT_STORE_DELETE_FLAG) > + TRACE("\n"); > + > + mutex = CreateMutexW( NULL, FALSE, mutex_nameW); > + if (!mutex) There is a race in here. Sorry about wrong suggestion earlier, CreateSemaphore seems more appropriate here. If semaphore is already created, we need to wait for it to be satisfied. Otherwise we could try to read partially processed registries. > { > - WARN("root store can't be deleted\n"); > - SetLastError(ERROR_ACCESS_DENIED); > - return NULL; > + ERR("Failed to create mutex, %08x\n", GetLastError()); > + return; > } > - if (!CRYPT_rootStore) > + if ( GetLastError() == ERROR_ALREADY_EXISTS ) > + return; > + > + if (!(store = create_root_store())) > + return; > + > + rc = RegCreateKeyExW(HKEY_LOCAL_MACHINE, certs_root_pathW, 0, NULL, 0, KEY_ALL_ACCESS, NULL, &key, 0); > + if (!rc) > { > - HCERTSTORE root = create_root_store(); > + if (!CRYPT_SerializeContextsToReg(key, REG_OPTION_VOLATILE, pCertInterface, store)) > + WARN("Failed to import system certs into registry, %08x\n", GetLastError()); > > - InterlockedCompareExchangePointer((PVOID *)&CRYPT_rootStore, root, > - NULL); > - if (CRYPT_rootStore != root) > - CertCloseStore(root, 0); > + RegCloseKey(key); > } > - CRYPT_rootStore->vtbl->addref(CRYPT_rootStore); > - return CRYPT_rootStore; > -} > > -void root_store_free(void) > -{ > - CertCloseStore(CRYPT_rootStore, 0); > -} > + CertCloseStore(store, 0); > +} > \ No newline at end of file > diff --git a/dlls/crypt32/store.c b/dlls/crypt32/store.c > index 356712b..19eca22 100644 > --- a/dlls/crypt32/store.c > +++ b/dlls/crypt32/store.c > @@ -424,21 +424,15 @@ static WINECRYPT_CERTSTORE *CRYPT_SysRegOpenStoreW(HCRYPTPROV hCryptProv, > SetLastError(E_INVALIDARG); > return NULL; > } > - /* FIXME: In Windows, the root store (even the current user location) is > - * protected: adding to it or removing from it present a user interface, > - * and the keys are owned by the system process, not the current user. > - * Wine's registry doesn't implement access controls, so a similar > - * mechanism isn't possible yet. > - */ > - if ((dwFlags & CERT_SYSTEM_STORE_LOCATION_MASK) == > - CERT_SYSTEM_STORE_LOCAL_MACHINE && !lstrcmpiW(storeName, rootW)) > - return CRYPT_RootOpenStore(hCryptProv, dwFlags); > > switch (dwFlags & CERT_SYSTEM_STORE_LOCATION_MASK) > { > case CERT_SYSTEM_STORE_LOCAL_MACHINE: > root = HKEY_LOCAL_MACHINE; > base = CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH; > + /* If the HKLM\Root certs are requested, expressing system certs into the registry */ > + if (!lstrcmpiW(storeName, rootW)) > + CRYPT_ImportSystemRootCertsToReg(); I'm a bit nervous about implications of this patch. This will allow changing the store, which was not possible earlier. Let me explain. If user has sufficient rights: - On Windows: warning dialogs appear when application tries to modify root store. It's allowed, but only with user confirmation (which makes me think it's not a common way for installing new certs). - On current Wine: it's not allowed. - With your patch: it's allowed. Ideally we'd do what Windows does, but that's a separated issue. I'd propose to change the patch to simply behave like current Wine does in the regards. It should be as simple as: dwFlags |= CERT_STORE_READONLY_FLAG; Does that sounds good to you? Thanks, Jacek

2 5

Re: msvcirt: Avoid "array subscript above array bounds" warnings in test_ostrstream and test_strstreambuf.
by Piotr Caban 04 Nov '16

04 Nov '16

Hi, sorry for long reply time. On 10/30/16 14:55, Gerald Pfeifer wrote: > - ok(ssb1.base.ebuf == buffer + 0x7fffffff || ssb1.base.ebuf == (char*)-1, > + ok((size_t)ssb1.base.ebuf == (size_t)buffer + 0x7fffffff || ssb1.base.ebuf == (char*)-1, Is casting buffer to char* enough to get away with the warning? I think I would prefer it to be done this way if it works. I'm also not sure if this warning is useful. I don't see anything wrong in computing the pointer as long as it's not accessed. I guess it can't be disabled without also disabling some useful warnings? Thanks, Piotr

1 0

Re: [PATCH v2 2/7] winebus.sys: Implement removing IOHID devices
by Sebastian Lackner 04 Nov '16

04 Nov '16

2016-11-04 13:45 GMT+01:00 Aric Stewart <aric(a)codeweavers.com>: > > v2: Suggestions from Ken Thomases > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > I haven't reviewed the whole series yet, but the result of subtracting two ULONG_PTRs might not fit in an int return value.

1 0

Re: [v2 PATCH] vbscript: Implement StrComp()
by Marvin 04 Nov '16

04 Nov '16

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=26449 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH] vbscript: Implement StrComp()
by Dmitry Timoshkov 04 Nov '16

04 Nov '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + TRACE("(%s %s ...)\n", debugstr_variant(args), debugstr_variant(args+1)); > + > + assert(args_cnt == 2 || args_cnt == 3); > + > + if(V_VT(args) != VT_BSTR || V_VT(args+1) != VT_BSTR) { > + FIXME("args[0] = %s, args[1] = %s\n", debugstr_variant(args), debugstr_variant(args+1)); > + return E_NOTIMPL; > + } > + > + if (args_cnt == 3) { > + hres = to_int(args+2, &mode); > + if(FAILED(hres)) > + return hres; > + > + if (mode != 0 && mode != 1) { > + FIXME("unknown compare mode = %d\n", mode); > + return E_FAIL; > + } > + } > + else > + mode = 0; > + > + left = V_BSTR(args); > + right = V_BSTR(args+1); Is it possible to consistently use single way of accessing the args array, for instance the indexed args[i] form? -- Dmitry.

2 2

Re: [PATCH] vbscript: Implement StrComp()
by Jacek Caban 04 Nov '16

04 Nov '16

Hi Nikolay, The patch looks mostly good. On 04.11.2016 07:34, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/vbscript/global.c | 43 ++++++++++++++++++++++++++++++++++++++++--- > dlls/vbscript/tests/api.vbs | 15 +++++++++++++++ > 2 files changed, 55 insertions(+), 3 deletions(-) > > diff --git a/dlls/vbscript/global.c b/dlls/vbscript/global.c > index 129d6ce..a872838 100644 > --- a/dlls/vbscript/global.c > +++ b/dlls/vbscript/global.c > @@ -1027,10 +1027,47 @@ static HRESULT Global_MidB(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARI > return E_NOTIMPL; > } > > -static HRESULT Global_StrComp(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > +static HRESULT Global_StrComp(vbdisp_t *This, VARIANT *args, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + BSTR left, right; > + int mode, ret; > + HRESULT hres; > + > + TRACE("(%s %s ...)\n", debugstr_variant(args), debugstr_variant(args+1)); > + > + assert(args_cnt == 2 || args_cnt == 3); > + > + if(V_VT(args) != VT_BSTR || V_VT(args+1) != VT_BSTR) { > + FIXME("args[0] = %s, args[1] = %s\n", debugstr_variant(args), debugstr_variant(args+1)); > + return E_NOTIMPL; > + } > + > + if (args_cnt == 3) { > + hres = to_int(args+2, &mode); A test where mode arg is of other type would be nice. Something like "1" (passed as a string). > + if(FAILED(hres)) > + return hres; > + > + if (mode != 0 && mode != 1) { > + FIXME("unknown compare mode = %d\n", mode); > + return E_FAIL; > + } > + } > + else > + mode = 0; > + > + left = V_BSTR(args); > + right = V_BSTR(args+1); > + > + V_VT(res) = VT_I2; > + ret = mode ? strcmpiW(left, right) : strcmpW(left, right); > + if (ret < 0) > + V_I2(res) = -1; > + else if (ret > 0) > + V_I2(res) = 1; > + else > + V_I2(res) = 0; Please use return_short() helper here. Thanks, Jacek

1 0

Re: [PATCH] wscript: Do case insensitive check for WSH/WScript item names
by Jacek Caban 04 Nov '16

04 Nov '16

On 04.11.2016 06:36, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > For https://bugs.winehq.org/show_bug.cgi?id=41651 > > programs/wscript/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/wscript/main.c b/programs/wscript/main.c > index 3537f9d..e4bd676 100644 > --- a/programs/wscript/main.c > +++ b/programs/wscript/main.c > @@ -87,7 +87,7 @@ static HRESULT WINAPI ActiveScriptSite_GetItemInfo(IActiveScriptSite *iface, > { > WINE_TRACE("(%s %x %p %p)\n", wine_dbgstr_w(pstrName), dwReturnMask, ppunkItem, ppti); > > - if(strcmpW(pstrName, wshW) && strcmpW(pstrName, wscriptW)) > + if(strcmpiW(pstrName, wshW) && strcmpiW(pstrName, wscriptW)) > return E_FAIL; > > if(dwReturnMask & SCRIPTINFO_ITYPEINFO) { Looks good, but please add a test case. Thanks, Jacek

1 0

Re: [PATCH 1/3] dssenh/tests: The default container may already exist.
by Marvin 04 Nov '16

04 Nov '16

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=26439 Your paranoid android. === w864 (32 bit dssenh) === dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. === w1064 (32 bit dssenh) === dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. === w1064 (64 bit dssenh) === dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:642: Test failed: Incorrect decrypted data. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical. dssenh.c:1348: Test failed: Decrypted data is not identical.

2 1

Re: [PATCH 2/3] dssenh/tests: RC4 has been crippled in recent Windows versions.
by Marvin 04 Nov '16

04 Nov '16

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=26440 Your paranoid android. === w864 (32 bit dssenh) === dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. === w1064 (32 bit dssenh) === dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. === w1064 (64 bit dssenh) === dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical. dssenh.c:1349: Test failed: Decrypted data is not identical.

1 0

Re: [PATCH] vbscript: Implement StrComp()
by Marvin 04 Nov '16

04 Nov '16

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=26432 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH (resend) 3/8] winebus.sys: Implement removing IOHID devices
by Ken Thomases 04 Nov '16

04 Nov '16

On Nov 3, 2016, at 7:15 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index f3e282c..c25a3b8 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -120,7 +120,9 @@ static DWORD CFNumberToDWORD(CFNumberRef num) > > static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > { > - return 0; > + IOHIDDeviceRef dev1 = *(IOHIDDeviceRef*)get_platform_private(device); > + IOHIDDeviceRef dev2 = (IOHIDDeviceRef)platform_dev; > + return dev1 == dev2; The return value here has the reverse sense from how the caller interprets it. The caller, bus_find_hid_device(), interprets it like the result from strcmp() or memcmp(). A value of 0 means equal. Here, you're returning true (1) when the devices are equal. > }

1 1

Re: [PATCH (resend) 5/8] winebus.sys: IOCTL_HID_GET_STRING for iohid
by Ken Thomases 04 Nov '16

04 Nov '16

On Nov 3, 2016, at 7:15 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index 26243fb..6e3c044 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -88,6 +88,7 @@ > #include "winternl.h" > #include "winioctl.h" > #include "ddk/wdm.h" > +#include "ddk/hidtypes.h" > #include "wine/debug.h" > > #include "bus.h" > @@ -143,7 +144,28 @@ static NTSTATUS get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD > > static NTSTATUS get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length) > { > - return STATUS_NOT_IMPLEMENTED; > + IOHIDDeviceRef dev = *(IOHIDDeviceRef*)get_platform_private(device); > + CFStringRef str = NULL; It's not necessary to initialize str here. > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + str = IOHIDDeviceGetProperty(dev, CFSTR(kIOHIDProductKey)); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + str = IOHIDDeviceGetProperty(dev, CFSTR(kIOHIDManufacturerKey)); > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + str = IOHIDDeviceGetProperty(dev, CFSTR(kIOHIDSerialNumberKey)); > + break; > + default: > + ERR("Unknown string index\n"); > + return STATUS_NOT_IMPLEMENTED; > + } > + > + if (str) > + CFStringToWSTR(str, buffer, length); What if str is NULL? Should the function return a different result code, or should it set the caller's buffer to the empty string, or…? Certainly, it shouldn't just return success but leave the caller's buffer with junk. > + > + return STATUS_SUCCESS; > }

1 0

Re: [PATCH (resend) 2/8] winebus.sys: Implement adding IOHID devices
by Ken Thomases 04 Nov '16

04 Nov '16

On Nov 3, 2016, at 7:14 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_iohid.c | 102 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 101 insertions(+), 1 deletion(-) > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > index 882b483..f3e282c 100644 > --- a/dlls/winebus.sys/bus_iohid.c > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -98,14 +98,114 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > static DRIVER_OBJECT *iohid_driver_obj = NULL; > static IOHIDManagerRef hid_manager; > > +static const WCHAR busidW[] = {'I','O','H','I','D',0}; > + > +#include "initguid.h" > +DEFINE_GUID(GUID_DEVCLASS_IOHID, 0x989D309D,0x0470,0x4E1A,0x89,0x38,0x50,0x1F,0x42,0xBD,0x9A,0xCD); > + > +static void CFStringToWSTR(CFStringRef cstr, LPWSTR wstr, int length) > +{ > + int len = min(CFStringGetLength(cstr), length-1); > + CFStringGetCharacters(cstr, CFRangeMake(0, len), wstr); > + wstr[len] = 0; > +} > + > +static DWORD CFNumberToDWORD(CFNumberRef num) > +{ > + DWORD dwNum = 0; > + if (num) > + CFNumberGetValue(num, kCFNumberIntType, &dwNum); The local should be of type "int" to match kCFNumberIntType. > + return dwNum; > +} > + … > + > +static void handle_DeviceMatchingCallback(void *inContext, IOReturn inResult, void *inSender, IOHIDDeviceRef inIOHIDDeviceRef) > +{ > + DEVICE_OBJECT *device; > + DWORD vid, pid, version; > + CFStringRef str = NULL; > + WCHAR serial_string[256]; > + BOOL is_gamepad; > + > + TRACE("OS/X IOHID Device Added %p\n", inIOHIDDeviceRef); > + > + vid = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDVendorIDKey))); > + pid = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDProductIDKey))); > + version = CFNumberToDWORD(IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDVersionNumberKey))); > + str = IOHIDDeviceGetProperty(inIOHIDDeviceRef, CFSTR(kIOHIDSerialNumberKey)); > + if (str) CFStringToWSTR(str, serial_string, 256); You should use sizeof(serial_string) / sizeof(WCHAR) instead of 256 here. > + > + is_gamepad = (IOHIDDeviceConformsTo(inIOHIDDeviceRef, kHIDPage_GenericDesktop, kHIDUsage_GD_GamePad) || > + IOHIDDeviceConformsTo(inIOHIDDeviceRef, kHIDPage_GenericDesktop, kHIDUsage_GD_Joystick)); > + > + device = bus_create_hid_device(iohid_driver_obj, busidW, vid, pid, version, 0, str?serial_string:NULL, is_gamepad, &GUID_DEVCLASS_IOHID, &iohid_vtbl, sizeof(inIOHIDDeviceRef)); > + if (!device) > + ERR("Failed to create device\n"); > + else > + { > + IOHIDDeviceRef* ext = get_platform_private(device); > + *ext = inIOHIDDeviceRef; > + IoInvalidateDeviceRelations(device, BusRelations); > + } > +} > + > /* This puts the relevent run loop for event handleing into a WINE thread */ > static DWORD CALLBACK runloop_thread(VOID *args) > { > CFRunLoopRef run_loop; > > + DRIVER_OBJECT *driver = (DRIVER_OBJECT*)args; > run_loop = CFRunLoopGetCurrent(); Minor style nit: the variable declarations would normally be grouped and separated from statements. Of course, the declaration and setting of run_loop could be merged into one line (in the previous patch) to eliminate the distinction. > > IOHIDManagerSetDeviceMatching(hid_manager, NULL); > + IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, handle_DeviceMatchingCallback, driver); > IOHIDManagerScheduleWithRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > if (IOHIDManagerOpen( hid_manager, 0 ) != kIOReturnSuccess) > { > @@ -130,7 +230,7 @@ NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registr > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; > hid_manager = IOHIDManagerCreate(kCFAllocatorDefault, 0L); > - if (!(run_loop_handle = CreateThread(NULL, 0, runloop_thread, NULL, 0, NULL))) > + if (!(run_loop_handle = CreateThread(NULL, 0, runloop_thread, driver, 0, NULL))) > { > ERR("Failed to initialize IOHID Manager thread\n"); > iohid_driver_obj = NULL; > >

1 0

Re: [PATCH v2 1/8] winebus.sys: Add OS/X IOHID bus
by Ken Thomases 04 Nov '16

04 Nov '16

On Nov 3, 2016, at 7:14 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > > v2: remove Unload code as it will never be triggered > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/Makefile.in | 3 +- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_iohid.c | 151 +++++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 3 + > 4 files changed, 157 insertions(+), 1 deletion(-) > create mode 100644 dlls/winebus.sys/bus_iohid.c > > diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c > new file mode 100644 > index 0000000..882b483 > --- /dev/null > +++ b/dlls/winebus.sys/bus_iohid.c > @@ -0,0 +1,151 @@ … > + > +WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +#ifdef HAVE_IOHIDMANAGERCREATE > + > +static DRIVER_OBJECT *iohid_driver_obj = NULL; > +static IOHIDManagerRef hid_manager; > + > +/* This puts the relevent run loop for event handleing into a WINE thread */ Spelling: "relevant", "handling". > +static DWORD CALLBACK runloop_thread(VOID *args) > +{ > + CFRunLoopRef run_loop; > + > + run_loop = CFRunLoopGetCurrent(); > + > + IOHIDManagerSetDeviceMatching(hid_manager, NULL); > + IOHIDManagerScheduleWithRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > + if (IOHIDManagerOpen( hid_manager, 0 ) != kIOReturnSuccess) > + { > + ERR("Couldn't open IOHIDManager.\n"); > + IOHIDManagerUnscheduleFromRunLoop(hid_manager, run_loop, kCFRunLoopDefaultMode); > + CFRelease(hid_manager); > + return 0; > + } > + > + CFRunLoopRun(); > + TRACE("Run Loop exiting\n"); Under what circumstances might CFRunLoopRun() return (if any)? You should presumably unschedule the hid_manager from the run loop and release it in this path, too. > + return 1; > +} > + > +NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + HANDLE run_loop_handle; > + > + TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > + > + iohid_driver_obj = driver; > + driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; > + hid_manager = IOHIDManagerCreate(kCFAllocatorDefault, 0L); > + if (!(run_loop_handle = CreateThread(NULL, 0, runloop_thread, NULL, 0, NULL))) > + { > + ERR("Failed to initialize IOHID Manager thread\n"); > + iohid_driver_obj = NULL; You should CFRelease(hid_manager) in this failure path. > + return STATUS_UNSUCCESSFUL; > + } > + You should CloseHandle(run_loop_handle) before returning. > + return STATUS_SUCCESS; > +} > + > +#else > + > +NTSTATUS WINAPI iohid_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + WARN("IOHID Support not compiled into Wine.\n"); > + return STATUS_NOT_IMPLEMENTED; > +} > + > +#endif /* HAVE_IOHIDMANAGERCREATE */ > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 791ccbb..ed95435 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -628,10 +628,13 @@ NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > static UNICODE_STRING udev = {sizeof(udevW) - sizeof(WCHAR), sizeof(udevW), (WCHAR *)udevW}; > + static const WCHAR iohidW[] = {'\\','D','r','i','v','e','r','\\','I','O','H','I','D',0}; > + static UNICODE_STRING iohid = {sizeof(iohidW) - sizeof(WCHAR), sizeof(iohidW), (WCHAR *)iohidW}; > > TRACE( "(%p, %s)\n", driver, debugstr_w(path->Buffer) ); > > IoCreateDriver(&udev, udev_driver_init); > + IoCreateDriver(&iohid, iohid_driver_init); > > return STATUS_SUCCESS; > } In general, this patch is a bit weird in that it doesn't do anything. It could maybe be combined with the next one. *shrug* -Ken

1 0

Re: [PATCH 1/2] rpcrt4/tests: Extend the tests for NdrDllGetClassObject().
by Marvin 03 Nov '16

03 Nov '16

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=26418 Your paranoid android. === w1064 (32 bit cstub) === cstub: unhandled exception c0000005 at 76CF3DFD === w864 (64 bit cstub) === cstub: unhandled exception c0000005 at 00007FFB7D5E2A12 === w1064 (64 bit cstub) === cstub: unhandled exception c0000005 at 00007FFC79AEDBF3

2 1

Re: [PATCH 2/5] d3d8/tests: Port test_check_device_format() from d3d9.
by Marvin 03 Nov '16

03 Nov '16

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=26400 Your paranoid android. === w8 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2794: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2799: Test failed: The focus window is active. device.c:2807: Test failed: Got unexpected hr 0x88760869. device.c:2811: Test failed: Got unexpect screen size 800x600. device.c:2826: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2835: Test failed: Got unexpect screen size 800x600. device.c:2848: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2856: Test failed: Got unexpect width 640. device.c:2857: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 1/5] d3d9/tests: Add test for checking buffer resource format support.
by Marvin 03 Nov '16

03 Nov '16

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=26399 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

1 0

Re: libs/wine: give user an error message if WINEARCH is not win32/win64 (try 2)
by Austin English 03 Nov '16

03 Nov '16

On Sun, Oct 16, 2016 at 5:57 AM, Jens Reyer <jre.winesim(a)gmail.com> wrote: > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > > lgtm and tested successfully. Thanks! Could I get some feedback or a reviewer assigned please? This has sat for a few weeks with a second signed-off but no other activity and it's close to dropping off of the tracker. -- -Austin GPG: 14FB D7EA A041 937B

1 0

old Windows API books
by Marcus Meissner 02 Nov '16

02 Nov '16

Hi folks, On reducing my library I found two Windows books I want to get rid of, with information that is not just in MSDN. Matt Pietrek - Windows 95 System Programming Secrets, including original Floppy Disk. Seems that has a lot of lowlevel details. Andrew Schulman - Unauthorized Windows 95 (in german language) Not so many details, looks less interesting on paging through. Is anyone interested in those? I could bring them to wineconf. Ciao, Marcus

1 0

Re: [v2 PATCH 2/2] gdiplus: Implement GdipBitmapGetHistogram()
by Vincent Povirk 02 Nov '16

02 Nov '16

> +static void set_histogram_point_gray(ARGB color, UINT *ch0, UINT *ch1, UINT *ch2, UINT *ch3) > +{ > + ch0[(76 * ((color >> 16) & 0xff) + 150 * ((color >> 8) & 0xff) + 28 * (color & 0xff)) / 0xff]++; > +} Shouldn't the multipliers add up to 255 here?

2 1

Re: [PATCH 1/2] crypt32/tests: testing priorities and flags of stores in a collection; and whether certs are saved in registry endpoint
by Jacek Caban 02 Nov '16

02 Nov '16

Hi Donat, Sorry it took a while, I wanted to do some testing myself before reviewing. Patches look mostly good to me, I have a few comments. On 10/28/16 5:15 PM, Donat Enikeev wrote: > Superceeds: https://source.winehq.org/patches/data/127162 > > v1: > Test of priorities and flags of stores in a collection > v2: > Test whether certificates are actually saved in the registry for the most common pathes and one todo for HLCU\My saved in the AppData > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > --- > dlls/crypt32/tests/Makefile.in | 2 +- > dlls/crypt32/tests/store.c | 288 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 289 insertions(+), 1 deletion(-) > > diff --git a/dlls/crypt32/tests/Makefile.in b/dlls/crypt32/tests/Makefile.in > index d84ca17..d96ad1c 100644 > --- a/dlls/crypt32/tests/Makefile.in > +++ b/dlls/crypt32/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = crypt32.dll > -IMPORTS = crypt32 advapi32 > +IMPORTS = crypt32 advapi32 user32 shlwapi shell32 > > C_SRCS = \ > base64.c \ > diff --git a/dlls/crypt32/tests/store.c b/dlls/crypt32/tests/store.c > index e811fbe..7fedaa4 100644 > --- a/dlls/crypt32/tests/store.c > +++ b/dlls/crypt32/tests/store.c > @@ -23,6 +23,9 @@ > > #include <windef.h> > #include <winbase.h> > +#include <winuser.h> > +#include <shlobj.h> > +#include <shlwapi.h> > #include <winreg.h> > #include <winerror.h> > #include <wincrypt.h> > @@ -347,6 +350,287 @@ static const BYTE serializedStoreWithCert[] = { > 0x08,0x30,0x06,0x01,0x01,0xff,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00, > 0x00,0x00,0x00,0x00,0x00,0x00 }; > > +static const struct > +{ > + HKEY key; > + DWORD cert_store; > + BOOL todo_appdata_file; Please remove todo_ part of the name. > + WCHAR store_name[MAX_PATH]; MAX_PATH does not make much sense. I believe that hardcoding the size to a small number would be better here. If there is an overflow, compiler will warn about that anyway. > + LPCWSTR base_reg_path; const WCHAR * instead of LPCWSTR in new code would be slightly preferable. > +} reg_store_saved_certs[] = { > + { HKEY_LOCAL_MACHINE, CERT_SYSTEM_STORE_LOCAL_MACHINE, FALSE, > + {'R','O','O','T',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH }, > + { HKEY_LOCAL_MACHINE, CERT_SYSTEM_STORE_LOCAL_MACHINE, FALSE, > + {'M','Y',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH }, > + { HKEY_LOCAL_MACHINE, CERT_SYSTEM_STORE_LOCAL_MACHINE, FALSE, > + {'C','A',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH }, > + /* Adding to HKCU\Root triggers safety warning dialog at least on Win764 */ > + /* { HKEY_CURRENT_USER, CERT_SYSTEM_STORE_CURRENT_USER, > + {'R','O','O','T',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH }, */ > + { HKEY_CURRENT_USER, CERT_SYSTEM_STORE_CURRENT_USER, TRUE, > + {'M','Y',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH }, > + { HKEY_CURRENT_USER, CERT_SYSTEM_STORE_CURRENT_USER, FALSE, > + {'C','A',0}, CERT_LOCAL_MACHINE_SYSTEM_STORE_REGPATH } > +}; > + > +/* Testing whether system stores are available for adding new certs > + * and checking directly in the registry whether they are actually saved or deleted. > + * However, by the moment Windows treats HKCU\My (at least) as a special case, > + * and uses AppData directory for storing certs, not registry > + * @see additionally testRegStore() verifying a content of read/saved certs > + */ > +static void testRegStoreSavedCerts(void) > +{ > + static const WCHAR fmt[] = > + { '%','s','\\','%','s','\\','%','s','\\','%','s',0}, > + ms_certs[] = > + { 'M','i','c','r','o','s','o','f','t','\\','S','y','s','t','e','m','C','e','r','t','i','f','i','c','a','t','e','s',0}, > + certs[] = > + {'C','e','r','t','i','f','i','c','a','t','e','s',0}, > + bigCert_hash[] = { > + '6','E','3','0','9','0','7','1','5','F','D','9','2','3', > + '5','6','E','B','A','E','2','5','4','0','E','6','2','2', > + 'D','A','1','9','2','6','0','2','A','6','0','8',0}; > + PCCERT_CONTEXT cert1, cert2; > + HCERTSTORE store; > + HANDLE cert_file; > + HRESULT pathres; > + WCHAR key_name[MAX_PATH], appdata_path[MAX_PATH]; > + HKEY key; > + BOOL ret; > + DWORD res,i; > + > + for (i = 0; i < sizeof(reg_store_saved_certs) / sizeof(reg_store_saved_certs[0]); i++) > + { > + store = CertOpenStore(CERT_STORE_PROV_SYSTEM_REGISTRY_W,0,0, > + reg_store_saved_certs[i].cert_store, reg_store_saved_certs[i].store_name); > + if (!store) > + { > + win_skip("Insufficient privileges for the test %d, skipping\n", i); > + continue; This should be skip() instead of win_skip(). Once Wine will implement access rights, it will hit that skip as well. I think that this skip is valid only in local machine store, current user should always have sufficient rights, it should be expressed here to make tests more strict. Also, testing GetLastError() in this branch would be nice. Thanks, Jacek

1 0

Re: [PATCH 2/2] gdiplus: Implement GdipBitmapGetHistogram()
by Vincent Povirk 01 Nov '16

01 Nov '16

> + ok(ch1[0x3f] == WIDTH, "Got green (0x3f) %u\n", ch1[0x3f]); > + ok(ch2[0x20] == WIDTH, "Got blue (0x20) %u\n", ch1[0x20]); > + > +return; > + > + /* ARGB histogram from RGB data. */ > + stat = pGdipBitmapGetHistogram(bm, HistogramFormatARGB, 256, ch0, ch1, ch2, NULL); > + expect(InvalidParameter, stat); That return doesn't look like it's supposed to be there.

2 1

Re: [PATCH] ws2_32: Fix the default behavior of IPV6_V6ONLY
by Marvin 01 Nov '16

01 Nov '16

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=26345 Your paranoid android. === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFF126F94

3 2

Re: [PATCH 2/2] gdiplus: Implement GdipBitmapGetHistogram()
by Dmitry Timoshkov 01 Nov '16

01 Nov '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + for (x = 0; x < width; x++) > + for (y = 0; y < height; y++) > + { > + ARGB color; > + > + GdipBitmapGetPixel(bitmap, x, y, &color); > + set_histogram_point[format](color, ch0, ch1, ch2, ch3); > + } > + > + return Ok; > +} One of the very least things that could be done about this very ineffecient implementation is to make the width traversing an inner loop. -- Dmitry.

1 0

Re: wined3d: Add ARB_texture_env_crossbar extension.
by Henri Verbeet 01 Nov '16

01 Nov '16

This isn't very useful on its own. Do you intend to use the extension for something?

1 0

d3dx9: d3dx9_base_effect_get_pass_desc
by Luis C. Busquets Pérez 31 Oct '16

31 Oct '16

Dear developers, I have tried to run Civ4BeyondtheSword.exe with the internal d3dx9_33.dll I can run the programme but when I start a game, it hangs. I saw that a lot of FIXME's with the message: fixme:d3dx:d3dx9_base_effect_get_pass_desc Pixel shader and vertex shader are not supported, yet. Therefore, I tried to finishing implementing the function. Find below a patch that works. With this patch, the programme does not hang. Fell free to study, redo it or rewrite it but please I look forward to somebody who corrects it and manages to integrate that function in the wine tree so that I do not need to compile the wine. On the other hand, the settler image seems to something in the middle. Furthermore, the leaders also seem to have something in the middle. Actually, it seems that the image that should be behind the leader in the bottom is in the middle of them and bend vertically when they bend. I assume this is not because of the patch but I guess that this information could serve to locate and correct another bug. --- dlls/d3dx9_36/effect.c | 46 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c index 42f5aea..c69b73c 100644 --- a/dlls/d3dx9_36/effect.c +++ b/dlls/d3dx9_36/effect.c @@ -150,6 +150,7 @@ struct d3dx9_base_effect UINT parameter_count; UINT technique_count; UINT object_count; + BOOL clonable; struct d3dx_parameter *parameters; struct d3dx_technique *techniques; @@ -999,6 +1000,11 @@ static HRESULT d3dx9_base_effect_get_pass_desc(struct d3dx9_base_effect *base, D3DXHANDLE pass, D3DXPASS_DESC *desc) { struct d3dx_pass *p = get_valid_pass(base, pass); + struct d3dx_state *s; + struct d3dx_parameter *param; + IDirect3DVertexShader9 *vshader; + IDirect3DPixelShader9 *pshader; + UINT i, size; if (!desc || !p) { @@ -1008,11 +1014,45 @@ static HRESULT d3dx9_base_effect_get_pass_desc(struct d3dx9_base_effect *base, desc->Name = p->name; desc->Annotations = p->annotation_count; - - FIXME("Pixel shader and vertex shader are not supported, yet.\n"); desc->pVertexShaderFunction = NULL; desc->pPixelShaderFunction = NULL; + if (base->clonable) + { + for (i=0; i < p->state_count; i++) + { + s = p->states + i; + if (state_table[s->operation].class == SC_VERTEXSHADER) + { + param = &(s->parameter); + vshader = *(struct IDirect3DVertexShader9 **)param- >data; + if (vshader) + { + IDirect3DVertexShader9_GetFunction(vshader, NULL, &size); + if (desc->pVertexShaderFunction) + free((void *)desc->pVertexShaderFunction); + desc->pVertexShaderFunction = malloc(size); + IDirect3DVertexShader9_GetFunction(vshader, (void *)(desc->pVertexShaderFunction), &size); + } + } + if (state_table[s->operation].class == SC_PIXELSHADER) + { + param = &(s->parameter); + pshader = *(struct IDirect3DPixelShader9 **)param- >data; + if (pshader) + { + IDirect3DPixelShader9_GetFunction(pshader, NULL, &size); + if (desc->pPixelShaderFunction) + free((void *)desc->pPixelShaderFunction); + desc->pPixelShaderFunction = malloc(size); + IDirect3DPixelShader9_GetFunction(pshader, (void *)(desc->pPixelShaderFunction), &size); + } + } + } + } + + TRACE("Pass '%s': %i annots. Vertexshader %p and Pixelshader %p\n", desc->Name, desc->Annotations, desc->pVertexShaderFunction, desc->pPixelShaderFunction); + return D3D_OK; } @@ -5955,6 +5995,8 @@ static HRESULT d3dx9_base_effect_init(struct d3dx9_base_effect *base, base->effect = effect; + base->clonable = TRUE; + read_dword(&ptr, &tag); TRACE("Tag: %x\n", tag); -- 2.7.4

4 4

Re: [PATCH 7/7] ddraw: Fix remaining style issues in executebuffer.c
by Henri Verbeet 31 Oct '16

31 Oct '16

On 30 October 2016 at 15:02, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Feel free to ignore this. With this the file follows the wined3d style, > unless I missed something... > +static void _dump_executedata(const D3DEXECUTEDATA *lpData) Naming conventions for "_dump_executedata" and "lpData". > TRACE("dwSize : %d\n", lpData->dwSize); %u for unsigned integers, punctuation. > -static void _dump_D3DEXECUTEBUFFERDESC(const D3DEXECUTEBUFFERDESC *lpDesc) { > +static void _dump_D3DEXECUTEBUFFERDESC(const D3DEXECUTEBUFFERDESC *lpDesc) > +{ > TRACE("dwSize : %d\n", lpDesc->dwSize); Likewise. > TRACE("dwFlags : %x\n", lpDesc->dwFlags); %#x for hexadecimal values. > @@ -76,12 +78,12 @@ HRESULT d3d_execute_buffer_execute(struct d3d_execute_buffer *buffer, > for (;;) > { > D3DINSTRUCTION *current = (D3DINSTRUCTION *)instr; Should probably be const. > - BYTE size; > - WORD count; > - > - count = current->wCount; > - size = current->bSize; > - instr += sizeof(D3DINSTRUCTION); > + BYTE size; > + WORD count; > + > + count = current->wCount; > + size = current->bSize; > + instr += sizeof(D3DINSTRUCTION); "sizeof(*current)" > instr = (char*)current + ci->dwOffset; "(char *)" > + default: > + ERR("Unhandled OpCode %d !!!\n",current->bOpcode); Should probably use %#x. Punctuation. Some of these probably deserve a patch on their own, and there may very well be more issues.

1 0

Re: [PATCH 6/7] ddraw: Implement executebuffer point and line draws.
by Henri Verbeet 31 Oct '16

31 Oct '16

On 30 October 2016 at 15:02, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > case D3DOP_TRIANGLE: > { > WORD *indices; > - unsigned int index_pos = buffer->index_pos; > + unsigned int index_pos = buffer->index_pos, num_indices; Since you're doing style cleanups in the next patch, "index_count".

1 0

Re: [PATCH] wined3d: Invalidate INDEXBUFFER device state when contents of bound index buffer is changed.
by Henri Verbeet 31 Oct '16

31 Oct '16

On 28 October 2016 at 12:20, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (buffer->resource.bind_count) > + { > + if (buffer->buffer_type_hint == GL_ELEMENT_ARRAY_BUFFER) > + device_invalidate_state(buffer->resource.device, STATE_INDEXBUFFER); > + } You can merge those if-conditions. What happens exactly that makes this required?

2 3

Re: [PATCH 2/7] ddraw: Use wined3d_device_process_vertices for execute buffers.
by Henri Verbeet 31 Oct '16

31 Oct '16

On 30 October 2016 at 15:02, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -318,65 +277,36 @@ HRESULT d3d_execute_buffer_execute(struct d3d_execute_buffer *buffer, > + hr = wined3d_resource_map(wined3d_buffer_get_resource(buffer->src_vertex_buffer), 0, > + &map_desc, &box, WINED3D_MAP_DISCARD); > if (FAILED(hr)) > return hr; > - dst = map_desc.data; > + memcpy(map_desc.data, src, ci->dwCount * sizeof(*src)); > + wined3d_resource_unmap(wined3d_buffer_get_resource(buffer->dst_vertex_buffer), 0); That looks wrong.

1 0

RE: [PATCH] xinput1_3: Prefer builtin DLL
by Filip Frackiewicz 30 Oct '16

30 Oct '16

Hi Bruno, I hope I am not intruding or stating something already known,,, >- case DLL_WINE_PREATTACH: >- return FALSE; /* prefer native version */ case DLL_PROCESS_ATTACH: DisableThreadLibraryCalls(inst); break; This code looks different than the patch https://bugs.winehq.org/attachment.cgi?id=55851 attached to https://bugs.winehq.org/show_bug.cgi?id=41428 The patch attached to the bug did fix the issue in another game for me. Just thought I'd mention this just in case :) Cheers, Filip

2 2

Re: [PATCH 6/7] ddraw: Implement executebuffer point and line draws.
by Stefan Dösinger 30 Oct '16

30 Oct '16

Am 2016-10-30 um 07:02 schrieb Stefan Dösinger: > + case D3DOP_LINE: > + primitive_size = 2; > + wined3d_device_set_primitive_type(device->wined3d_device, WINED3D_PT_LINELIST); I should probably mention the purpose of this patch: It fixes the minimap and bike performance display in Moto Racer 2.

1 0

Imort system certificates in crypt32@Wine
by Donat Enikeev 28 Oct '16

28 Oct '16

2 6

Re: [PATCH] d2d1: Use transformed geometry to translate glyph run outline
by Henri Verbeet 28 Oct '16

28 Oct '16

On 28 October 2016 at 13:23, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d2d1/render_target.c | 27 +++++++++++++++++++-------- > 1 file changed, 19 insertions(+), 8 deletions(-) > This is probably fine, but why would you want to do that?

2 1

Re: [v2 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch
by Huw Davies 28 Oct '16

28 Oct '16

On Fri, Oct 28, 2016 at 01:43:19PM +0300, Nikolay Sivov wrote: > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 432d5c7..37e5ece 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -2144,9 +2144,10 @@ static int check_bom(HANDLE h, int oflags, BOOL seek) > } > > /********************************************************************* > - * _wsopen_s (MSVCRT.@) > + * _wsopen_dispatch (UCRTBASE.@) > */ > -int CDECL MSVCRT__wsopen_s( int *fd, const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode ) > +int CDECL MSVCRT__wsopen_dispatch( const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode, > + int *fd, int secure ) > { > DWORD access = 0, creation = 0, attrib; > SECURITY_ATTRIBUTES sa; You probably want to add 'secure' to the TRACE() just below here and change the order of the parameters in that TRACE() to match the new function. Huw.

3 3

Re: [v3 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch
by Huw Davies 28 Oct '16

28 Oct '16

Signed-off-by: Huw Davies <huw(a)codeweavers.com>

1 0

Re: [PATCH] winebus.sys: Remove dead code
by Sebastian Lackner 28 Oct '16

28 Oct '16

It is dead code, but I don't think putting it in a comment makes it better. In general, commented out code should be avoided because it is not checked by the compiler. In addition, we might want to implement driver unloading in the near future, and will have to add the code back then (including the "if" because failures to create the monitor are not critical). 2016-10-28 3:00 GMT+02:00 Aric Stewart <aric(a)codeweavers.com>: > > Coverity 1373717 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > >

2 1

Cmd.exe test cases
by Carlos Rafael Ramirez 28 Oct '16

28 Oct '16

Hello, I want to add some test cases to cmd program. But I don't understand the structure of them. Where to put the command and where to put the assertion or expected output? I am coding a patch and I want to make it like TDD, first the test fail and after the fix the test passes. Thank you

2 1

Re: [3/3] hidclass.sys: Only return new reports when reading data from ringbuffer.
by Aric Stewart 27 Oct '16

27 Oct '16

On 10/27/16 9:45 AM, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Depending on the buffer size, we might get a huge amount of old reports otherwise. > > @ Aric: I believe there are some more things wrong with the ringbuffer implementation. > We shouldn't really need a ->start pointer, this is exactly what the ring->pointers[] > are used for. Also, the current implementation never uses all slots. > Reviews on the ringbuffer code is very welcome! Thanks! It has been a while since I did that implementation but if I recall the purpose for start and end is about tracking the writing positions, It was more important before this patch, but after this patch you are correct that start is no longer needed. 2 -aric > dlls/hidclass.sys/buffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 14e83e4..0b29f97 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -170,7 +170,7 @@ UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > for( ;count < ring->pointer_alloc; count++) > ring->pointers[count] = POINTER_UNUSED; > } > - ring->pointers[idx] = ring->start; > + ring->pointers[idx] = ring->end; > LeaveCriticalSection(&ring->lock); > return idx; > } >

1 0

Re: [PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch
by Huw Davies 27 Oct '16

27 Oct '16

On 27 Oct 2016, at 17:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 432d5c7..9097598 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -2330,6 +2330,18 @@ int CDECL MSVCRT__wsopen( const MSVCRT_wchar_t *path, int oflags, int shflags, . > } > > /********************************************************************* > + * _wsopen_dispatch (UCRTBASE.@) > + */ > +int CDECL MSVCRT__wsopen_dispatch( const MSVCRT_wchar_t *path, int oflags, int shflags, > + int pmode, int *filehandle, int secure) > +{ > + if (secure) > + FIXME("secure argument ignored.\n"); > + > + return MSVCRT__wsopen_s( filehandle, path, oflags, shflags, pmode ); > +} Wouldn’t it make more sense to have _wsopen() and _wsopen_s() call _wsopen_dispatch() (and likewise for the char* version)? Huw.

1 0

Re: ntdll: Add ApiSetQueryApiSetPresence stub.
by Nikolay Sivov 27 Oct '16

27 Oct '16

Do you have a program that needs this?

1 0

Re: ntdll: Forward EtwEventRegister() from EventRegister().
by Nikolay Sivov 27 Oct '16

27 Oct '16

> --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -41,6 +41,7 @@ > # @ stub DbgUiStopDebugging > @ stub DbgUiWaitStateChange > @ stdcall DbgUserBreakPoint() > +@ stdcall EtwEventRegister(ptr ptr ptr ptr) advapi32.EventRegister This won't do it. Advapi32 should forward to ntdll, not the other way around.

1 0

Re: [PATCH 1/2] edit: Test that EM_REPLACESEL works after EM_GETHANDLE.
by Sebastian Lackner 26 Oct '16

26 Oct '16

On 27.10.2016 00:41, Roman Pišl wrote: > Signed-off-by: Roman Pišl <rpisl(a)seznam.cz> > --- > dlls/user32/tests/edit.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) I haven't reviewed the patch yet, but please note that the subject should start with the component (here user32), not with the filename. It was also wrong in http://source.winehq.org/git/wine.git/patch/ddfc5275af0081cba6e834bf9d9e35d…, but seems like Alexandre didn't notice it. ;) Best regards, Sebastian

1 0

d3dx9: d3dx9_base_effect_get_pass_desc
by Luis C. Busquets Pérez 26 Oct '16

26 Oct '16

Dear developers, I have tried to run Civ4BeyondtheSword.exe with the internal d3dx9_33.dll I can run the programme but when I start a game, it hangs. I saw that a lot of FIXME's with the message: fixme:d3dx:d3dx9_base_effect_get_pass_desc Pixel shader and vertex shader are not supported, yet. Therefore, I tried to finishing implementing the function. Find attached a patch that works. With this patch, the programme does not hang. Fell free to study, redo it or rewrite it but please I look forward to somebody who corrects it and manages to integrate that function in the wine tree so that I do not need to compile the wine. On the other hand, find attached an image, where you can see that the settler image seems to something in the middle. Furthermore, the leaders also seem to have something in the middle. Actually, it seems that the image that should be behind the leader in the bottom is in the middle of them and bend vertically when they bend. I assume this is not because of the patch but I guess that this information could serve to locate and correct another bug.

1 0

Re: [PATCH] hid: implement HidD_SetOutputReport
by Sebastian Lackner 26 Oct '16

26 Oct '16

On 24.10.2016 16:06, Aric Stewart wrote: > Also fixes an issue with IOCTL_HID_SET_FEATURE where the wrong buffers where being sent. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hid/hid.spec | 2 +- > dlls/hid/hidd.c | 6 ++++++ > dlls/hidclass.sys/device.c | 11 +++++++---- > include/ddk/hidsdi.h | 1 + > 4 files changed, 15 insertions(+), 5 deletions(-) > While you are just at it, shouldn't the first char in SystemBuffer be skipped? "packet.reportBuffer = irp->AssociatedIrp.SystemBuffer;" Also, it looks like the first assignment of "irp->IoStatus.Information = 0;" is not really required, its also assigned later. Regards, Sebastian

1 0

Re: [6/6] webservices: Implement WsCall.
by Marvin 26 Oct '16

26 Oct '16

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

1 0

Re: [PATCH 1/4] d2d1: Implement FillContainsPoint for rectangles
by Nikolay Sivov 26 Oct '16

26 Oct '16

On Fri, Oct 21, 2016 at 7:28 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > + *contains = probe.x > geometry->u.rectangle.rect.left - tolerance && > + probe.x < geometry->u.rectangle.rect.right + tolerance && > + probe.y > geometry->u.rectangle.rect.top - tolerance && > + probe.y < geometry->u.rectangle.rect.bottom + tolerance; > + > Does it really work like that? I'd expect tolerance to be irrelevant for paths constructed purely from lines. So basically in general case path is approximated with lines (or enclosed area with triangles) with given tolerance, and then point is tested against this flattened path. While in rectangular case it's already flat to begin with.

2 1

Product Registration Bug
by Jonathan Allen 25 Oct '16

25 Oct '16

Dear List, Do we have any movement on bug 29354? I'm trying to move to an all-Linux environment and am blocked on two (old, venerable) XP (but not MS) applications that go to sleep in the ... fixme:msi:msi_validate_product_id partial stud: template ... ... code and can't move beyond that point. Completely stuck - help! Jonathan

1 0

Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.
by Sebastian Lackner 25 Oct '16

25 Oct '16

On 19.10.2016 19:05, Jacek Caban wrote: > v2: Don't store async queues in a list. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > server/async.c | 34 +++++++++++++++++++++++++++++++++ > server/device.c | 58 > +++++++++++++++++++++++++-------------------------------- > server/file.h | 14 ++++++++++++++ > 3 files changed, 73 insertions(+), 33 deletions(-) > I'm not sure if Alexandre has already agreed to this approach, but from my point of view it would make sense to do some measurements. How fast is the proposed named pipe approach compared to alternatives (unpatched Wine, or the Linux-only implementation included in Wine Staging)? In general I like the idea, but I fear that adding significant optimizations afterwards will be very difficult. Regards, Sebastian

3 6

Re: Polish translation
by Nikolay Sivov 25 Oct '16

25 Oct '16

On 24.10.2016 21:55, m4sk1n wrote: > Here is translated .po file from my GlotPress. Hope it will be used. > Hi. Thank you for your contribution. Translations should be submitted as regular patches, generated using git format-patch or similar. Also make sure to use your real name when submitting.

1 0

Testing: gcc -foutline-msabi-xlogues patch
by Daniel Santos 24 Oct '16

24 Oct '16

I've been working on a gcc patch targeting 64-bit Wine to reduce the impact of the implicit register clobbers when a Microsoft's x64 function calls a System V ABI function and I appear to finally have a working implementation. However, I cannot get recent Wine tests to complete with an unpatched compiler (I have 30 failures, 4 which are crashes and I even get some dmesgs from drivers.) While the same Wine tests pass both with and without the new optimization, I could use some external testing to make sure there's no flaws that I've missed (especially a full test with no failures). The patch set is not actually complete as my unit tests didn't catch many of the flaws (now fixed) that I caught when building real Wine, so I'm re-working them. I have my current version up on github: https://github.com/daniel-santos/gcc/tree/gcc-5_4_0-outline-msabi-xlogues. Background For those unfamiliar, the differences between the two ABIs requires an ms_abi function to save and restore 12 registers: RSI, RDI and XMM6-15. The size of pushing/popping RSI and RDI is insignificant, but saving and restoring 10 SSE registers takes between 94 and 174 bytes each function (dependent upon the SP offset), thereby bloating ".text" size quite a bit. Details This patch uses out-of-line stubs for register for saves/restores to reduce .text size. The *theory* (not yet proven) is that the reduction of instruction cache misses will offset the extra few instructions required to facilitate this. But while we're going this far, the optimization also saves/restores an additional 6 non-volatile ms_abi registers if they are clobbered in the function: RBX, RBP and R12-15. This extra step actually saves very little ".text" code, but the stub implements them using MOVs which the CPU is better able to parallelize. While MOV instructions are larger (4 bytes vs 1 or 2), they only appear in the stubs, theoretically gaining the performance benefits of MOVs without paying for the cost of the extra size. This optimization works both with and without forced stack realignment (https://bugs.winehq.org/show_bug.cgi?id=27680), although more can be done to produce better code in the realigned case. In the forced realignment case, this optimization reduces .text size Wine 64 by 19% and in the normal (aligned stack) case by 22%. As an example, here is a test function (with stubs) built with -foutline-msabi-xlogues (but no realignment): __attribute__ ((noinline)) long sysv_fn0 () { return 42; } __attribute__ ((ms_abi, noinline)) long msabifn0_6 () { __asm__ __volatile__ ("" ::: "rbx", "rbp", "r12", "r13", "r14", "r15"); return sysv_fn0 (); } 0000000000401000 <msabifn0_6>: 401000: 48 8d 44 24 88 lea -0x78(%rsp),%rax 401005: 48 81 ec f8 00 00 00 sub $0xf8,%rsp 40100c: e8 09 e8 01 00 callq 41f81a <__msabi_save_18> 401011: 31 c0 xor %eax,%eax 401013: e8 48 fc ff ff callq 400c60 <sysv_fn0> 401018: 48 8d b4 24 80 00 00 lea 0x80(%rsp),%rsi 40101f: 00 401020: 4c 8d 56 78 lea 0x78(%rsi),%r10 401024: e9 41 e8 01 00 jmpq 41f86a <__msabi_restore_ret_18> 000000000041f81a <__msabi_save_18>: 41f81a: 4c 89 78 90 mov %r15,-0x70(%rax) 000000000041f81e <__msabi_save_17>: 41f81e: 4c 89 70 98 mov %r14,-0x68(%rax) 000000000041f822 <__msabi_save_16>: 41f822: 4c 89 68 a0 mov %r13,-0x60(%rax) 000000000041f826 <__msabi_save_15>: 41f826: 4c 89 60 a8 mov %r12,-0x58(%rax) 000000000041f82a <__msabi_save_14>: 41f82a: 48 89 68 b0 mov %rbp,-0x50(%rax) 000000000041f82e <__msabi_save_13>: 41f82e: 48 89 58 b8 mov %rbx,-0x48(%rax) 000000000041f832 <__msabi_save_12>: 41f832: 48 89 78 c0 mov %rdi,-0x40(%rax) 41f836: 48 89 70 c8 mov %rsi,-0x38(%rax) 41f83a: 44 0f 29 78 d0 movaps %xmm15,-0x30(%rax) 41f83f: 44 0f 29 70 e0 movaps %xmm14,-0x20(%rax) 41f844: 44 0f 29 68 f0 movaps %xmm13,-0x10(%rax) 41f849: 44 0f 29 20 movaps %xmm12,(%rax) 41f84d: 44 0f 29 58 10 movaps %xmm11,0x10(%rax) 41f852: 44 0f 29 50 20 movaps %xmm10,0x20(%rax) 41f857: 44 0f 29 48 30 movaps %xmm9,0x30(%rax) 41f85c: 44 0f 29 40 40 movaps %xmm8,0x40(%rax) 41f861: 0f 29 78 50 movaps %xmm7,0x50(%rax) 41f865: 0f 29 70 60 movaps %xmm6,0x60(%rax) 41f869: c3 retq 000000000041f86a <__msabi_restore_ret_18>: 41f86a: 4c 8b 7e 90 mov -0x70(%rsi),%r15 000000000041f86e <__msabi_restore_ret_17>: 41f86e: 4c 8b 76 98 mov -0x68(%rsi),%r14 000000000041f872 <__msabi_restore_ret_16>: 41f872: 4c 8b 6e a0 mov -0x60(%rsi),%r13 000000000041f876 <__msabi_restore_ret_15>: 41f876: 4c 8b 66 a8 mov -0x58(%rsi),%r12 000000000041f87a <__msabi_restore_ret_14>: 41f87a: 48 8b 6e b0 mov -0x50(%rsi),%rbp 000000000041f87e <__msabi_restore_ret_13>: 41f87e: 48 8b 5e b8 mov -0x48(%rsi),%rbx 000000000041f882 <__msabi_restore_ret_12>: 41f882: 48 8b 7e c0 mov -0x40(%rsi),%rdi 41f886: 44 0f 28 7e d0 movaps -0x30(%rsi),%xmm15 41f88b: 44 0f 28 76 e0 movaps -0x20(%rsi),%xmm14 41f890: 44 0f 28 6e f0 movaps -0x10(%rsi),%xmm13 41f895: 44 0f 28 26 movaps (%rsi),%xmm12 41f899: 44 0f 28 5e 10 movaps 0x10(%rsi),%xmm11 41f89e: 44 0f 28 56 20 movaps 0x20(%rsi),%xmm10 41f8a3: 44 0f 28 4e 30 movaps 0x30(%rsi),%xmm9 41f8a8: 44 0f 28 46 40 movaps 0x40(%rsi),%xmm8 41f8ad: 0f 28 7e 50 movaps 0x50(%rsi),%xmm7 41f8b1: 0f 28 76 60 movaps 0x60(%rsi),%xmm6 41f8b5: 48 8b 76 c8 mov -0x38(%rsi),%rsi 41f8b9: 4c 89 d4 mov %r10,%rsp 41f8bc: c3 retq Here is a similar function with forced realignment. This can be improved with an additional "have frame pointer" set of stubs. __attribute__ ((ms_abi, noinline, force_align_arg_pointer)) long msabifn0_5 () { __asm__ __volatile__ ( "" ::: "rbx", "r12", "r13", "r14", "r15" ); return sysv_fn0 (); } 0000000000400fc0 <msabifn0_5>: 400fc0: 55 push %rbp 400fc1: 48 8d 44 24 90 lea -0x70(%rsp),%rax 400fc6: 48 89 e5 mov %rsp,%rbp 400fc9: 48 83 e0 f0 and $0xfffffffffffffff0,%rax 400fcd: 48 8d 60 b0 lea -0x50(%rax),%rsp 400fd1: e8 78 e8 01 00 callq 41f84e <__msabi_save_13> 400fd6: 41 57 push %r15 400fd8: 41 56 push %r14 400fda: 41 55 push %r13 400fdc: 41 54 push %r12 400fde: 31 c0 xor %eax,%eax 400fe0: e8 7b fc ff ff callq 400c60 <sysv_fn0> 400fe5: 48 8d a5 20 ff ff ff lea -0xe0(%rbp),%rsp 400fec: 41 5c pop %r12 400fee: 41 5d pop %r13 400ff0: 41 5e pop %r14 400ff2: 41 5f pop %r15 400ff4: 48 8d 74 24 50 lea 0x50(%rsp),%rsi 400ff9: e8 a0 e8 01 00 callq 41f89e <__msabi_restore_13> 400ffe: 48 81 c4 c0 00 00 00 add $0xc0,%rsp 401005: 5d pop %rbp 401006: c3 retq Daniel

1 2

Re: [PATCH 09/10] kernel32/tests: Added more named pipe tests.
by Marvin 24 Oct '16

24 Oct '16

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=26285 Your paranoid android. === w864 (64 bit pipe) === pipe.c:2575: Test failed: FlushFileBuffers failed: 87 pipe.c:2575: Test failed: FlushFileBuffers failed: 87

1 0

Stack realignment configure option?
by Daniel Santos 23 Oct '16

23 Oct '16

I've read up a bit on the issues with realignment on Wine 64 and all of the programs that crash because they luckily get away with violating the ABI on Windows. While not crashing is a pretty good thing, forcing stack realignment also affects optimizations in some less obvious ways, inhibiting sibling calls, ret from function bodies, adding a frame pointer, etc. I don't actually have any bright ideas for this atm, but can we at least add a configure option to disable this for those who don't happen to have such programs crashing? Probably only Gentoo users and geeks will care for it.

1 1

TRACE in wined3d_check_device_format()
by wylda＠volny.cz 22 Oct '16

22 Oct '16

Hi, isn't that middle \n in TRACE some kind of leftover? TRACE("wined3d %p, adapter_idx %u, device_type %s, adapter_format %s, usage %s, %s,\n" "resource_type %s, check_format %s.\n", wined3d, adapter_idx, debug_d3ddevicetype(device_type), debug_d3dformat(adapter_format_id), debug_d3dusage(usage), debug_d3dusagequery(usage), debug_d3dresourcetype(resource_type), debug_d3dformat(check_format_id)); Regards, W.

2 1

How to make winedbg listen to same port every time?
by A B 21 Oct '16

21 Oct '16

If i run : winedbg --gdb --no-start test.exe it say : target remote localhost:55304 But if I run it second time , it say a different port , for example target remote localhost:111111 is there a command line argument for winedbg so it to listen to same port every time , and to do not change the port ,so I can specity to witch port it to listen , or I have to recompile winedbg ? Thank you!

2 2

Re: [PATCH 6/9] wined3d: Replace wined3d_buffer_load_sysmem() calls with wined3d_buffer_load_location().
by Henri Verbeet 21 Oct '16

21 Oct '16

On 20 October 2016 at 12:50, Józef Kucia <jkucia(a)codeweavers.com> wrote: > - /* Download the buffer, but don't permanently enable double buffering */ > - if (!(buffer->flags & WINED3D_BUFFER_DOUBLEBUFFER)) > - { > - wined3d_buffer_load_sysmem(buffer, context); > - buffer->flags &= ~WINED3D_BUFFER_DOUBLEBUFFER; > - } > + /* Download the buffer, but don't permanently enable double buffering. */ > + wined3d_buffer_load_location(buffer, context, WINED3D_LOCATION_SYSMEM); > + buffer->flags &= ~WINED3D_BUFFER_DOUBLEBUFFER; Wouldn't this also clear WINED3D_BUFFER_DOUBLEBUFFER if it was previously set? Longer term, it's probably inappropriate for wined3d_buffer_load_location() to set WINED3D_BUFFER_DOUBLEBUFFER to begin with.

1 0

Re: [PATCH 5/9] wined3d: Implement wined3d_buffer_prepare_location() for WINED3D_LOCATION_BUFFER.
by Henri Verbeet 21 Oct '16

21 Oct '16

On 20 October 2016 at 12:50, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -612,7 +619,7 @@ void buffer_get_memory(struct wined3d_buffer *buffer, struct wined3d_context *co > { > if ((buffer->flags & WINED3D_BUFFER_USE_BO) && !buffer->resource.map_count) > { > - buffer_create_buffer_object(buffer, context); > + wined3d_buffer_prepare_location(buffer, context, WINED3D_LOCATION_BUFFER); > if (buffer->buffer_object) Note that that should be equivalent to "if (wined3d_buffer_prepare_location(buffer, context, WINED3D_LOCATION_BUFFER))".

1 0

Re: [PATCH v3] winebus.sys: Handle device reports for hidraw devices
by Sebastian Lackner 21 Oct '16

21 Oct '16

On 17.10.2016 17:14, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > v3: Further suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 + > dlls/winebus.sys/bus_udev.c | 73 ++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 133 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 208 insertions(+), 1 deletion(-) > > Now that all the handling for last_report is in main.c, I would suggest to split it out into a separate patch for easier reviewing. The first patch could contain IOCTL_HID_READ_REPORT and corresponding platform code only. Caching of the last record can then be implemented in the second patch. > > v3-0003-winebus.sys-Handle-device-reports-for-hidraw-device.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 7ce54bf..339449d 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -25,6 +25,8 @@ typedef struct > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > NTSTATUS (*get_string)(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length); > + NTSTATUS (*begin_report_processing)(DEVICE_OBJECT *device); > + void (*end_report_processing)(DEVICE_OBJECT *device); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > @@ -37,3 +39,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 243aabb..517a7d3 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #ifdef HAVE_UDEV > > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > + > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > > @@ -73,6 +75,11 @@ struct platform_private > { > struct udev_device *udev_device; > int device_fd; > + > + BYTE *report_buffer; > + int buffer_length; > + HANDLE report_thread; > + int control_pipe[2]; > }; > > static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > @@ -222,11 +229,77 @@ static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buf > return STATUS_SUCCESS; > } > > +static DWORD CALLBACK device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[2]; > + > + plfds[0].fd = private->device_fd; > + plfds[0].events = POLLIN; > + plfds[0].revents = 0; > + plfds[1].fd = private->control_pipe[0]; > + plfds[1].events = POLLIN; > + plfds[1].revents = 0; > + > + while (1) > + { > + int size; > + if (poll(plfds, 2, -1) <= 0) continue; > + if (plfds[1].revents || !private->report_buffer || private->buffer_length == 0) > + break; > + size = read(plfds[0].fd, private->report_buffer, private->buffer_length); > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else > + process_hid_report(device, private->report_buffer, size); > + } > + return 0; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + private->buffer_length = 1024; > + private->report_buffer = HeapAlloc(GetProcessHeap(), 0, private->buffer_length); My understanding is that report_buffer is only used from the device_report_thread. Do we really have to store it in the platform private data then? For such a small amount of data, you could probably even allocate it directly on the stack in device_report_thread. > + > + pipe(private->control_pipe); Please also check for success here. > + private->report_thread = CreateThread(NULL, 0, device_report_thread, device, 0, NULL); > + if (!private->report_thread) > + { > + ERR("Unable to create device report thread\n"); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); > + return STATUS_UNSUCCESSFUL; > + } > + else > + return STATUS_SUCCESS; > +} > + > +static void end_report_processing(DEVICE_OBJECT *device) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + if (private->report_thread) > + { > + write(private->control_pipe[1], "q", 1); > + WaitForSingleObject(private->report_thread, INFINITE); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); report_thread should also be closed when no longer needed. > + } > + private->buffer_length = 0; > + HeapFree(GetProcessHeap(), 0, private->report_buffer); > + private->report_buffer = NULL; > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > hidraw_get_string, > + begin_report_processing, > + end_report_processing, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 86adbf5..0bd2c76 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -40,6 +40,7 @@ > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > struct pnp_device > { > @@ -58,6 +59,14 @@ struct device_extension > const WCHAR *busid; /* Expected to be a static constant */ > > const platform_vtbl *vtbl; > + > + BOOL processing_started; > + BYTE *last_report; > + DWORD last_report_size; > + DWORD buffer_size; > + LIST_ENTRY irp_queue; > + CRITICAL_SECTION report_cs; > + > BYTE platform_private[1]; > }; > > @@ -214,6 +223,10 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->busid = busidW; > ext->vtbl = vtbl; > It might be better to explicitly initialize all fields here. I don't know if you can rely on the fact that Wines current implementation nulls the driver extension. > + InitializeListHead(&ext->irp_queue); > + InitializeCriticalSection(&ext->report_cs); > + ext->report_cs.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": report_cs"); > + > /* add to list of pnp devices */ > pnp_dev->device = device; > list_add_tail(&pnp_devset, &pnp_dev->entry); > @@ -271,6 +284,8 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > { > struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > struct pnp_device *pnp_device = ext->pnp_device; > + LIST_ENTRY *entry; > + IRP *irp; > > TRACE("(%p)\n", device); > > @@ -279,7 +294,28 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > LeaveCriticalSection(&device_list_cs); > > IoInvalidateDeviceRelations(device, RemovalRelations); > + > + if (ext->processing_started) > + ext->vtbl->end_report_processing(device); At this point the device_fd was already closed (too early). Do we really need the callback, or could we also do the platform specific cleanup in try_remove_device()? > + > + /* Cancel pending IRPs */ > + EnterCriticalSection(&ext->report_cs); > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) You could write this loop a bit easier like: while ((entry = RemoveHeadList(&ext->irp_queue)) != &ext->irp_queue) { ... } The same also applies to the code below. > + { > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irp->IoStatus.u.Status = STATUS_CANCELLED; > + irp->IoStatus.Information = 0; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > + > + ext->report_cs.DebugInfo->Spare[0] = 0; > + DeleteCriticalSection(&ext->report_cs); > + > HeapFree(GetProcessHeap(), 0, ext->serial); > + HeapFree(GetProcessHeap(), 0, ext->last_report); > IoDeleteDevice(device); > > /* pnp_device must be released after the device is gone */ > @@ -432,6 +468,58 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = (strlenW((WCHAR *)irp->UserBuffer) + 1) * sizeof(WCHAR); > break; > } > + case IOCTL_HID_GET_INPUT_REPORT: > + { > + HID_XFER_PACKET *packet = (HID_XFER_PACKET*)(irp->UserBuffer); > + TRACE_(hid_report)("IOCTL_HID_GET_INPUT_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + irp->IoStatus.u.Status = status = ext->vtbl->begin_report_processing(device); > + if (status == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + > + if (packet->reportBufferLen < ext->last_report_size) > + { > + irp->IoStatus.u.Status = status = STATUS_BUFFER_TOO_SMALL; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + > + if (ext->last_report_size) > + memcpy(packet->reportBuffer, ext->last_report, ext->last_report_size); > + packet->reportBufferLen = ext->last_report_size; > + irp->IoStatus.Information = ext->last_report_size; > + irp->IoStatus.u.Status = status = STATUS_SUCCESS; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + case IOCTL_HID_READ_REPORT: > + { > + TRACE_(hid_report)("IOCTL_HID_READ_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + if (ext->vtbl->begin_report_processing(device) == STATUS_SUCCESS) Did you want to assign the result to "status" here? Also, it is a bit unfortunate that we have tracking of report processing in both the common code and also in the platform specific code. If you modify begin_report_processing to return STATUS_SUCCESS if it already has been started, you could simplify this code to something like: --- snip --- status = ext->vtbl->begin_report_processing(device); if (status != STATUS_SUCCESS) { ... } --- snip --- It also ensures that the status in both components never gets out of sync. Not sure if it is a problem, but due to the fact that the device has been opened a long time before starting to read from it, couldn't there be a large amount of reports in the kernel buffers? Do you think it makes sense to skip such outdated reports? > + ext->processing_started = TRUE; > + else > + { > + irp->IoStatus.u.Status = status; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + status = STATUS_PENDING; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > @@ -441,11 +529,54 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > } > } > > - IoCompleteRequest(irp, IO_NO_INCREMENT); > + if (status != STATUS_PENDING) > + IoCompleteRequest(irp, IO_NO_INCREMENT); > > return status; > } > > +void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + IRP *irp; > + LIST_ENTRY *entry; > + > + EnterCriticalSection(&ext->report_cs); > + if (length > ext->buffer_size) > + { > + HeapFree(GetProcessHeap(), 0, ext->last_report); > + ext->last_report = HeapAlloc(GetProcessHeap(), 0, length); It would be better to handle failures here. > + ext->buffer_size = length; > + } > + > + memcpy(ext->last_report, report, length); > + ext->last_report_size = length; > + > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + IO_STACK_LOCATION *irpsp; > + TRACE_(hid_report)("Processing Request\n"); > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irpsp = IoGetCurrentIrpStackLocation(irp); > + > + if (irpsp->Parameters.DeviceIoControl.OutputBufferLength < length) > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_TOO_SMALL; > + } > + else > + { > + memcpy(irp->UserBuffer, report, length); > + irp->IoStatus.Information = length; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

2 8

Re: [PATCH] hidclass.sys: Use IoSetCompletionRoutine
by Aric Stewart 21 Oct '16

21 Oct '16

On 10/18/16 5:40 PM, Sebastian Lackner wrote: > On 18.10.2016 17:07, Aric Stewart wrote: >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/hidclass.sys/device.c | 20 +++++++------------- >> dlls/hidclass.sys/main.c | 13 +++++-------- >> dlls/hidclass.sys/pnp.c | 10 +++++----- >> 3 files changed, 17 insertions(+), 26 deletions(-) > > Thanks! While you are just at it, could you please also check the two > occurances of "if (irp->IoStatus.u.Status == STATUS_PENDING)"? They > look wrong to me, the correct way would be to check the return value > of IoCallDriver. Also, it looks like call_minidriver is leaking "buffer". Actually that was intentional at the time. There was code in ntoskrnl that was freeing that buffer already so I was getting a double free issue. Now you have been doing a lot of work there so maybe that has changed. I have not gone back and revisited it. -aric > > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v6).
by Marvin 20 Oct '16

20 Oct '16

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=26243 Your paranoid android. === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFF1220C0

1 0

Re: [PATCH] d2d1: Initial implementation of bitmap render target
by Henri Verbeet 19 Oct '16

19 Oct '16

On 14 October 2016 at 18:12, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + if (!pixel_size && size) > + { > + texture_desc.Width = ceilf((size->width * parent_target->desc.dpiX) / 96.0f); > + texture_desc.Height = ceilf((size->height * parent_target->desc.dpiY) / 96.0f); > + dxgi_rt_desc.dpiX = (texture_desc.Width * 96.0f) / size->width; > + dxgi_rt_desc.dpiY = (texture_desc.Height * 96.0f) / size->height; > + } > + else if (pixel_size && !size) > + { > + texture_desc.Width = pixel_size->width; > + texture_desc.Height = pixel_size->height; > + dxgi_rt_desc.dpiX = parent_target->desc.dpiX; > + dxgi_rt_desc.dpiY = parent_target->desc.dpiY; > + } > + else if (pixel_size && size) > + { > + texture_desc.Width = pixel_size->width; > + texture_desc.Height = pixel_size->height; > + dxgi_rt_desc.dpiX = (pixel_size->width * 96.0f) / size->width; > + dxgi_rt_desc.dpiY = (pixel_size->height * 96.0f) / size->height; > + } > + else > + { > + texture_desc.Width = parent_target->pixel_size.width; > + texture_desc.Height = parent_target->pixel_size.height; > + dxgi_rt_desc.dpiX = parent_target->desc.dpiX; > + dxgi_rt_desc.dpiY = parent_target->desc.dpiY; > + } It may just be taste, but I think this is a bit harder to follow than it needs to be. What do you think about the following? if (pixel_size) { texture_desc.Width = pixel_size->width; texture_desc.Height = pixel_size->height; } else if (size) { texture_desc.Width = ceilf((size->width * parent_target->desc.dpiX) / 96.0f); texture_desc.Height = ceilf((size->height * parent_target->desc.dpiY) / 96.0f); } else { texture_desc.Width = parent_target->pixel_size.width; texture_desc.Height = parent_target->pixel_size.height; } if (size) { dxgi_rt_desc.dpiX = (texture_desc.Width * 96.0f) / size->width; dxgi_rt_desc.dpiY = (texture_desc.Height * 96.0f) / size->height; } else { dxgi_rt_desc.dpiX = parent_target->desc.dpiX; dxgi_rt_desc.dpiY = parent_target->desc.dpiY; }

2 1

Re: [PATCH 6/6] wined3d: Rename buffer_invalidate_bo_range() to buffer_mark_dirty_area().
by Henri Verbeet 19 Oct '16

19 Oct '16

On 16 October 2016 at 21:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > -static void buffer_invalidate_bo_range(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size) > +static void buffer_mark_dirty_area(struct wined3d_buffer *buffer, unsigned int offset, unsigned int size) I assume this is for consistency with buffer_clear_dirty_areas() and the like, but in the larger context we're using validate/invalidate for terminology.

2 2

Re: [PATCH 3/6] wined3d: Rename buffer_internal_preload() to wined3d_buffer_load().
by Henri Verbeet 19 Oct '16

19 Oct '16

On 16 October 2016 at 21:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > -void buffer_internal_preload(struct wined3d_buffer *buffer, struct wined3d_context *context, > +void wined3d_buffer_load(struct wined3d_buffer *buffer, struct wined3d_context *context, > const struct wined3d_state *state) This makes the naming consistent with wined3d_texture_load(), so that's good. Still, I don't think that one necessarily covers what the function does very well either, so if anyone has good suggestions...

1 0

Re: [PATCH 2/6] wined3d: Clean up buffer_internal_preload().
by Henri Verbeet 19 Oct '16

19 Oct '16

On 16 October 2016 at 21:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > -static inline void fixup_transformed_pos(float *p) > +static inline unsigned int fixup_transformed_pos(float *p) > { > /* rhw conversion like in position_float4(). */ > if (p[3] != 1.0f && p[3] != 0.0f) > @@ -452,6 +454,8 @@ static inline void fixup_transformed_pos(float *p) > p[2] *= w; > p[3] = w; > } > + > + return 4 * sizeof(*p); > } Since you're cleaning things up, note that this should probably use struct wined3d_vec4. > - for (i = start / buffer->stride; i < min((end / buffer->stride) + 1, vertices); ++i) > + for (i = start / buffer->stride; i < min((end / buffer->stride) + 1, vertex_count); ++i) > { > - for (j = 0; j < buffer->stride; ++j) > + for (j = 0; j < buffer->stride;) > { > switch (buffer->conversion_map[j]) > { In general this conversion code shouldn't be used a lot, but I could imagine it being better to loop over the vertices in the fixup functions instead of in the outer loop.

1 0

Re: [PATCH 1/2] taskschd: Added ITriggerCollection::Create implementation.
by Dmitry Timoshkov 19 Oct '16

19 Oct '16

Jacek Caban <jacek(a)codeweavers.com> wrote: > + if(IsEqualGUID(&IID_IUnknown, riid) || IsEqualGUID(&IID_IDispatch, riid) || IsEqualGUID(&IID_ITrigger, riid) > + || IsEqualGUID(&IID_IDailyTrigger, riid)) { > + *ppv = &This->IDailyTrigger_iface; > + }else { Please try to follow the style of the existing code for placing braces, add space between if and (, } and else, and split the above line of comparisons. > @@ -144,8 +373,29 @@ static HRESULT WINAPI TriggerCollection_get__NewEnum(ITriggerCollection *iface, > static HRESULT WINAPI TriggerCollection_Create(ITriggerCollection *iface, TASK_TRIGGER_TYPE2 type, ITrigger **trigger) > { > trigger_collection *This = impl_from_ITriggerCollection(iface); > - FIXME("(%p)->(%d %p)\n", This, type, trigger); > - return E_NOTIMPL; > + > + TRACE("(%p)->(%d %p)\n", This, type, trigger); > + > + switch(type) { > + case TASK_TRIGGER_DAILY: { > + DailyTrigger *daily_trigger; > + > + daily_trigger = heap_alloc(sizeof(*daily_trigger)); > + if(!daily_trigger) > + return E_OUTOFMEMORY; > + > + daily_trigger->IDailyTrigger_iface.lpVtbl = &DailyTrigger_vtbl; > + daily_trigger->ref = 1; > + > + *trigger = (ITrigger*)&daily_trigger->IDailyTrigger_iface; > + break; > + } > + default: > + FIXME("Unimplemented type %d\n", type); > + return E_NOTIMPL; > + } Please add a global constructor for the triggger, and use it here. -- Dmitry.

1 0

Re: [PATCH v2] kernel32: Improved GetUserPreferredUILanguages stub.
by Marvin 18 Oct '16

18 Oct '16

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=26213 Your paranoid android. === w1064 (32 bit locale) === locale.c:2650: Test failed: LCMapStringEx should fail with bad locale name locale.c:2651: Test failed: unexpected error code -559038737 locale.c:2742: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4480: Test failed: IsValidLocaleName should have failed locale.c:4863: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4865: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2650: Test failed: LCMapStringEx should fail with bad locale name locale.c:2651: Test failed: unexpected error code -559038737 locale.c:2742: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4480: Test failed: IsValidLocaleName should have failed locale.c:4863: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4865: Test failed: For id 7, Expected IVC, got ''

1 0

Re: kernel32: Improved GetUserPreferredUILanguages stub.
by Marvin 18 Oct '16

18 Oct '16

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

1 0

Re: [PATCH v2 2/2] hid/tests: Add HID device enumeration test
by Sebastian Lackner 18 Oct '16

18 Oct '16

On 17.10.2016 15:58, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > configure | 1 + > configure.ac | 1 + > dlls/hid/tests/Makefile.in | 5 +++ > dlls/hid/tests/device.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 89 insertions(+) > create mode 100644 dlls/hid/tests/Makefile.in > create mode 100644 dlls/hid/tests/device.c > > > > v2-0002-hid-tests-Add-HID-device-enumeration-test.txt > > > diff --git a/configure b/configure > index c21bda3..b397b38 100755 > --- a/configure > +++ b/configure > @@ -17940,6 +17940,7 @@ wine_fn_config_dll gpkcsp enable_gpkcsp > wine_fn_config_dll hal enable_hal > wine_fn_config_dll hhctrl.ocx enable_hhctrl_ocx clean,implib htmlhelp > wine_fn_config_dll hid enable_hid implib > +wine_fn_config_test dlls/hid/tests hid_test > wine_fn_config_dll hidclass.sys enable_hidclass_sys implib hidclass > wine_fn_config_dll hlink enable_hlink clean,implib > wine_fn_config_test dlls/hlink/tests hlink_test > diff --git a/configure.ac b/configure.ac > index c624c9e..40060b7 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3027,6 +3027,7 @@ WINE_CONFIG_DLL(gpkcsp) > WINE_CONFIG_DLL(hal) > WINE_CONFIG_DLL(hhctrl.ocx,,[clean,implib],[htmlhelp]) > WINE_CONFIG_DLL(hid,,[implib]) > +WINE_CONFIG_TEST(dlls/hid/tests) > WINE_CONFIG_DLL(hidclass.sys,,[implib],[hidclass]) > WINE_CONFIG_DLL(hlink,,[clean,implib]) > WINE_CONFIG_TEST(dlls/hlink/tests) > diff --git a/dlls/hid/tests/Makefile.in b/dlls/hid/tests/Makefile.in > new file mode 100644 > index 0000000..6bf3773 > --- /dev/null > +++ b/dlls/hid/tests/Makefile.in > @@ -0,0 +1,5 @@ > +TESTDLL = hid.dll > +IMPORTS = hid setupapi > + > +C_SRCS = \ > + device.c > diff --git a/dlls/hid/tests/device.c b/dlls/hid/tests/device.c > new file mode 100644 > index 0000000..47ad1a3 > --- /dev/null > +++ b/dlls/hid/tests/device.c > @@ -0,0 +1,82 @@ > +/* > + * Copyright (c) 2016 Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windows.h" > +#include "setupapi.h" > +#include "ddk/hidsdi.h" > + > +#include "wine/test.h" > + > +static void enumerate_devices(void) I didn't point this out earlier, but usually test functions start with "test_". An exception would be if you plan to use this as a helper function to run other tests for all enumerated devices. Then you could either move most of the code to START_TEST, for example: --- snip --- START_TEST(device) { ... enumeration code ... test_device_info(file); ... enumeration code ... } --- snip --- or rename it to something like "run_for_each_device(callback)" and use a callback-based approach: --- snip --- START_TEST(device) { run_for_each_device(test_device_info); } --- snip --- > +{ > + GUID hid_guid; > + WCHAR device_name[128]; > + HDEVINFO info_set; > + DWORD index = 0; > + SP_DEVICE_INTERFACE_DATA interface_data; > + DWORD detail_size = MAX_PATH * sizeof(WCHAR); > + SP_DEVICE_INTERFACE_DETAIL_DATA_W *data; > + > + HidD_GetHidGuid(&hid_guid); > + > + ZeroMemory(&interface_data, sizeof(interface_data)); > + interface_data.cbSize = sizeof(interface_data); > + > + data = HeapAlloc(GetProcessHeap(), 0, sizeof(*data) + detail_size); > + data->cbSize = sizeof(*data); > + > + info_set = SetupDiGetClassDevsW(&hid_guid, NULL, NULL, DIGCF_DEVICEINTERFACE); > + while (SetupDiEnumDeviceInterfaces(info_set, NULL, &hid_guid, index, &interface_data)) > + { > + index ++; > + > + if (SetupDiGetDeviceInterfaceDetailW(info_set, &interface_data, data, sizeof(*data) + detail_size, NULL, NULL)) > + { > + NTSTATUS status; > + BOOL rc; > + PHIDP_PREPARSED_DATA ppd; > + HIDP_CAPS Caps; > + HANDLE file = CreateFileW(data->DevicePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); > + if (file == INVALID_HANDLE_VALUE) > + { > + trace("Failed to access device %s, likely not plugged in or access is denied.\n", wine_dbgstr_w(data->DevicePath)); > + continue; > + } > + rc = HidD_GetPreparsedData(file, &ppd); > + ok(rc, "Failed to get preparsed data(0x%x)\n", GetLastError()); > + status = HidP_GetCaps(ppd, &Caps); > + ok(status == HIDP_STATUS_SUCCESS, "Failed to get Caps(0x%x)\n", status); > + rc = HidD_GetProductString(file, device_name, sizeof(device_name)); > + ok(rc, "Failed to get product string(0x%x)\n", GetLastError()); > + trace("Found device %s (%s, %02x, %02x)\n", wine_dbgstr_w(device_name), wine_dbgstr_w(data->DevicePath), Caps.UsagePage, Caps.Usage); > + rc = HidD_FreePreparsedData(ppd); > + ok(rc, "Failed to free preparsed data(0x%x)\n", GetLastError()); > + CloseHandle(file); > + } > + } > + HeapFree(GetProcessHeap(), 0, data); > + if (info_set) > + SetupDiDestroyDeviceInfoList(info_set); According to MSDN SetupDiGetClassDevs returns INVALID_HANDLE_VALUE on failure, not NULL. If this check is not necessary you can also remove it. > +} > + > +START_TEST(device) > +{ > + enumerate_devices(); > +} > > >

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v5).
by Dmitry Timoshkov 18 Oct '16

18 Oct '16

Roman Pišl <rpisl(a)seznam.cz> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. > > V5 - fixes failing test on Windows > > Based on https://www.winehq.org/pipermail/wine-patches/2016-July/151919.html > > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > Signed-off-by: Roman Pišl <rpisl(a)seznam.cz> Probably you shouldn't add someone's else sign-off without the author's agreement, or mention that you've got an explicit agreement from the patch author otherwise. > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + int enable = 1; > + int fd = get_sock_fd(ret, 0, NULL); > + setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, sizeof(enable)); > + } > +#endif It's better to verify that get_sock_fd() succeded before using its result, and call release_sock_fd() at the end. -- Dmitry.

2 2

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4).
by Bruno Jesus 17 Oct '16

17 Oct '16

Hi, thanks for the retry. I'm not at home and I'm replying from mobile so I can't help much, from the test results it is clear that MS broke the API starting on Vista, the.tests need to be.enhaced so that they pass on both pré vista and post xp. In the sockets tests I have made that many times due to other API breaks, look for the word behavior around tests line 1760. So you can split and make tests pass on all systems. On Monday, October 17, 2016, Roman Pišl <rpisl(a)seznam.cz> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. > > Based on https://www.winehq.org/pipermail/wine-patches/2016- > July/151919.html > > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io > <javascript:;>> > Signed-off-by: Roman Pišl <rpisl(a)seznam.cz <javascript:;>> > --- > dlls/ws2_32/socket.c | 23 +++++++++------------- > dlls/ws2_32/tests/sock.c | 50 ++++++++++++++++++++++++++++++ > ++++++++++++++++-- > 2 files changed, 57 insertions(+), 16 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index e8c5130..d14e9d6 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3240,20 +3240,6 @@ int WINAPI WS_bind(SOCKET s, const struct > WS_sockaddr* name, int namelen) > } > else > { > -#ifdef IPV6_V6ONLY > - const struct sockaddr_in6 *in6 = (const struct > sockaddr_in6*) &uaddr; > - if (name->sa_family == WS_AF_INET6 && > - !memcmp(&in6->sin6_addr, &in6addr_any, sizeof(struct > in6_addr))) > - { > - int enable = 1; > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, > &enable, sizeof(enable)) == -1) > - { > - release_sock_fd( s, fd ); > - SetLastError(WSAEAFNOSUPPORT); > - return SOCKET_ERROR; > - } > - } > -#endif > if (name->sa_family == WS_AF_INET) > { > struct sockaddr_in *in4 = (struct sockaddr_in*) > &uaddr; > @@ -7233,6 +7219,15 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > + > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + int enable = 1; > + int fd = get_sock_fd(ret, 0, NULL); > + setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, > sizeof(enable)); > + } > +#endif > return ret; > } > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index a144bd3..a676255 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -1732,7 +1732,7 @@ static void test_so_reuseaddr(void) > DWORD err; > > saddr.sin_family = AF_INET; > - saddr.sin_port = htons(9375); > + saddr.sin_port = htons(SERVERPORT+1); > saddr.sin_addr.s_addr = inet_addr("127.0.0.1"); > > s1=socket(AF_INET, SOCK_STREAM, 0); > @@ -6110,6 +6110,8 @@ static void test_ipv6only(void) > struct sockaddr_in sin4; > struct sockaddr_in6 sin6; > int ret; > + int enabled; > + int len; > > memset(&sin4, 0, sizeof(sin4)); > sin4.sin_family = AF_INET; > @@ -6142,6 +6144,50 @@ static void test_ipv6only(void) > ok(!ret, "Could not bind IPv4 address (LastError: %d; %d expected if > IPv6 binds to IPv4 as well).\n", > WSAGetLastError(), WSAEADDRINUSE); > > + closesocket(v4); > + closesocket(v6); > + v4 = INVALID_SOCKET; > + v6 = INVALID_SOCKET; > + > + /* Test again, this time disabling V6ONLY. */ > + sin4.sin_port = htons(SERVERPORT+2); > + sin6.sin6_port = htons(SERVERPORT+2); > + > + v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); > + ok(v6 != INVALID_SOCKET, "Could not create IPv6 socket (LastError: > %d; %d expected if IPv6 not available).\n", > + WSAGetLastError(), WSAEAFNOSUPPORT); > + > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, > &len); > + if (ret) { > + skip("Could not check IPV6_V6ONLY (option not supported?) > ((LastError: %d).\n", WSAGetLastError()); > + goto end; > + } > + ok(enabled == 1, "IPV6_V6ONLY is not enabled by default.\n"); > + > + enabled = 0; > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, len); > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + > + ret = bind(v6, (struct sockaddr*)&sin6, sizeof(sin6)); > + ok(!ret, "Could not bind IPv6 address (LastError: %d).\n", > WSAGetLastError()); > + > + enabled = 2; > + len = sizeof(enabled); > + getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, &len); > + ok(enabled == 0, "IPV6_V6ONLY is enabled after bind.\n"); > + > + v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); > + ok(v4 != INVALID_SOCKET, "Could not create IPv4 socket (LastError: > %d).\n", > + WSAGetLastError()); > + > + WSASetLastError(0xdeadbeef); > + bind(v4, (struct sockaddr*)&sin4, sizeof(sin4)); > + > + ok(WSAGetLastError() == WSAEADDRINUSE, "Failed to disable IPV6_V6ONLY > (LastError: %d; %d expected if IPv6 binds to IPv4 as well).\n", > + WSAGetLastError(), WSAEADDRINUSE); > + > end: > if (v4 != INVALID_SOCKET) > closesocket(v4); > @@ -8024,7 +8070,7 @@ static void test_TransmitFile(void) > /* Setup a properly connected socket for transfers */ > memset(&bindAddress, 0, sizeof(bindAddress)); > bindAddress.sin_family = AF_INET; > - bindAddress.sin_port = htons(9375); > + bindAddress.sin_port = htons(SERVERPORT+1); > bindAddress.sin_addr.s_addr = inet_addr("127.0.0.1"); > iret = bind(server, (struct sockaddr*)&bindAddress, > sizeof(bindAddress)); > if (iret != 0) > -- > 2.7.3 > > > >

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4).
by Marvin 17 Oct '16

17 Oct '16

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=26191 Your paranoid android. === wvistau64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7u (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). sock.c:7810: Test failed: bytesReturned isn't supposed to be 1 sock.c:7834: Test failed: GetOverlappedResult failed, error 0 === w8 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === wvistau64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). sock.c:7810: Test failed: bytesReturned isn't supposed to be 1 sock.c:7856: Test failed: Waiting for timeout failed with 0 + errno 997 === w864 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well).

1 0

Re: [PATCH v2] winebus.sys: Handle device reports for hidraw devices
by Sebastian Lackner 17 Oct '16

17 Oct '16

On 17.10.2016 15:29, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 ++ > dlls/winebus.sys/bus_udev.c | 73 ++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 123 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 198 insertions(+), 1 deletion(-) > > > > v2-0001-winebus.sys-Handle-device-reports-for-hidraw-device.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 7ce54bf..bcb1163 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -25,6 +25,8 @@ typedef struct > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > NTSTATUS (*get_string)(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length); > + NTSTATUS (*begin_report_processing)(DEVICE_OBJECT *device, BYTE **report_buffer, DWORD *buffer_length); > + void (*end_report_processing)(DEVICE_OBJECT *device, BYTE *report_buffer); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > @@ -37,3 +39,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 243aabb..37c8412 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #ifdef HAVE_UDEV > > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > + > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > > @@ -73,6 +75,11 @@ struct platform_private > { > struct udev_device *udev_device; > int device_fd; > + > + BYTE *report_buffer; > + int buffer_length; > + HANDLE report_thread; > + int control_pipe[2]; > }; > > static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > @@ -222,11 +229,77 @@ static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buf > return STATUS_SUCCESS; > } > > +static DWORD CALLBACK device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[2]; > + > + plfds[0].fd = private->device_fd; > + plfds[0].events = POLLIN; > + plfds[0].revents = 0; > + plfds[1].fd = private->control_pipe[0]; > + plfds[1].events = POLLIN; > + plfds[1].revents = 0; > + > + while (1) > + { > + int size; > + if (poll(plfds, 2, -1) <= 0) continue; > + if (plfds[1].revents || !private->report_buffer || private->buffer_length == 0) > + break; > + size = read(plfds[0].fd, private->report_buffer, private->buffer_length); This could still cause problems when another thread copies the last_report while it is updated. I don't know how you are planning to implement it for other platforms, but wouldn't it be better to use a separate buffer in this thread, and let process_hid_report() do the copying? > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else > + process_hid_report(device, hidraw_busidW, private->report_buffer, size); > + } > + return 0; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device, BYTE **buffer, DWORD *length) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + *length = private->buffer_length = 1024; > + *buffer = private->report_buffer = HeapAlloc(GetProcessHeap(), 0, *length); > + > + pipe(private->control_pipe); > + private->report_thread = CreateThread(NULL, 0, device_report_thread, device, 0, NULL); > + if (!private->report_thread) > + { > + ERR("Unable to create device report thread\n"); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); > + return STATUS_UNSUCCESSFUL; > + } > + else > + return STATUS_SUCCESS; > +} > + > +static void end_report_processing(DEVICE_OBJECT *device, BYTE *buffer) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + if (private->report_thread) > + { > + write(private->control_pipe[1], "q", 1); > + WaitForSingleObject(private->report_thread, INFINITE); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); > + } > + private->buffer_length = 0; > + private->report_buffer = NULL; > + HeapFree(GetProcessHeap(), 0, buffer); > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > hidraw_get_string, > + begin_report_processing, > + end_report_processing, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 86adbf5..49dcc97 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -40,6 +40,7 @@ > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > struct pnp_device > { > @@ -58,6 +59,14 @@ struct device_extension > const WCHAR *busid; /* Expected to be a static constant */ > > const platform_vtbl *vtbl; > + > + BOOL processing_started; > + BYTE *last_report; > + DWORD last_report_size; > + DWORD buffer_size; > + LIST_ENTRY irp_queue; > + CRITICAL_SECTION report_cs; > + > BYTE platform_private[1]; > }; > > @@ -214,6 +223,9 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->busid = busidW; > ext->vtbl = vtbl; > > + InitializeListHead(&ext->irp_queue); > + InitializeCriticalSection(&ext->report_cs); You might want to give this CS a name, like done in other parts of wine. For example: --- snip --- InitializeCriticalSection(&src->lock); src->lock.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": XA2SourceImpl.lock"); --- snip --- > + > /* add to list of pnp devices */ > pnp_dev->device = device; > list_add_tail(&pnp_devset, &pnp_dev->entry); > @@ -271,6 +283,8 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > { > struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > struct pnp_device *pnp_device = ext->pnp_device; > + LIST_ENTRY *entry; > + IRP *irp; > > TRACE("(%p)\n", device); > > @@ -279,6 +293,23 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > LeaveCriticalSection(&device_list_cs); > > IoInvalidateDeviceRelations(device, RemovalRelations); > + > + if (ext->processing_started) > + ext->vtbl->end_report_processing(device, ext->last_report); > + > + /* Cancel pending IRPs */ > + EnterCriticalSection(&ext->report_cs); > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irp->IoStatus.u.Status = STATUS_CANCELLED; > + irp->IoStatus.Information = 0; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > + You will have to delete the CS here. Also make sure to reset Spare[0] if it was previously set to a debug string. For example: --- snip --- src->lock.DebugInfo->Spare[0] = 0; DeleteCriticalSection(&src->lock); --- snip --- > HeapFree(GetProcessHeap(), 0, ext->serial); > IoDeleteDevice(device); > > @@ -432,6 +463,58 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = (strlenW((WCHAR *)irp->UserBuffer) + 1) * sizeof(WCHAR); > break; > } > + case IOCTL_HID_GET_INPUT_REPORT: > + { > + HID_XFER_PACKET *packet = (HID_XFER_PACKET*)(irp->UserBuffer); > + TRACE_(hid_report)("IOCTL_HID_GET_INPUT_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + irp->IoStatus.u.Status = status = ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size); > + if (status == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + > + if (packet->reportBufferLen < ext->last_report_size) > + { > + irp->IoStatus.u.Status = status = STATUS_BUFFER_TOO_SMALL; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + > + ZeroMemory(packet->reportBuffer, packet->reportBufferLen); Do we need this line? Usually callers do not expect valid data after the length provided by irp->IoStatus.Information. Is it different in this case? > + memcpy(packet->reportBuffer, ext->last_report, ext->last_report_size); > + packet->reportBufferLen = ext->last_report_size; > + irp->IoStatus.Information = ext->last_report_size; > + irp->IoStatus.u.Status = status = STATUS_SUCCESS; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + case IOCTL_HID_READ_REPORT: > + { > + TRACE_(hid_report)("IOCTL_HID_READ_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + if (ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size) == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + irp->IoStatus.u.Status = status; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + status = STATUS_PENDING; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > @@ -441,11 +524,49 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > } > } > > - IoCompleteRequest(irp, IO_NO_INCREMENT); > + if (status != STATUS_PENDING) > + IoCompleteRequest(irp, IO_NO_INCREMENT); > > return status; > } > > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + IRP *irp; > + LIST_ENTRY *entry; > + > + EnterCriticalSection(&ext->report_cs); > + if (ext->last_report && report != ext->last_report && ext->buffer_size <= length) Shouldn't it be "length <= ext->buffer_size" ? > + { > + memcpy(ext->last_report, report, length); > + ext->last_report_size = length; > + } > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + IO_STACK_LOCATION *irpsp; > + TRACE_(hid_report)("Processing Request\n"); > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irpsp = IoGetCurrentIrpStackLocation(irp); > + > + if (irpsp->Parameters.DeviceIoControl.OutputBufferLength < length) > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_TOO_SMALL; > + } > + else > + { > + memcpy(irp->UserBuffer, report, length); > + irp->IoStatus.Information = length; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

1 0

Re: [PATCH] hid/tests: Add HID device enumeration test
by Sebastian Lackner 17 Oct '16

17 Oct '16

On 14.10.2016 11:36, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > configure | 1 + > configure.ac | 1 + > dlls/hid/tests/Makefile.in | 5 +++ > dlls/hid/tests/device.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 87 insertions(+) > create mode 100644 dlls/hid/tests/Makefile.in > create mode 100644 dlls/hid/tests/device.c > > > > 0001-hid-tests-Add-HID-device-enumeration-test.txt > > > diff --git a/configure b/configure > index 99793b0..7bb6fef 100755 > --- a/configure > +++ b/configure > @@ -17936,6 +17936,7 @@ wine_fn_config_dll gpkcsp enable_gpkcsp > wine_fn_config_dll hal enable_hal > wine_fn_config_dll hhctrl.ocx enable_hhctrl_ocx clean,implib htmlhelp > wine_fn_config_dll hid enable_hid implib > +wine_fn_config_test dlls/hid/tests hid_test > wine_fn_config_dll hidclass.sys enable_hidclass_sys implib hidclass > wine_fn_config_dll hlink enable_hlink clean,implib > wine_fn_config_test dlls/hlink/tests hlink_test > diff --git a/configure.ac b/configure.ac > index ba8fd0f..9cab382 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3025,6 +3025,7 @@ WINE_CONFIG_DLL(gpkcsp) > WINE_CONFIG_DLL(hal) > WINE_CONFIG_DLL(hhctrl.ocx,,[clean,implib],[htmlhelp]) > WINE_CONFIG_DLL(hid,,[implib]) > +WINE_CONFIG_TEST(dlls/hid/tests) > WINE_CONFIG_DLL(hidclass.sys,,[implib],[hidclass]) > WINE_CONFIG_DLL(hlink,,[clean,implib]) > WINE_CONFIG_TEST(dlls/hlink/tests) > diff --git a/dlls/hid/tests/Makefile.in b/dlls/hid/tests/Makefile.in > new file mode 100644 > index 0000000..d4a69f0 > --- /dev/null > +++ b/dlls/hid/tests/Makefile.in > @@ -0,0 +1,5 @@ > +TESTDLL = hid.dll > +IMPORTS = hid setupapi > + > +C_SRCS = \ > + device.c \ The "\" at the end seems wrong. Please note that you can also use tools/make_makefiles to update/fix this file automatically for you. > diff --git a/dlls/hid/tests/device.c b/dlls/hid/tests/device.c > new file mode 100644 > index 0000000..f3260ec > --- /dev/null > +++ b/dlls/hid/tests/device.c > @@ -0,0 +1,80 @@ > +/* > + * Copyright (c) 2016 Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windows.h" > +#include "setupapi.h" > + > +#ifndef WINE_NTSTATUS_DECLARED > +#define WINE_NTSTATUS_DECLARED > +typedef LONG NTSTATUS; > +#endif Such hacks should be avoided in tests. I believe you are trying to workaround a bug in the Wine hidsdi.h header file. Wine declares NTSTATUS after the includes: --- snip --- #include <hidusage.h> #include <ddk/hidpi.h> #ifndef WINE_NTSTATUS_DECLARED #define WINE_NTSTATUS_DECLARED typedef LONG NTSTATUS; #endif --- snip --- On Windows its declared before: --- snip --- typedef _Return_type_success_(return >= 0) LONG NTSTATUS; #include "hidusage.h" #include "hidpi.h" --- snip --- > + > +#include "ddk/hidsdi.h" > + > +#include "wine/test.h" > + > +static void enumerate_devices(void) > +{ > + GUID hid_guid; > + WCHAR device_name[128]; > + HDEVINFO info_set; > + DWORD index = 0; > + SP_DEVICE_INTERFACE_DATA interface_data; > + DWORD detail_size = MAX_PATH * sizeof(WCHAR); > + SP_DEVICE_INTERFACE_DETAIL_DATA_W *data; > + > + HidD_GetHidGuid(&hid_guid); > + > + ZeroMemory(&interface_data, sizeof(interface_data)); > + interface_data.cbSize = sizeof(interface_data); > + > + data = HeapAlloc(GetProcessHeap(), 0, sizeof(*data) + detail_size); > + data->cbSize = sizeof(*data); > + > + info_set = SetupDiGetClassDevsW(&hid_guid, NULL, NULL, DIGCF_DEVICEINTERFACE); Shouldn't this be released afterwards? > + while (SetupDiEnumDeviceInterfaces(info_set, NULL, &hid_guid, index, &interface_data)) > + { > + index ++; > + > + if (SetupDiGetDeviceInterfaceDetailW(info_set, &interface_data, data, detail_size, NULL, NULL)) Shouldn't the DeviceInterfaceDetailDataSize parameter also include the sizeof(*data) ? > + { > + PHIDP_PREPARSED_DATA ppd; > + HIDP_CAPS Caps; > + HANDLE file = CreateFileW(data->DevicePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); > + if (file == INVALID_HANDLE_VALUE) > + { > + trace("Failed to access device %s, likely not plugged in or access is denied.\n", wine_dbgstr_w(data->DevicePath)); > + continue; > + } > + ok(HidD_GetPreparsedData(file, &ppd), "Failed to preparsed data\n"); Is there a "get" missing in the debug string? > + ok(HidP_GetCaps(ppd, &Caps) == HIDP_STATUS_SUCCESS, "Failed to get Caps\n"); > + ok(HidD_GetProductString(file, device_name, sizeof(device_name)), "Failed to get product string\n"); > + trace("Found device %s (%s, %02x, %02x)\n", wine_dbgstr_w(device_name), wine_dbgstr_w(data->DevicePath), Caps.UsagePage, Caps.Usage); > + ok(HidD_FreePreparsedData(ppd), "Failed to free preparsed data\n"); Its a matter of taste, but usually its better to assign those values to a variable. This also allows to print the error code / GetLastError() in case of a failure. > + CloseHandle(file); > + } > + } > + HeapFree(GetProcessHeap(), 0, data); > +} > + > +START_TEST(device) > +{ > + enumerate_devices(); > +} > > >

1 0

Re: [PATCH] winebus.sys: Handle device reports for hidraw devices
by Sebastian Lackner 17 Oct '16

17 Oct '16

On 17.10.2016 06:41, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 ++ > dlls/winebus.sys/bus_udev.c | 63 +++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 97 ++++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 162 insertions(+), 1 deletion(-) > > > > 0001-winebus.sys-Handle-device-reports-for-hidraw-devices.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 7ce54bf..bcb1163 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -25,6 +25,8 @@ typedef struct > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > NTSTATUS (*get_string)(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length); > + NTSTATUS (*begin_report_processing)(DEVICE_OBJECT *device, BYTE **report_buffer, DWORD *buffer_length); > + void (*end_report_processing)(DEVICE_OBJECT *device, BYTE *report_buffer); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > @@ -37,3 +39,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 243aabb..5307224 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #ifdef HAVE_UDEV > > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > + > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > > @@ -73,6 +75,10 @@ struct platform_private > { > struct udev_device *udev_device; > int device_fd; > + > + BYTE *report_buffer; > + int buffer_length; > + HANDLE report_thread; > }; > > static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > @@ -222,11 +228,68 @@ static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buf > return STATUS_SUCCESS; > } > > +static DWORD CALLBACK device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[1]; > + > + plfds[0].fd = private->device_fd; > + plfds[0].events = POLLIN; > + > + while (1) > + { > + int size; > + if (poll(plfds, 1, -1) <= 0) continue; > + if (!private->report_buffer || private->buffer_length == 0) > + break; > + size = read(plfds[0].fd, private->report_buffer, private->buffer_length); > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else > + process_hid_report(device, hidraw_busidW, private->report_buffer, size); > + } > + return 0; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device, BYTE **buffer, DWORD *length) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + *length = private->buffer_length = 1024; > + *buffer = private->report_buffer = HeapAlloc(GetProcessHeap(), 0, *length); > + > + private->report_thread = CreateThread(NULL, 0, device_report_thread, device, 0, NULL); > + if (!private->report_thread) > + { > + ERR("Unable to create device report thread\n"); > + return STATUS_UNSUCCESSFUL; > + } > + else > + return STATUS_SUCCESS; > +} > + > +static void end_report_processing(DEVICE_OBJECT *device, BYTE *buffer) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + if (private->report_thread) > + { > + TerminateThread(private->report_thread, 0); TerminateThread is not really the best way to clean up this worker thread. Depending on when exactly it is called, it can corrupt internal data and crash the whole process. In this case, it would definitely be better to have some synchronization mechanism (for example event pipe) to allow a clean shutdown. > + WaitForSingleObject(private->report_thread, INFINITE); > + } > + private->buffer_length = 0; > + private->report_buffer = NULL; > + HeapFree(GetProcessHeap(), 0, buffer); > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > hidraw_get_string, > + begin_report_processing, > + end_report_processing, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 86adbf5..f12cdf7 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -40,6 +40,7 @@ > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > struct pnp_device > { > @@ -58,6 +59,13 @@ struct device_extension > const WCHAR *busid; /* Expected to be a static constant */ > > const platform_vtbl *vtbl; > + > + BOOL processing_started; > + BYTE *last_report; > + DWORD last_report_size; > + DWORD buffer_size; > + LIST_ENTRY irp_queue; > + > BYTE platform_private[1]; > }; > > @@ -214,6 +222,8 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->busid = busidW; > ext->vtbl = vtbl; > > + InitializeListHead(&ext->irp_queue); > + > /* add to list of pnp devices */ > pnp_dev->device = device; > list_add_tail(&pnp_devset, &pnp_dev->entry); > @@ -271,6 +281,8 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > { > struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > struct pnp_device *pnp_device = ext->pnp_device; > + LIST_ENTRY *entry; > + IRP *irp; > > TRACE("(%p)\n", device); > > @@ -279,6 +291,21 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > LeaveCriticalSection(&device_list_cs); > > IoInvalidateDeviceRelations(device, RemovalRelations); > + > + /* Cancel pending IRPs */ > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irp->IoStatus.u.Status = STATUS_CANCELLED; > + irp->IoStatus.Information = 0; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + > + if (ext->processing_started) > + ext->vtbl->end_report_processing(device, ext->last_report); > + > HeapFree(GetProcessHeap(), 0, ext->serial); > IoDeleteDevice(device); > > @@ -432,6 +459,49 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = (strlenW((WCHAR *)irp->UserBuffer) + 1) * sizeof(WCHAR); > break; > } > + case IOCTL_HID_GET_INPUT_REPORT: > + { > + HID_XFER_PACKET *packet = (HID_XFER_PACKET*)(irp->UserBuffer); > + TRACE_(hid_report)("IOCTL_HID_GET_INPUT_REPORT\n"); > + if (!ext->processing_started) > + { > + irp->IoStatus.u.Status = status = ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size); > + if (status == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + break; > + } We might need synchronization here to ensure that only one worker thread is started (if there are multiple IOCTL_HID_GET_INPUT_REPORT requests at the same time). > + > + if (packet->reportBufferLen < ext->last_report_size) > + { > + irp->IoStatus.u.Status = status = STATUS_BUFFER_TOO_SMALL; > + break; > + } > + > + ZeroMemory(packet->reportBuffer, packet->reportBufferLen); > + memcpy(packet->reportBuffer, ext->last_report, ext->last_report_size); The worker thread always uses the same buffer. How do you ensure that the "last_report" you are copying here is a complete record, and not corrupted (for example partially old data)? > + packet->reportBufferLen = ext->last_report_size; > + irp->IoStatus.Information = ext->last_report_size; > + irp->IoStatus.u.Status = status = STATUS_SUCCESS; > + break; > + } > + case IOCTL_HID_READ_REPORT: > + { > + TRACE_(hid_report)("IOCTL_HID_READ_REPORT\n"); > + if (!ext->processing_started) > + { > + if (ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size) == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + irp->IoStatus.u.Status = status; > + break; > + } > + } > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); The irp_queue will require locking when it is accessed from multiple threads. > + status = STATUS_PENDING; Thats fine for now, but I'm planning to send some additional patches soon to fix STATUS_PENDING handling. Drivers on Windows have to call IoMarkIrpPending() when they return STATUS_PENDING. Also see: https://msdn.microsoft.com/en-us/library/windows/hardware/ff549422(v=vs.85)… """Otherwise, the I/O manager attempts to complete the IRP as soon as the dispatch routine returns control.""" and """If a driver queues incoming IRPs, it should call IoMarkIrpPending before it queues each IRP. Otherwise, an IRP could be dequeued, completed by another driver routine, and freed by the system before the call to IoMarkIrpPending occurs, thereby causing a crash. """ > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > @@ -441,11 +511,36 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > } > } > > - IoCompleteRequest(irp, IO_NO_INCREMENT); > + if (status != STATUS_PENDING) > + IoCompleteRequest(irp, IO_NO_INCREMENT); > > return status; > } > > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + IRP *irp; > + LIST_ENTRY *entry; > + > + if (ext->last_report && report != ext->last_report && ext->buffer_size <= length) > + { > + memcpy(ext->last_report, report, length); > + ext->last_report_size = length; > + } > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + TRACE_(hid_report)("Processing Request\n"); > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + memcpy(irp->UserBuffer, report, length); Shouldn't there also be some kind of length validation? > + irp->IoStatus.Information = length; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

1 0

Imort system certificates in crypt32@Wine
by Donat Enikeev 16 Oct '16

16 Oct '16

[Resending in plain/text, apologies for html] Hi Guys, Watched video recently from WineConf 2015, and results around opening community looks really promising, so I am performing 3rd attempt to be useful here :) The bug https://bugs.winehq.org/show_bug.cgi?id=30187 : Cisco IP Communicator failing to setup due to 'certmgr.exe' tool fails to install certificate to the system-wide trusted certificate store. Wine uses registry-based certificates stores by default, but treats HKLM\Root store as a special case: whenever app opens such store, Crypt32 goes through hard-coded paths in rootstore.c: static const char * const CRYPT_knownLocations[] = { "/etc/ssl/certs/ca-certificates.crt", "/etc/ssl/certs", ... }; And adds all found certificates to the special store. In the context of bug, this special-case store doesn't support adding certificates, and thus Cisco IP fails to install. So a backward compatible patch (attached) that just fixes this bug looks straightforward: make a stores collection, add there HKLM\Root certificates registry store first and then, add that system store with certificates from the environment. And return the resulting collection as a store to work with. It will allow applications do whatever they used to with certificates, keeping all the linux certificates available for verification of any kind. The problem with this approach is that current wine crypt32 doesn't actually save certificates that were added to a collection of stores (the test for this attached), while Win does. Although it could be fixed with a different patch in one function, but I would like to hear your thoughts first around following questions: 1. Does this backward-compatible patch-set make sense at all and worth proceeding? Probably you have some ongoing activities 2. Do you still think that wine should import system certificates during HKLM\Root request at all, not just shipping with those from typical windows installation? 3. Have you considered different approach of utilizing system certificates in Wine? For example, import all system certificates to the *registry* during wine-prefix initialization process, and work with them from there in a way windows does (even native crypt32 will benefit from this approach). That will allow to unify and simplify crypt32 and remove all that arguable hard-coded paths in the code, and bring more familiar environment to the windows application and, at the same time, isolation. Please share your thoughts, Donnie

1 0

mscoree: Add CorIsLatestSvc function stub.
by Andrey Gusev 16 Oct '16

16 Oct '16

>From poking at it with python ctypes, I believe this function takes 2 >pointer arguments and returns an HRESULT. >Have you found a real app that calls this? As far as I know, it's only >called by native .NET components that shouldn't be used with builtin >mscoree. At least two apps calls this function after .NET 4.5.1 (offline) have been installed.

3 2

IP dual stack
by Roman Pišl 16 Oct '16

16 Oct '16

Hi, I sent a small patch to fix a bug where it is not possible to disable IPV6_V6ONLY as it is always enabled in WS_bind(). I have discovered, that my patch is wrong and Matthieu Nottale already proposed right solution. But it wasn't merged. What is the current status of the patch? May I help somehow? I would like to fix that bug (it breaks our application). Roman

2 1

Re: mscoree: Add CorIsLatestSvc function stub.
by Vincent Povirk 16 Oct '16

16 Oct '16

>From poking at it with python ctypes, I believe this function takes 2 pointer arguments and returns an HRESULT. Have you found a real app that calls this? As far as I know, it's only called by native .NET components that shouldn't be used with builtin mscoree.

1 0

build WoW64 in chroots
by wylda＠volny.cz 15 Oct '16

15 Oct '16

Hello, some year ago i built WoW64 per Wine's wiki. But that was re-phrased now or maybe today things are not so complicated in case WoW64 built in chroots32/64. Now it is not clear to me, what are the proper WoW64 steps? : 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code (or should be wine32_tools?) ****** change chroot ****** 5. inside chroot64: "make install" of wine32 from above point 4 (but why wine32_tools dir also needs to be available in chroot64??) 6. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 5) Or can this be simplified to: 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code ****** change chroot ****** 5. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 4) Regards, W.

1 0

Re: libwine: Add public symbol to access list of debug options.
by Sebastian Lackner 14 Oct '16

14 Oct '16

On 09.10.2016 18:56, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41457. > > Currently, the "edit debug channels" feature of taskmgr is broken in > release builds, because: > > * "debug_options" is not exported as a public symbol > * taskmgr passes SYMOPT_PUBLICS_ONLY to SymSetOptions > > This combination does not make any sense (not even installing debug > packages is sufficient). This patch replaces debug_options with > __wine_dbg_options and makes it a public symbol. > > libs/wine/debug.c | 24 ++++++++++++------------ > libs/wine/wine.def | 1 + > libs/wine/wine.map | 1 + > programs/taskmgr/dbgchnl.c | 2 +- > programs/winedbg/info.c | 2 +- > 5 files changed, 16 insertions(+), 14 deletions(-) > Any opinions regarding this patch? An alternative approach would be to fix taskmgr (remove SYMOPT_PUBLICS_ONLY), and ask users to install debug packages if they want to use this feature. Would that be preferred? Regards, Sebastian

2 1

Re: [PATCH 1/5] wined3d: Add a quirk for GL implementations not supporting sRGB FBO attachments.
by Henri Verbeet 14 Oct '16

14 Oct '16

On 14 October 2016 at 00:03, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > As it seems to be the case for i915 (at least with some Mesa versions). > > This is only a problem because the GL implementation also exposes > EXT_texture_sRGB_decode and when that extension is available we always > use the sRGB format. > > For bug 41052. > Just disabling EXT_texture_sRGB in this case is probably fine, but it's a little unfortunate that we already retrieve this information in init_format_fbo_compat_info(). Would it be hard to use that information instead?

1 0

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls
by Sebastian Lackner 14 Oct '16

14 Oct '16

On 12.10.2016 18:19, Aric Stewart wrote: > > Mostly by passing them to the bus driver where platform specific actions > happen > > v2: Suggestion from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > This patch no longer applies because of the slightly modified version of patch 1/2. I have already prepared a rebased version, but I'm wondering a bit: Couldn't we just pass through ALL ioctls (without any filtering in winehid)? This would reduce the code complexity even further. HID related FIXMEs could also be printed in winebus. hid_internal_dispatch should probably use the "hid" debug channel anyway. What do you think? Regards, Sebastian

2 3

Re: [1/3] gdiplus/tests: Add tests for 0-pixel pens.
by Marvin 13 Oct '16

13 Oct '16

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=26156 Your paranoid android. === wxppro (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2003std (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7u (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w8 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0

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