- wine-devel - winehq.org

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

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