June 2015 - Wine-devel - list.winehq.org

Re: odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Nikolay Sivov 16 Jun '15

16 Jun '15

> + sect = heap_strdupAtoW(lpszSection); > + entry = heap_strdupAtoW(lpszEntry); > + string = heap_strdupAtoW(lpszDefault); > + file = heap_strdupAtoW(lpszFilename); > + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); > + > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > + if(ret) > + { > + WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); > + RetBuffer[ret] = 0; > + } > + > + heap_free(sect); > + heap_free(entry); > + heap_free(string); > + heap_free(file); > + > + heap_free(retval); Structurally it's fine, but you're using WCHAR count as CP_ACP char count, and it's wrong assumption in general.

1 0

Re: [1/3] winhttp: Improve parsing of cookie values.
by Marvin 16 Jun '15

16 Jun '15

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=14301 Your paranoid android. === w2000pro (32 bit winhttp) === winhttp.c:945: Test failed: failed to receive response 12152 winhttp.c:950: Test failed: failed unexpectedly 12019 winhttp.c:951: Test failed: request failed unexpectedly 3735928559

2 1

Re: [2/3] msvcirt: Add implementation of streambuf::sputc
by Piotr Caban 16 Jun '15

16 Jun '15

On 06/15/15 17:34, Iván Matellanes wrote: > + test_overflow_this = &sb2; > + ret = (int) call_func2(p_streambuf_sputc, &sb3, 'c'); You probably wanted to set the test_overflow_this to sb3 here. Thanks, Piotr

1 0

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

Hi, > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ref = get_refcount((IUnknown *)clipper); You're not reading ref anywhere as far as I can see. Did you forget to re-check the refcount after creating the device? If the refcount is incremented by 2 or more: See if the clipper is assigned to the render target and / or depth stencil. This wouldn't really do anything, but it's Microsoft we're talking about here. > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM3 interface (hr = %x).\n", hr); Minor mistake: IDirect3DRM2 vs IDirect3DRM3. > + memcpy(&driver, &IID_IDirect3DRGBDevice, sizeof(GUID)); I think an assignment should do the job. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice2 interface (hr = %x).\n", hr); I'd say "Cannot create IDirect3DRMDevice2 (hr = ...)" here. You're not retrieving an interface here. > + /* Fetch immediate mode device in order to access render target */ > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + todo_wine ok(hr == D3DRM_OK, "Cannot get IDirect3DDevice2 interface (hr = %x).\n", hr); > + if (FAILED(hr)) > + { > + IDirect3DRMDevice2_Release(device2); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM_Release(d3drm1); > + IDirectDrawClipper_Release(clipper); > + return; > + } You can use the cleanup label here too if you initialize the interface pointers to NULL and add checks for NULL before calling release. > + /* Check properties of primary and depth surfaces */ > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x).\n", hr); > + if (FAILED(hr)) > + goto cleanup; Minor nitpick: A "primary" surface represents the screen content. The correct term in in this case is "render target". Note that a primary surface can be a render target in fullscreen mode. > + ok((desc.dwWidth == rc.right) && (desc.dwHeight == rc.bottom), "Expected surface dimentions = %d, %d, got %d, %d.\n", > + rc.right, rc.bottom, desc.dwWidth, desc.dwHeight); > + expected_caps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE | DDSCAPS_SYSTEMMEMORY; > + todo_wine ok(desc.ddsCaps.dwCaps == expected_caps, "Expected %x for caps, got %x.\n", expected_caps, desc.ddsCaps.dwCaps); As discussed on IRC ignore DDSCAPS_SYSTEMMEMORY here. I think it happens because you use a RGB device, and I don't think it's something we should care about unless an application depends on this. Check dwRGBBitCount of the render target. It should match the bit depth of the screen mode. > + if (FAILED(hr = IDirectDraw_SetDisplayMode(ddraw, desc.dwWidth, desc.dwHeight, 8))) > + { > + win_skip("Cannot set display mode to 8bpp (hr = %x), skipping tests.\n", hr); > + IDirectDrawSurface7_Release(surface7); > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IUnknown_Release(unknown); > + IDirectDraw_Release(ddraw); > + goto cleanup; > + } There's no need to try to set the display mode to 8. Also testing if changing the mode works is outside the scope of this test. What's interesting is that the pixel format of the primary surface of a new device after changing the mode. Please also check the Z bit depth, and if the surface has stencil bits.

2 2

Re: [PATCH 2/5] wined3d: Implement SM4 discard in the GLSL shader backend.
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 14:07 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > --- > dlls/wined3d/glsl_shader.c | 35 +++++++++++++++++++++-------------- > 1 file changed, 21 insertions(+), 14 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5ba246e..eb98ffe 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -4704,22 +4704,29 @@ static void shader_glsl_texreg2rgb(const struct wined3d_shader_instruction *ins) > * If any of the first 3 components are < 0, discard this pixel */ > static void shader_glsl_texkill(const struct wined3d_shader_instruction *ins) > { > - struct glsl_dst_param dst_param; > + if (ins->ctx->reg_maps->shader_version.major >= 4) > + { > + struct glsl_src_param src_param; > > - /* The argument is a destination parameter, and no writemasks are allowed */ > - shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > - if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_glsl_add_src_param(ins, &ins->src[0], WINED3DSP_WRITEMASK_0, &src_param); > + shader_addline(ins->ctx->buffer, "if (bool(floatBitsToUint(%s))) discard;\n", src_param.param_str); > + } > + else > { > - if (ins->ctx->reg_maps->shader_version.major >= 4) > - FIXME("SM4 discard not implemented.\n"); > - /* 2.0 shaders compare all 4 components in texkill */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > - } else { > - /* 1.X shaders only compare the first 3 components, probably due to the nature of the texkill > - * instruction as a tex* instruction, and phase, which kills all a / w components. Even if all > - * 4 components are defined, only the first 3 are used > - */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > + struct glsl_dst_param dst_param; > + > + /* The argument is a destination parameter, and no writemasks are allowed */ > + shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > + > + /* 2.0 shaders compare all 4 components in texkill. */ > + if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > + /* 1.x shaders only compare the first 3 components, probably due to > + * the nature of the texkill instruction as a tex* instruction, and > + * phase, which kills all .w components. Even if all 4 components are > + * defined, only the first 3 are used. */ > + else > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > } > } > > -- > 2.1.4 FWIW, https://msdn.microsoft.com/en-us/library/windows/desktop/hh446968%28v=vs.85… mentions two variants of the discard instruction. Any clue how is that _z vs _nz part encoded?

2 1

DInput axis mapping explanation
by Michael Gardner 15 Jun '15

15 Jun '15

Please forgive me if this is the wrong list or a stupid question, but I already tried wine-users and the WineHQ forums and no one could answer. I'm trying to understand Wine's DirectInput axis mapping feature (registry key HKEY_CURRENT_USER\Software\Wine\DirectInput). The documentation at http://wiki.winehq.org/UsefulRegistryKeys gives some details but seems to assume you already know how the feature works. (You could also consider this an RFE for better DInput axis mapping docs, which I'd be happy to write if I can first understand the feature.) I understand that I can make a registry key with the same name as my joystick device and a value that's a comma-separated list of axes, which will act as some kind of mapping. But how does this mapping work? What is being mapped to what, exactly? The docs give an example mapping without explaining what it does, or how you'd arrive at that mapping given whatever result you're looking for. I've also read https://forum.winehq.org/viewtopic.php?t=14899, but it also doesn't explain how these mappings work in the abstract. Once again, my apologies if this is the wrong place, but if there's anyone who might have the knowledge I'm looking for then it would be the Wine devs.

2 1

Re: [PATCH] winscard: add stubs for SCardListReadersA/W (try 2)
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 9:31 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > From: Austin English <austinenglish(a)gmail.com> > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26978 > > replaced return code after suggestion by Bruno Jesus. > --- > dlls/winscard/winscard.c | 12 ++++++++++++ > dlls/winscard/winscard.spec | 4 ++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c > index bcf8129..70b3914 100644 > --- a/dlls/winscard/winscard.c > +++ b/dlls/winscard/winscard.c > @@ -129,3 +129,15 @@ void WINAPI SCardReleaseStartedEvent(void) > { > FIXME("stub\n"); > } > + > +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, LPCSTR groups, LPSTR readers, LPDWORD buflen) Not sure it matters much here but I'd stick to avoiding LP* types, as by usual Wine style.

1 0

Re: riched: Added ITextDocument2 definition and corresponding tests
by Alexandre Julliard 15 Jun '15

15 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > From 5583828198dff5f5e19606ba11f1cf961f78f7c5 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Tue, 2 Jun 2015 01:32:52 +0300 > Subject: [PATCH] riched: Added ITextDocument2 definition and corresponding > tests It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M riched20.dll -p riched20_test.exe.so richole && touch richole.ok fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:richedit:IRichEditOleImpl_inner_fnQueryInterface 0x3334e0: unhandled interface {01c25500-4268-11d1-883a-3c8b00c10000} richole.c:150: Test failed: got 0x80004002 wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed4b59e (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Use random names when caching very long urls.
by Piotr Caban 15 Jun '15

15 Jun '15

Hi, this will not work for filenames a little shorter than MAX_PATH. Whole file path needs to fit into MAX_PATH characters (not only the file name). Thanks, Piotr

1 0

Re: [PATCH 2/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

> Am 11.06.2015 um 13:51 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &surface); > + ok(hr == DD_OK, "Cannot get surface to the render target (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; > + > + /* Check properties of primary and depth surfaces */ > + memset(&desc, 0, sizeof(desc)); > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; Checking the surface desc isn't really relevant here. The interesting check is if the render target returned by GetRenderTarget is the surface you passed to CreateDeviceFromSurface. Please add a test that shows that an error is returned if the surface was created without 3DDEVICE. > > + hr = IDirectDrawSurface_GetAttachedSurface(surface, &caps, &ds); > + ok(hr == DD_OK, "Cannot get attached depth surface (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; What happens if you attach a depth surface yourself before calling CreateDeviceFromSurface? Does d3drm replace it? > + hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface7, (void**)&surface7); > + ok(hr == DD_OK, "Cannot get IDirectDrawSurface7 interface (hr = %x)\n", hr); > + > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IDirectDrawSurface7_Release(surface7); The QueryInterface call here is redundant.

3 3