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

Re: secur32/tests: Don't load crypt32.dll function dynamically.
by Marvin June 14, 2016

June 14, 2016

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=23615 Your paranoid android. === w1064 (32 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308. === w1064 (64 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Guillaume Charifi June 14, 2016

June 14, 2016

Hello, thank you for your feedback :) I just sent a patch that fixes the NaN issue in all places it can happen (at least in the GLSL backend). Well, stupid drivers... It seems to work really well with Mesa, but I just saw some 1 fps benchmarks, so I guess it's a *nope*. I'll do a test to make you happy, and try to fix the other things. :) <div>-------- Message d'origine --------</div><div>De : Józef Kucia <joseph.kucia(a)gmail.com> </div><div>Date :13/06/2016 20:32 (GMT+01:00) </div><div>À : wine-devel <wine-devel(a)winehq.org> </div><div>Cc : Guillaume Charifi <guillaume.charifi(a)sfr.fr> </div><div>Objet : Re: [PATCH] wined3d: Implement icb dcl support in GLSL. </div><div> </div>This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Marvin June 14, 2016

June 14, 2016

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=23604 Your paranoid android. === w864 (32 bit process) === process.c:2859: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Alexandre Julliard June 14, 2016

June 14, 2016

Marcus Meissner <marcus(a)jet.franken.de> writes: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > + FILE *f; > + unsigned long hugepagesize = 0; > + > + f = fopen( "/proc/meminfo", "r" ); > + if (f) > + { > + char buffer[256]; > + > + while (fgets( buffer, sizeof(buffer), f )) > + { > + if (sscanf( buffer, "Hugepagesize: %lu", &hugepagesize )) > + break; > + } > + fclose( f ); > + } > + return (SIZE_T)hugepagesize*1024; > +#else > + FIXME("stub: not implemented on your platform.\n"); > + return 0; > +#endif This could probably be simply hard-coded based on the CPU architecture. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by Ken Thomases June 14, 2016

June 14, 2016

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Sliders, Dials, and Wheels now map to Z, U (Ry), or V (Rx) depending on > availability. Thus, also adds support for up to 3 such HID elements. > dlls/winejoystick.drv/joystick_osx.c | 20 +++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c > index 77dbef8..4e59ca3 100644 > --- a/dlls/winejoystick.drv/joystick_osx.c > +++ b/dlls/winejoystick.drv/joystick_osx.c > @@ -442,8 +442,26 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kHIDUsage_GD_Slider: > - TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_Slider; ignoring\n"); > + case kHIDUsage_GD_Dial: > + case kHIDUsage_GD_Wheel: > + { > + //if one axis is taken, fall to the next until axes are filled Line comments (//) are not allowed in most of Wine. > + int possible_axes[3] = {AXIS_Z,AXIS_RY,AXIS_RX}; > + int axis = 0; > + TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_<axis> (%d)", usage); > + while(axis < 3 && joystick->axes[possible_axes[axis]].element) > + axis++; > + if (axis == 3) > + TRACE(" ignoring\n"); > + else > + { > + TRACE(" axis %d\n", possible_axes[axis]); Rather than breaking the trace line across multiple TRACEs, you should just move the TRACE to after the selection of an axis. Note that in the existing code, the "ignoring" TRACEs are on a separate line, which is why they are indented. It doesn't make sense to have that extra space if that isn't on a separate line. Alternatively, you could put a newline on the first TRACE and indent the axis trace as a subordinate line. > + joystick->axes[possible_axes[axis]].element = (IOHIDElementRef)CFRetain(child); > + joystick->axes[possible_axes[axis]].min_value = IOHIDElementGetLogicalMin(child); > + joystick->axes[possible_axes[axis]].max_value = IOHIDElementGetLogicalMax(child); > + } > break; > + } Is there reason to expect that these elements (sliders, dials, wheels) will be listed after the "proper" axes (x, y, z, etc.) in the children array? Since the proper axes are specific and these elements should only be mapped to unused axes, I think they should be enumerated in a separate pass after everything else has had a shot. Note that collect_joystick_elements() is recursive, so it's not right to do it in a separate loop within collect_joystick_elements(). Probably, you'll want to call it twice from open_joystick(), with a flag to indicate which mode it should operate in. -Ken

2 3

Re: [MASSMAIL][PATCH] kernel32: implement GetLargePageMinimum
by Dmitry Timoshkov June 14, 2016

June 14, 2016

Marcus Meissner <marcus(a)jet.franken.de> wrote: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > +#ifdef __i386__ > + /* Linux x86 hugepages are 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} What's the reason of making it linux only and excluding x86_64? -- Dmitry.

1 0

Differences between named pipes in Windows and Wine
by Ryan Prichard June 14, 2016

June 14, 2016

Hi, I noticed a handful of differences in the "lifecycle" of named pipes between Windows and Wine, and I figured I'd post about them here. I wrote a standalone one-file C++ program that demonstrates the differences I found. (In that test, the pipe handles are always overlapped and PIPE_WAIT.) I tested using wine-1.9.12. The differences were: 1. With Windows, there can be multiple concurrent ConnectNamedPipe operations on a pipe. With Wine, the second ConnectNamedPipe call fails with ERROR_INVALID_HANDLE. 2. With Windows, DisconnectNamedPipe aborts ConnectNamedPipe operations with the error ERROR_PIPE_NOT_CONNECTED. The DisconnectNamedPipe call succeeds, and the pipe is no longer listening. With Wine, the DisconnectNamedPipe call itself fails with ERROR_PIPE_LISTENING, and the pipe is still listening. 3. With Windows, if the server breaks the pipe by closing its handle, the client can finish reading the remaining data in the pipe. Once the data is gone, reading from a broken pipe fails with ERROR_BROKEN_PIPE. Writing to a broken pipe fails with ERROR_NO_DATA. With Wine, once the server breaks the pipe, the client cannot read the remaining data, and I/O on a broken pipe fails with ERROR_PIPE_NOT_CONNECTED. (Exception: ReadFile on a server pipe still returns ERROR_BROKEN_PIPE.) 4. Calling ConnectNamedPipe on a broken server pipe fails with ERROR_NO_DATA on Windows, but ERROR_NO_DATA_DETECTED on Wine. My test program is at: https://gist.github.com/rprichard/8dd8ca134b39534b7da2733994aa07ba. It passes on XP, Vista, Win7, and Win10, with the exception of testChangeMaxInstancesAfterClosingLastServerHandle, which passes on Vista and up. A couple of the more interesting tests are testDisconnectAtStartup and testReadFromBrokenClientPipe: testDisconnectAtStartup: // Calling DisconnectNamedPipe on a new pipe successfully transitions it to a // "Not Connected" state. The second DisconnectNamedPipe call fails, and the // client can't connect. void testDisconnectAtStartup() { const HANDLE server = assertValid(openServer(name(0))); CHECK_SUCCESS(DisconnectNamedPipe(server)); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_FAILURE(DisconnectNamedPipe(server), ERROR_PIPE_NOT_CONNECTED); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_SUCCESS(CloseHandle(server)); } // If a client pipe is broken, rather than disconnected, the remaining data can // still be read. void testReadFromBrokenClientPipe() { DWORD actual = 0; Over over; char buf[2] = {}; const HANDLE server = assertValid(openServer(name(0))); const HANDLE client = assertValid(createFile(name(0))); CHECK_SUCCESS(WriteFile(server, buf, 1, &actual, &over)); CHECK_SUCCESS(CloseHandle(server)); CHECK_SUCCESS(ReadFile(client, buf, 2, &actual, &over)); CHECK(actual == 1); CHECK_FAILURE(ReadFile(client, buf, 2, &actual, &over), ERROR_BROKEN_PIPE); CHECK_SUCCESS(CloseHandle(client)); } I know that item #3 above breaks my winpty project (in principle), where a pipe server signals EOF by closing a pipe without disconnecting it. The winpty client can read all the output before hitting the broken pipe. I suspect winpty may not run on Wine anyway, though. -Ryan

2 1

wine-1.8.3-rc2 Available
by Michael Stefaniuc June 13, 2016

June 13, 2016

Hello guys, wine-1.8.3-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ There is just a small change compared to rc1 but that required a rebase and thus you'll see a forced upgrade. Changes to rc1: --------------- The two ole32 patches were deferred to a future 1.8.x version. They need more testing in the wild to make them less risky for Stable: - ole32: Implement StgOpenPropStg. - ole32: Implement StgCreatePropStg. This should be the final rc for 1.8.3 (famous last words...) bye michael

1 0

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Marvin June 13, 2016

June 13, 2016

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=23562 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw1) === ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw7) === ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw2) === ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw4) === ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result.

2 1

Re: [PATCH 3/3] msscript: Implement Timeout property
by Jacek Caban June 13, 2016

June 13, 2016

Hi Nikolay, On 06/11/2016 12:02 PM, Nikolay Sivov wrote: > static HRESULT WINAPI ScriptControl_put_Timeout(IScriptControl *iface, LONG milliseconds) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%d)\n", This, milliseconds); > - return E_NOTIMPL; > + > + TRACE("(%p)->(%d)\n", This, milliseconds); > + > + if (milliseconds < -1) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + This->timeout = milliseconds; > + return S_OK; > } Getter/setter implementation seems fine, but it's not full implementation and I'm pretty sure that at least first versions that will be able to execute script code won't support that (builtin jscript nor vbscript supports that, so there is very little point in implementing it here), so FIXME or WARN here would be more appropriate here. Thanks, Jacek

2 2