July 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL

by Piotr Caban

On 07/27/16 21:49, Daniel Lehman wrote: > +@ stub ??$_Getvals(a)_W@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@IAAX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@IAEX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@IEAAX_WAEBV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@IAAX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@IAEX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@IEAAX_WAEBV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@IAAX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@IAEX_WABV_Locinfo(a)1@@Z > +@ stub ??$_Getvals(a)_W@?$time_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@IEAAX_WAEBV_Locinfo(a)1@@Z Could you please add -arch specifiers to stub entries? Thanks, Piotr

July 28, 2016

Re: avifil32: Use debugstr_a() and debugstr_w() in TRACE() messages.

by Michael Stefaniuc

On 07/28/2016 02:11 PM, Nikolay Sivov wrote: > I see it's Rejected on the patch list, it's indeed wrong, because you're > tracing output parameters. Hehehe, yeah. I run into the same issue with my first version of the debugstr_guid() script. The search and replace programming style can be tricky at times ;) bye michael

July 28, 2016

Re: avifil32: Use debugstr_a() and debugstr_w() in TRACE() messages.

by Nikolay Sivov

I see it's Rejected on the patch list, it's indeed wrong, because you're tracing output parameters.

July 28, 2016

Re: [PATCH 2/6] d3d9/tests: Add visual tests for locking vertexbuffers

by Henri Verbeet

On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > + static const struct > + { > + const char *flags_s; > + unsigned int flags; > + DWORD usage; > + BOOL unsyncronized; > + BOOL todo; > + BOOL broken; > + } > + /* Nvidia ignores D3DLOCK_NOOVERWRITE on non dynamic buffers, > + * while AMD always accepts D3DLOCK_NOOVERWRITE on all buffers. */ > + tests[] = > + { > + {"0", 0, 0, FALSE, FALSE, FALSE}, > + {"0", 0, D3DUSAGE_DYNAMIC, FALSE, FALSE, FALSE}, > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, D3DUSAGE_DYNAMIC, TRUE, FALSE, FALSE}, > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, 0, FALSE, FALSE, FALSE}, > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, D3DUSAGE_DYNAMIC, FALSE, FALSE, FALSE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > + }; [...] > + todo_wine_if (tests[i].todo) > + { > + ok(tests[i].unsyncronized == unsyncronized || broken(tests[i].broken), > + "Expected buffer mapped %s. Flags = %s. Usage = %#x.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } I assume the broken() is for the testbot, but the way this is written, half the cases aren't really tested on Windows. Also, what makes these fail on the testbot? > + timestamp1 = GetTickCount(); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitive(device, D3DPT_TRIANGLESTRIP, 0, tri); > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > + > + /* dummy read to wait for GPU being done */ > + color = getPixelColor(device, 160, 360); > + > + timestamp2 = GetTickCount(); > + > + /* Adjust buffer size for 1 second draw call duration */ > + size = (size * 1000UL) / (timestamp2 - timestamp1 + 1); Does this work reliably? GetTickCount() has very limited resolution, I think there's a real chance that the draw will take only a fraction of GetTickCount()'s resolution.

July 28, 2016

Re: [PATCH 1/6] wined3d/resource: Add flag WINED3D_MAP_WRITEONLY

by Henri Verbeet

On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > #define WINED3D_MAP_READONLY 0x0010 > +#define WINED3D_MAP_WRITEONLY 0x0020 But now the API is weird. What happens when both READONLY and WRITEONLY are set? I think the d3d11 model makes more sense.

July 28, 2016

Re: [PATCH 2/2 v4] ucrtbase: Add _get_narrow_winmain_command_line tests

by Piotr Caban

On 07/28/16 13:33, Dmitry Timoshkov wrote: > Piotr Caban <piotr(a)codeweavers.com> wrote: > >>>> + sprintf(cmd, "\"\"%c\"\"\"%s\" \t \"misc\" cmd", name[0], name+1); >>>> + memset(&startup, 0, sizeof(startup)); >>>> + startup.cb = sizeof(startup); >>>> + CreateProcessA(path, cmd, NULL, NULL, TRUE, >>>> + CREATE_DEFAULT_ERROR_MODE|NORMAL_PRIORITY_CLASS, >>>> + NULL, NULL, &startup, &proc); >>>> + winetest_wait_child_process(proc.hProcess); >>> >>> Thanks for adding the tests. It shouldn't be too hard to also test other >>> white space characters, at least testing '\r' and '\n' would be nice to >>> have. >>> >> CreateProcess will fail in case of '\r' or '\n' characters. > > In a simple test CreateProcess() works just fine here under Windows 7 when a > passed in command line contains '\r' and/or '\n', where does it fail for you? > I'll try to be a little more precise - '\r' is treated as another argument so it can't be used before first argument (misc in this case).

July 28, 2016

Re: [PATCH 2/2 v4] ucrtbase: Add _get_narrow_winmain_command_line tests

by Dmitry Timoshkov

Piotr Caban <piotr(a)codeweavers.com> wrote: > >> + sprintf(cmd, "\"\"%c\"\"\"%s\" \t \"misc\" cmd", name[0], name+1); > >> + memset(&startup, 0, sizeof(startup)); > >> + startup.cb = sizeof(startup); > >> + CreateProcessA(path, cmd, NULL, NULL, TRUE, > >> + CREATE_DEFAULT_ERROR_MODE|NORMAL_PRIORITY_CLASS, > >> + NULL, NULL, &startup, &proc); > >> + winetest_wait_child_process(proc.hProcess); > > > > Thanks for adding the tests. It shouldn't be too hard to also test other > > white space characters, at least testing '\r' and '\n' would be nice to > > have. > > > CreateProcess will fail in case of '\r' or '\n' characters. In a simple test CreateProcess() works just fine here under Windows 7 when a passed in command line contains '\r' and/or '\n', where does it fail for you? -- Dmitry.

July 28, 2016

Re: [PATCH 2/2 v4] ucrtbase: Add _get_narrow_winmain_command_line tests

by Piotr Caban

On 07/28/16 13:08, Dmitry Timoshkov wrote: > Piotr Caban <piotr(a)codeweavers.com> wrote: > >> + sprintf(cmd, "\"\"%c\"\"\"%s\" \t \"misc\" cmd", name[0], name+1); >> + memset(&startup, 0, sizeof(startup)); >> + startup.cb = sizeof(startup); >> + CreateProcessA(path, cmd, NULL, NULL, TRUE, >> + CREATE_DEFAULT_ERROR_MODE|NORMAL_PRIORITY_CLASS, >> + NULL, NULL, &startup, &proc); >> + winetest_wait_child_process(proc.hProcess); > > Thanks for adding the tests. It shouldn't be too hard to also test other > white space characters, at least testing '\r' and '\n' would be nice to > have. > CreateProcess will fail in case of '\r' or '\n' characters.

July 28, 2016

Re: [PATCH 2/2 v4] ucrtbase: Add _get_narrow_winmain_command_line tests

by Dmitry Timoshkov

Piotr Caban <piotr(a)codeweavers.com> wrote: > + sprintf(cmd, "\"\"%c\"\"\"%s\" \t \"misc\" cmd", name[0], name+1); > + memset(&startup, 0, sizeof(startup)); > + startup.cb = sizeof(startup); > + CreateProcessA(path, cmd, NULL, NULL, TRUE, > + CREATE_DEFAULT_ERROR_MODE|NORMAL_PRIORITY_CLASS, > + NULL, NULL, &startup, &proc); > + winetest_wait_child_process(proc.hProcess); Thanks for adding the tests. It shouldn't be too hard to also test other white space characters, at least testing '\r' and '\n' would be nice to have. -- Dmitry.

July 28, 2016

Re: [PATCH 2/2] DInput : Use vendor and product ids to generate product GUID like it's done on Windows

by DavidL

I'm not really familiar with the intricacies of the guid generation ... but looking at the Mac dinput code ... should a similar patch be applied there? Cheers, David On Sun, Jul 24, 2016 at 3:15 AM, Corentin Rossignon <corossig(a)gmail.com> wrote: > Done, thanks for taking some times and helping me doing a proper patch. > > > > On 07/24/2016 12:03 AM, Bruno Jesus wrote: > >> On Sat, Jul 23, 2016 at 8:01 AM, Corentin Rossignon <corossig(a)gmail.com> >> wrote: >> >>> Signed-off-by: Corentin Rossignon <corossig(a)gmail.com> >>> --- >>> dlls/dinput/joystick_linux.c | 34 >>> +++++++++++++++++++++++++++++++--- >>> dlls/dinput/joystick_linuxinput.c | 27 +++++++++++++++++++++++++-- >>> 2 files changed, 56 insertions(+), 5 deletions(-) >>> >> Formatting problem: >> >> bruno(a)Note:~/programs/wine$ git apply dinput2 >> dinput2:31: trailing whitespace. >> /* >> dinput2:35: trailing whitespace. >> * Data4 seems to be a constant. >> dinput2:104: trailing whitespace. >> /* >> dinput2:108: trailing whitespace. >> * Data4 seems to be a constant. >> warning: 4 lines add whitespace errors. >> >> diff --git a/dlls/dinput/joystick_linux.c b/dlls/dinput/joystick_linux.c >>> index 90b7280..f8499ca 100644 >>> --- a/dlls/dinput/joystick_linux.c >>> +++ b/dlls/dinput/joystick_linux.c >>> @@ -77,6 +77,7 @@ struct JoyDev >>> { >>> char device[MAX_PATH]; >>> char name[MAX_PATH]; >>> + GUID guid_product; >>> >>> BYTE axis_count; >>> BYTE button_count; >>> @@ -122,6 +123,21 @@ static const GUID DInput_Wine_Joystick_GUID = { /* >>> 9e573ed9-7734-11d2-8d4a-23903 >>> {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} >>> }; >>> >>> + >>> +/* >>> + * Construct the GUID in the same way of Windows doing this. >>> + * Data1 is concatenation of productid and vendorid. >>> + * Data2 and Data3 are NULL. >>> + * Data4 seems to be a constant. >>> + */ >>> +static const GUID DInput_Wine_Joystick_Constant_Part_GUID = { >>> + 0x000000000, >>> + 0x0000, >>> + 0x0000, >>> + {0x00, 0x00, 0x50, 0x49, 0x44, 0x56, 0x49, 0x44} >>> +}; >>> + >>> + >>> >> Please remove all double blank lines in your changes in order to be >> more compatible with the surrounding code style. >> > > > >

July 28, 2016