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

Re: [v1 1/1] dinput: Sort virtual joysticks by name on the Mac

by Ken Thomases

On Jul 16, 2016, at 3:15 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 35 ++++++++++++++++++++++++++++++++--- > 1 file changed, 32 insertions(+), 3 deletions(-) > > diff --git a/dlls/dinput/joystick_osx.c b/dlls/dinput/joystick_osx.c > index 637692b..22bdc4f 100644 > --- a/dlls/dinput/joystick_osx.c > +++ b/dlls/dinput/joystick_osx.c > @@ -193,6 +193,26 @@ static long get_device_property_long(IOHIDDeviceRef device, CFStringRef key) > return result; > } > > +static CFStringRef get_device_name(IOHIDDeviceRef device) > +{ > + CFTypeRef ref; > + CFStringRef name = CFSTR("Default Name"); You can probably do better for a fallback. For example, you can format the vendor ID and product ID into a string. For an extreme take on this, see the Copy_DeviceName() function in Apple's HID Calibrator sample code: https://developer.apple.com/library/mac/samplecode/HID_Calibrator/Listings/… > + > + if(device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(device)); > + > + ref = IOHIDDeviceGetProperty(device, CFSTR(kIOHIDProductKey)); > + > + if (ref && CFStringGetTypeID() == CFGetTypeID(ref)) > + name = ref; > + else if (ref) > + name = CFCopyDescription(ref); This introduces a memory-management problem, a.k.a. a leak. This copy is never released. If you follow my suggestion above for formatting a string as a fallback if the product name isn't available, you'd also have to release that. So, you would change this function's name to copy_device_name() and make sure all code paths return an owned reference to the caller, which the caller has to release. Basically, in the case where IOHIDDeviceGetProperty() gives you a string, you'd have to copy it to match the other code paths. Of course, you'd have to make sure the callers do, in fact, release the references. > + } > + > + return name; > +} > + > static long get_device_location_ID(IOHIDDeviceRef device) > { > return get_device_property_long(device, CFSTR(kIOHIDLocationIDKey)); > @@ -203,7 +223,15 @@ static void copy_set_to_array(const void *value, void *context) > CFArrayAppendValue(context, value); > } > > -static CFComparisonResult device_location_comparator(const void *val1, const void *val2, void *context) > +static CFComparisonResult device_name_comparator(IOHIDDeviceRef device1, IOHIDDeviceRef device2) > +{ > + CFStringRef name1 = get_device_name(device1), name2 = get_device_name(device2); > + CFStringCompareFlags compareOptions = kCFCompareForcedOrdering | kCFCompareNumerically; Any reason you've added this separate variable instead of just inlining the options in the call? > + > + return CFStringCompare(name1, name2, compareOptions); > +} -Ken

July 17, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Bernhard Übelacker

Hello, just tried to find out when this started exactly. First by using old packages from snapshot.debian.org. That revealed it started between packages: gcc-mingw-w64-i686_4.6.4-4+9_i386.deb gcc-mingw-w64-i686_4.8.2-5+10_i386.deb A git bisect of gcc history points to this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff2a5adaa72fef87cac689a40… ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit commit ff2a5adaa72fef87cac689a40c23258a30b304c8 Author: hubicka <hubicka(a)138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sun Apr 22 21:28:07 2012 +0000 * lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags. (...much longer commit message...) git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk(a)186687 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 d706bdeafbddb9f5f02474e39a245dca08f3334a 508082a31919fe9e907f70b3b3278d4f8d953fac M gcc Testbot runs: Good: (gcc 62c34bf, last one before ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24283 Bad: (gcc ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24280 Hope this could be of any help to identify the issue. Kind regards, Bernhard Notes: - Did not install gcc build system wide. Instead set the PATH that i686-w64-mingw32-gcc was taken from there. - Initial wine configure step was done using Jessie default gcc-mingw-w64-i686 4.9.1-19+14.3. Then the iterations were just done by removing objects from dlls/dinput8/tests and make dinput8_crosstest.exe. - GCC history before 1e37e371 did segfault while building, therefore started from there. Am 24.04.2016 um 20:30 schrieb Francois Gouget: > > I have rechecked this to make sure the test does not have a subtle bug > that causes it to depend on the stack layout. > > > In the process I have reduced the test to the minimum set necessary to > reproduce the bug (see attachment). But in the end I did not find > anything wrong so it does look like a compiler bug. > > I don't know how to proceed from there. > > * I think it would be better if someone more knowlegeable than me > reported this bug to the MinGW guys. Maybe someone who could undertand > what happens in the assembly code? > > * On the Wine side it would really be nice to get this test (and > the three others that are impacted) to stop failing. But removing all > the static directives really does not feel right. Would it be better > to arrange for these tests to be compiled with -O0? Any other cleaner > workaround. > > So I'm really hoping someone can step up and move this forward. > > > Here are the relevant bugs: > * dinput8:dinput regression caused by new compiler > https://bugs.winehq.org/show_bug.cgi?id=40384 > > * usp10:usp10 regression caused by new cross-compiler > https://bugs.winehq.org/show_bug.cgi?id=40385 > > * wininet:url regression caused by new cross-compiler > https://bugs.winehq.org/show_bug.cgi?id=40386 > > * Unexplained new random comctl32:header failure (cross-compiler issue?) > https://bugs.winehq.org/show_bug.cgi?id=40442 > > > >

July 17, 2016

Re: [PATCH] winegstreamer: Fixes for video flipping

by Jan Schmidt

On 16/07/16 09:12, Jan Schmidt wrote: > On 16/07/16 05:25, Andrew Eikum wrote: > >>> Fix state setting of new elements - always just >>> set them to PAUSED. gst_element_sync_state_with_parent() >>> can be problematic, and we only need these in paused >>> or playing anyway. >>> >> >> I'm not sure about this part. It makes sense to me for all members of >> a container to be in the same state. Why is it better for these to be >> PAUSED while others are PLAYING? If it's needed, this should be its >> own patch, too. > > This is actually the part that fixes bug 40764 (although the refcounting > ones are needed to avoid crashes too). You can set them to PLAYING or > PAUSED - it doesn't actually matter. The only difference between playing > and paused states in GStreamer is in elements that do operations on the > clock, such as audio or video sinks. For videoflip and videoconvert the > important thing is that they aren't still in READY state by the time > they receive data, because then their pads will not have been activated. > That's the core of the race condition that's causing 40764. Actually, I just realised this isn't true. The actual cause of 40764 is replacing the bus on decodebin which is now inside the container bin. It was OK when decodebin was the top-level element, but not when it's a child element. Setting the bus on the top-level bin is sufficient to fix 40764 reliably, which I'd fixed separately while cleaning up the ref-counting. Continuing to use gst_element_sync_state_to_parent here seems OK. New patches coming soon. J. -- Jan Schmidt, Centricular Ltd - http://centricular.com/

July 15, 2016

Re: [PATCH] winegstreamer: Fixes for video flipping

by Jan Schmidt

On 16/07/16 05:25, Andrew Eikum wrote: > Thanks very much for working on this, I'm glad to have more eyes > looking at it. Comments in-line below. > > On Sat, Jul 16, 2016 at 02:51:10AM +1000, Jan Schmidt wrote: >> The videoflip element doesn't handle all formats, >> so some formats like Intel Indeo 3 will fail. >> Add videoconvert to do format conversion when it's >> needed. >> > > Shouldn't the decodebin handle this during format negotiation when the > videoflip is connected to it? No, decodebin only handles decoding - it stops and outputs pads once it successfully decodes raw video or audio. >> Fix some refcount issues too - add a new element >> to a bin takes ownership of the floating reference, >> so there's no need to keep pointers around to unref >> later. >> > > Good catch. Could you separate this out into a different, stand-alone > patch from the other changes? OK >> Fix state setting of new elements - always just >> set them to PAUSED. gst_element_sync_state_with_parent() >> can be problematic, and we only need these in paused >> or playing anyway. >> > > I'm not sure about this part. It makes sense to me for all members of > a container to be in the same state. Why is it better for these to be > PAUSED while others are PLAYING? If it's needed, this should be its > own patch, too. This is actually the part that fixes bug 40764 (although the refcounting ones are needed to avoid crashes too). You can set them to PLAYING or PAUSED - it doesn't actually matter. The only difference between playing and paused states in GStreamer is in elements that do operations on the clock, such as audio or video sinks. For videoflip and videoconvert the important thing is that they aren't still in READY state by the time they receive data, because then their pads will not have been activated. That's the core of the race condition that's causing 40764. >> @@ -846,13 +855,16 @@ static void init_new_decoded_pad(GstElement *bin, GstPad *pad, GSTImpl *This) >> >> gst_util_set_object_arg(G_OBJECT(pin->flipfilter), "method", "vertical-flip"); >> >> - gst_bin_add(GST_BIN(This->container), pin->flipfilter); >> - gst_element_sync_state_with_parent(pin->flipfilter); >> + gst_element_set_state (vconv, GST_STATE_PAUSED); >> + gst_bin_add(GST_BIN(This->container), vconv); /* bin takes ownership */ >> + gst_element_set_state (pin->flipfilter, GST_STATE_PAUSED); >> + gst_bin_add(GST_BIN(This->container), pin->flipfilter); /* bin takes ownership */ >> >> - pin->flip_sink = gst_element_get_static_pad(pin->flipfilter, "sink"); >> + gst_element_link (vconv, pin->flipfilter); >> + >> + pin->flip_sink = gst_element_get_static_pad(vconv, "sink"); >> if(!pin->flip_sink){ >> WARN("Couldn't find sink on flip filter\n"); >> - gst_object_unref(pin->flipfilter); > > I believe this leaves a dangling element in the container. Should > these lines be replaced with calls to gst_bin_remove() instead? Those lines replace the insertion of videoflip with the insertion of 'videoconvert -> videoflip' as a linked pair and then treats them as a single unit - getting the sink pad of the first element, and the source pad of the videoflip. The elements are owned by the bin afterward, so there's no need to keep a ref or clean them up explictly. They'll be disposed of automatically when the container is unreffed on cleanup. Cheers, Jan. > Andrew > -- Jan Schmidt, Centricular Ltd - http://centricular.com/

July 15, 2016

Re: [PATCH] winegstreamer: Fixes for video flipping

by Andrew Eikum

Thanks very much for working on this, I'm glad to have more eyes looking at it. Comments in-line below. On Sat, Jul 16, 2016 at 02:51:10AM +1000, Jan Schmidt wrote: > The videoflip element doesn't handle all formats, > so some formats like Intel Indeo 3 will fail. > Add videoconvert to do format conversion when it's > needed. > Shouldn't the decodebin handle this during format negotiation when the videoflip is connected to it? > Fix some refcount issues too - add a new element > to a bin takes ownership of the floating reference, > so there's no need to keep pointers around to unref > later. > Good catch. Could you separate this out into a different, stand-alone patch from the other changes? > Fix state setting of new elements - always just > set them to PAUSED. gst_element_sync_state_with_parent() > can be problematic, and we only need these in paused > or playing anyway. > I'm not sure about this part. It makes sense to me for all members of a container to be in the same state. Why is it better for these to be PAUSED while others are PLAYING? If it's needed, this should be its own patch, too. > @@ -846,13 +855,16 @@ static void init_new_decoded_pad(GstElement *bin, GstPad *pad, GSTImpl *This) > > gst_util_set_object_arg(G_OBJECT(pin->flipfilter), "method", "vertical-flip"); > > - gst_bin_add(GST_BIN(This->container), pin->flipfilter); > - gst_element_sync_state_with_parent(pin->flipfilter); > + gst_element_set_state (vconv, GST_STATE_PAUSED); > + gst_bin_add(GST_BIN(This->container), vconv); /* bin takes ownership */ > + gst_element_set_state (pin->flipfilter, GST_STATE_PAUSED); > + gst_bin_add(GST_BIN(This->container), pin->flipfilter); /* bin takes ownership */ > > - pin->flip_sink = gst_element_get_static_pad(pin->flipfilter, "sink"); > + gst_element_link (vconv, pin->flipfilter); > + > + pin->flip_sink = gst_element_get_static_pad(vconv, "sink"); > if(!pin->flip_sink){ > WARN("Couldn't find sink on flip filter\n"); > - gst_object_unref(pin->flipfilter); I believe this leaves a dangling element in the container. Should these lines be replaced with calls to gst_bin_remove() instead? Andrew

July 15, 2016

Re: [PATCH 2/9] d3drm: Implement IDirect3DRMDevice*::InitFromD3D. (v2)

by Aaryaman Vasishta

On Fri, Jul 15, 2016 at 5:34 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I've just fixed some these up in the past, and let some others slide, > but please watch your line length. > > Right, sorry about that. I've started using a page guide in XCode so this shouldn't happen again. I'll resend the fixed patch.

July 15, 2016

Fwd: Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.

by Guillaume Charifi

Right, I was sure to forget to git add something... Do I need to resend everything, or is it ok if I send a patch that only enables the required extension, and will need to be committed before the others? Le 15/07/2016 13:59, Józef Kucia a écrit : > On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi > <guillaume.charifi(a)sfr.fr> wrote: >> Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> >> --- >> dlls/wined3d/glsl_shader.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c >> index 5e23920..376d110 100644 >> --- a/dlls/wined3d/glsl_shader.c >> +++ b/dlls/wined3d/glsl_shader.c >> @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) >> case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; >> case WINED3DSIH_SQRT: instruction = "sqrt"; break; >> case WINED3DSIH_UMAX: instruction = "max"; break; >> + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; > I think this requires you to enable appriopriate extension in GLSL > (GL_ARB_gpu_shader5, in this case). I haven't looked closely at the > other patches but they seem to have the same issue.

July 15, 2016

Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.

by Henri Verbeet

On 15 July 2016 at 13:59, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi > <guillaume.charifi(a)sfr.fr> wrote: >> Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> >> --- >> dlls/wined3d/glsl_shader.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c >> index 5e23920..376d110 100644 >> --- a/dlls/wined3d/glsl_shader.c >> +++ b/dlls/wined3d/glsl_shader.c >> @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) >> case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; >> case WINED3DSIH_SQRT: instruction = "sqrt"; break; >> case WINED3DSIH_UMAX: instruction = "max"; break; >> + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; > > I think this requires you to enable appriopriate extension in GLSL > (GL_ARB_gpu_shader5, in this case). I haven't looked closely at the > other patches but they seem to have the same issue. > Yeah, although the plan was to require GLSL 4.30 for shader model 5, which would have the various bitfield operations. I think this raises questions about how these patches were validated.

July 15, 2016

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)

by Henri Verbeet

On 15 July 2016 at 12:32, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/viewport.c b/dlls/d3drm/viewport.c > index 9fd627d..743fb75 100644 > --- a/dlls/d3drm/viewport.c > +++ b/dlls/d3drm/viewport.c > @@ -270,19 +279,126 @@ static HRESULT WINAPI d3drm_viewport1_GetClassName(IDirect3DRMViewport *iface, D > static HRESULT WINAPI d3drm_viewport2_Init(IDirect3DRMViewport2 *iface, IDirect3DRMDevice3 *device, > IDirect3DRMFrame3 *camera, DWORD x, DWORD y, DWORD width, DWORD height) > { > - FIXME("iface %p, device %p, camera %p, x %u, y %u, width %u, height %u stub!\n", > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport2(iface); > + D3DVIEWPORT vp; > + D3DVALUE scale; > + IDirect3D *d3d1 = NULL; > + D3DCOLOR color; > + IDirect3DDevice *d3d_device = NULL; > + IDirect3DMaterial *material = NULL; > + D3DMATERIAL mat; > + D3DMATERIALHANDLE hmat; > + HRESULT hr = D3DRM_OK; > + ... > + color = IDirect3DRMFrame3_GetSceneBackground(camera); > + /* Create material (ambient/diffuse/emissive?), set material */ > + if (FAILED(hr = IDirect3D_CreateMaterial(d3d1, &material, NULL))) > + goto cleanup; > + > + memset(&mat, 0, sizeof(mat)); > + memcpy(&mat.diffuse, &color, sizeof(color)); That doesn't look right.

July 15, 2016

Re: [PATCH 2/9] d3drm: Implement IDirect3DRMDevice*::InitFromD3D. (v2)

by Henri Verbeet

On 15 July 2016 at 12:32, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -3984,6 +3985,8 @@ static void test_create_device_from_d3d1(void) > ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u , ref2 = %u.\n", ref1, ref2); > device_ref2 = get_refcount((IUnknown *)d3ddevice1); > ok(device_ref2 > device_ref1, "Expected device_ref2 > device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); > + d3d_ref2 = get_refcount((IUnknown *)d3d1); > + ok(d3d_ref2 > d3d_ref1, "Expected d3d_ref2 > d3d_ref1, got d3d_ref1 = %u, d3d_ref2 = %u.\n", d3d_ref1, d3d_ref2); > ret_val = IDirect3DRMDevice_GetWidth(device1); > ok(ret_val == rc.right, "Expected device width = 300, got %u.\n", ret_val); > ret_val = IDirect3DRMDevice_GetHeight(device1); > @@ -4053,6 +4056,133 @@ static void test_create_device_from_d3d1(void) > device_ref2 = get_refcount((IUnknown *)d3ddevice1); > ok(device_ref2 == device_ref1, "Expected device_ref2 == device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); > > + /* InitFromD3D tests */ > + hr = IDirect3DRM_CreateObject(d3drm1, &CLSID_CDirect3DRMDevice, NULL, &IID_IDirect3DRMDevice, (void **)&device1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice interface (hr = %#x).\n", hr); > + > + hr = IDirect3DRMDevice_InitFromD3D(device1, NULL, d3ddevice1); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, NULL); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, d3ddevice1); > + ok(SUCCEEDED(hr), "Failed to initialise IDirect3DRMDevice interface (hr = %#x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u , ref2 = %u.\n", ref1, ref2); > + device_ref2 = get_refcount((IUnknown *)d3ddevice1); > + ok(device_ref2 > device_ref1, "Expected device_ref2 > device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); I've just fixed some these up in the past, and let some others slide, but please watch your line length.

July 15, 2016

Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.

by Józef Kucia

On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5e23920..376d110 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) > case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; > case WINED3DSIH_SQRT: instruction = "sqrt"; break; > case WINED3DSIH_UMAX: instruction = "max"; break; > + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; I think this requires you to enable appriopriate extension in GLSL (GL_ARB_gpu_shader5, in this case). I haven't looked closely at the other patches but they seem to have the same issue.

July 15, 2016

Re: [PATCH] msscript: Initial support for hosting script engines

by Jacek Caban

Hi Nikolay, On 14.07.2016 16:35, Nikolay Sivov wrote: > +static HRESULT init_script_host(const CLSID *clsid, ScriptHost **ret) > +{ > + IObjectSafety *objsafety; > + ScriptHost *host; > + HRESULT hr; > + > + *ret = NULL; > + > + host = heap_alloc(sizeof(*host)); > + if (!host) > + return E_OUTOFMEMORY; > + > + host->IActiveScriptSite_iface.lpVtbl = &ActiveScriptSiteVtbl; > + host->ref = 1; > + host->script = NULL; > + host->parse = NULL; > + host->clsid = *clsid; > + > + hr = CoCreateInstance(&host->clsid, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IActiveScript, (void**)&host->script); > + if (FAILED(hr)) { > + WARN("Failed to create an instance for %s, %#x\n", debugstr_guid(clsid), hr); > + goto failed; > + } > + > + hr = IActiveScript_QueryInterface(host->script, &IID_IObjectSafety, (void**)&objsafety); > + if (FAILED(hr)) { > + FIXME("Could not get IObjectSafety, %#x\n", hr); > + goto failed; > + } > + > + hr = IObjectSafety_SetInterfaceSafetyOptions(objsafety, &IID_IActiveScriptParse, INTERFACESAFE_FOR_UNTRUSTED_DATA, 0); > + if (FAILED(hr)) > + FIXME("SetInterfaceSafetyOptions failed, %#x\n", hr); This failure is important, please handle it well. > + IObjectSafety_Release(objsafety); > + > + hr = IActiveScript_SetScriptSite(host->script, &host->IActiveScriptSite_iface); > + if (FAILED(hr)) { > + WARN("SetScriptSite failed, %#x\n", hr); > + goto failed; > + } > + > + hr = IActiveScript_QueryInterface(host->script, &IID_IActiveScriptParse, (void**)&host->parse); > + if (FAILED(hr)) { > + WARN("Failed to get IActiveScriptParse, %#x\n", hr); > + goto failed; > + } This and... > + hr = IActiveScriptParse_InitNew(host->parse); > + if (FAILED(hr)) { > + WARN("InitNew failed, %#x\n", hr); > + goto failed; > + } ...this failure will cause ref leak. You have already set script site, so engine holds a reference to ScriptHost, but you only release one reference on failure. Using release_script_engine on failure should fix that. > + > + *ret = host; > + return S_OK; > + > +failed: > + IActiveScriptSite_Release(&host->IActiveScriptSite_iface); > + return hr; > +} > + > static HRESULT WINAPI ScriptControl_QueryInterface(IScriptControl *iface, REFIID riid, void **ppv) > { > ScriptControl *This = impl_from_IScriptControl(iface); > @@ -257,6 +498,10 @@ static ULONG WINAPI ScriptControl_Release(IScriptControl *iface) > if(!ref) { > if (This->site) > IOleClientSite_Release(This->site); > + if (This->host) { > + release_script_engine(This->host); > + IActiveScriptSite_Release(&This->host->IActiveScriptSite_iface); > + } > heap_free(This); > } > > @@ -321,15 +566,47 @@ static HRESULT WINAPI ScriptControl_Invoke(IScriptControl *iface, DISPID dispIdM > static HRESULT WINAPI ScriptControl_get_Language(IScriptControl *iface, BSTR *p) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + LPOLESTR progidW; > + HRESULT hr; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + if (!p) > + return E_POINTER; > + > + *p = NULL; > + > + if (!This->host) > + return S_OK; > + > + hr = ProgIDFromCLSID(&This->host->clsid, &progidW); > + if (FAILED(hr)) > + return hr; > + > + *p = SysAllocStringLen(progidW, lstrlenW(progidW)); How about SysAllocString instead? > + CoTaskMemFree(progidW); > + return *p ? S_OK : E_OUTOFMEMORY; > } > > static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR language) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(language)); > - return E_NOTIMPL; > + CLSID clsid; > + > + TRACE("(%p)->(%s)\n", This, debugstr_w(language)); > + > + if (language && FAILED(CLSIDFromProgID(language, &clsid))) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + if (This->host) { > + IActiveScriptSite_Release(&This->host->IActiveScriptSite_iface); > + This->host = NULL; > + } This will leave zombie script host and engine. You should probably use release_script_engine here as well. > + > + if (!language) > + return S_OK; > + > + return init_script_host(&clsid, &This->host); > } > > static HRESULT WINAPI ScriptControl_get_State(IScriptControl *iface, ScriptControlStates *p) > @@ -1379,6 +1656,7 @@ static HRESULT WINAPI ScriptControl_CreateInstance(IClassFactory *iface, IUnknow > script_control->ref = 1; > script_control->site = NULL; > script_control->cp_list = NULL; > + script_control->host = NULL; > > ConnectionPoint_Init(&script_control->cp_scsource, script_control, &DIID_DScriptControlSource); > ConnectionPoint_Init(&script_control->cp_propnotif, script_control, &IID_IPropertyNotifySink); > Thanks, Jacek

July 15, 2016

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)

by Aaryaman Vasishta

Hi, On Fri, Jul 15, 2016 at 4:27 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > On 07/15/2016 12:45 PM, Aaryaman Vasishta wrote: > > > > > > On Fri, Jul 15, 2016 at 4:02 PM, Aaryaman Vasishta > > <jem456.vasishta(a)gmail.com <mailto:jem456.vasishta(a)gmail.com>> wrote: > > > > struct d3drm_viewport > > { > > struct d3drm_object obj; > > + IDirect3DRMFrame *camera; > > IDirect3DRMViewport IDirect3DRMViewport_iface; > > IDirect3DRMViewport2 IDirect3DRMViewport2_iface; > > + IDirect3DViewport *d3d_viewport; > > + IDirect3DMaterial *material; > > IDirect3DRM *d3drm; > > D3DVALUE back; > > D3DVALUE front; > > > > I've decided to keep the interface instead of using the struct directly, > > since it'll be easier to use the interface functions for transformations > > and other paramaters. Referencing the interface via the object for every > You can do that as long as you can use only methods of those interfaces. > As soon as you need to access fields of the object struct directly you > need to save the object pointer. > > bye > michael > > Right, I'll keep that in mind once an implementation requires it :) Cheers, Aaryaman

July 15, 2016

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)

by Michael Stefaniuc

On 07/15/2016 12:45 PM, Aaryaman Vasishta wrote: > > > On Fri, Jul 15, 2016 at 4:02 PM, Aaryaman Vasishta > <jem456.vasishta(a)gmail.com <mailto:jem456.vasishta(a)gmail.com>> wrote: > > struct d3drm_viewport > { > struct d3drm_object obj; > + IDirect3DRMFrame *camera; > IDirect3DRMViewport IDirect3DRMViewport_iface; > IDirect3DRMViewport2 IDirect3DRMViewport2_iface; > + IDirect3DViewport *d3d_viewport; > + IDirect3DMaterial *material; > IDirect3DRM *d3drm; > D3DVALUE back; > D3DVALUE front; > > I've decided to keep the interface instead of using the struct directly, > since it'll be easier to use the interface functions for transformations > and other paramaters. Referencing the interface via the object for every You can do that as long as you can use only methods of those interfaces. As soon as you need to access fields of the object struct directly you need to save the object pointer. bye michael

July 15, 2016

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)

by Aaryaman Vasishta

On Fri, Jul 15, 2016 at 4:02 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > struct d3drm_viewport > { > struct d3drm_object obj; > + IDirect3DRMFrame *camera; > IDirect3DRMViewport IDirect3DRMViewport_iface; > IDirect3DRMViewport2 IDirect3DRMViewport2_iface; > + IDirect3DViewport *d3d_viewport; > + IDirect3DMaterial *material; > IDirect3DRM *d3drm; > D3DVALUE back; > D3DVALUE front; > I've decided to keep the interface instead of using the struct directly, since it'll be easier to use the interface functions for transformations and other paramaters. Referencing the interface via the object for every function call seems a bit redundant. Also I think refcounts should be handled seamlessly this way. A reference to the background material created internally is also kept here. As Stefan had pointed out, the material is not AddRef'd since its handle is used instead, so it's probably safer to keep the reference to ourselves and release it when the object is destroyed. Cheers, Aaryaman

July 15, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-11 um 08:46 schrieb Aaryaman Vasishta: > Umm, It's still not clear whether the interface is QI'd to > IDirect3DRMObject or referenced directly. Our implementation > doesn't do the AddRef, but I don't think refcounting matters much > in this case, since the callbacks happen right before the object > gets destroyed. For the mailing list archives: We talked about this on IRC, and it turns out that native always passes the version 1 interface to the callback, regardless of which version was used to call AddDestroyCallback. (or rather, it passes the IDirect3DRMObject interface, which happens to share the vtable with the version 1 interface in all objects as far as we know. Our code already implements this behavior. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXh973AAoJEN0/YqbEcdMwoXEP/24KdStf2VVxBKk62V26TVnw z8lzY1T6gLR/6ryzOuYAOKjeXRv+ZZgdPyiGhU1jgzXISKy1yAsZIckW5vi+r+2d niTt++P+/ldoEAxix2Eh4xf0boNjr3VtKVIU14DXpkpOb+VHE6Ldm25Bv0yrhCUm Ktziod3pqJxVRjDIzFgskyxUyzuVDy7bRKO5JDqOseLh84yVfKFD1Xw1sNW5po/S 30uyUaj6xC04etUd/VAnE9PRiWYWBcGi3hZkVRzJZ8y0dAZQu68ymACP6/5tcT95 FNPhBcOEKB0zDS1kIi5Hv4AaVX9nLSlWlfSZxJJykN8pX564Z62ZZIU3lCq/gJYl sdp/dC5lmbJxlkk5TtPxS1KsLUk5akm4Ra/t0JbfHBnfqeys0tt8BiJWpcD+Xw1Z oJ/eqwIbuQw2RsszfcmqWlLJ9LsY8smh5j4PwqS6d0z+SkjQSOyKWlgKyLtb95X+ 02HlKWiWn9eGKBVHcox91l0aRvYY6Ho0n4It6tzlG/1HzH0uyyKM/vdWXmkFwCWe WV0R9jjJB1lKkniVi5FMLQjMGAoDtteNHTMUk+rDFA5tRxqCZiOPvgDarLe70ZaJ KkfgR9OGlZmjeXdmvAyyn3ckwSWLj2JhGu9bmwuOsRzNs+Ljhfickd7izDubPlqw 4VqTcZqSHLRgTjEF18Bt =gTtW -----END PGP SIGNATURE-----

July 14, 2016

Re: [PATCH 05/12] d3drm: Implement IDirect3DRMDevice*::InitFromD3D.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-14 um 00:33 schrieb Aaryaman Vasishta: > It still returns E_NOINTERFACE. This means that CreateObject does > keep track of which interface was requested within the object after > all. We could probably mimic this by using a version field within > the struct, which can be looked up and InitFromD3D would be handled > accordingly, similar to the version field in struct d3d_device. > This could potentially be used in other functions with similar > behavior on different versions as well. Don't worry too much about the InitFromD3D? corner case. Keep it in mind for debugging, but I doubt there's an application that tries to do this and depends on this thing to fail. But yeah, you may need some sort of version tagging for future things at some point. Ddraw has something similar. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXh96HAAoJEN0/YqbEcdMwAicP/0sYEw43mK4ghm5H7uea/QHw 9Uv1PY2WGRPWoPPe4YXFK12ZD2E3gzSuTLPGhJruezqhOWB8Bxp0WPFX5q8IYTaf X30PjDOeRBvPh5ptHdRddXPDxGo89GhAFd+dz2lt3t5z5FdVWKyY7opjQhWS6nJF nNMbRC1di9zCuCyo/UGG/ILXxMPD9VAnH7Fahy4xWcRZFLAxJH8thPaiGbin7Nwi InWVqiUjG44BYff8roYXylu+rUIVBYdp8FHw5gowdNWAyDkMbGhHUtctlTqgPCM6 Irc+UOqmsxel2ccGlKHk1zDFjGbsNYkrLORCLeAtjaAhL+IaLgbrq+eu84DX7OQA XTO/PS0RVUwL6o+rsB6AG6Wsqq+dAHEDq0adSru4IqDrWlWBEAy6F9mYt1Qms8np Qa9J+1jo6fc7Eq35vcs0uW/Ymd+EH7qs4KHljJRsxMM/OzTOOmYIrJeBOmEo+oNq eGOGxNDa++gihpcNV7JzsfGj9Ar+vmfwyIRg8REGTisHzylIhlw22nRhmzr5k2rK mqI2M6KXlpG1lAQOSqpPKhdLLdPUwcWiRu7d+RDNadV3ypBlGgqjS6YY1mCUdynR yjK9Fabvo3RQV7bRC42rygIdYDvO8Bpj4cctejfD0Y0iuCw5VlJFbRXerjKNS3c6 Skm0afo5Ovb6y0rWLH+M =tnTR -----END PGP SIGNATURE-----

July 14, 2016

Re: Testbot 3D tests broken

by Matteo Bruni

2016-07-14 8:50 GMT+02:00 Patrick Rudolph <siro(a)das-labor.org>: > On 2016-07-13 09:53 PM, Matteo Bruni wrote: >> 2016-07-12 17:51 GMT+02:00 Patrick Rudolph <siro(a)das-labor.org>: >>> Hi, >>> can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. >>> Other 3D tests might be affected, too. >>> As you can see here it reports no test failures, but it skipped all >>> tests: >>> https://testbot.winehq.org/JobDetails.pl?Key=24151 >>> https://testbot.winehq.org/JobDetails.pl?Key=24150 >> >> Not sure if you already got an answer on IRC or elsewhere. Anyway, the >> tests are actually executed on OS versions with the WARP device >> available, i.e. Win8 and newer. WARP device doesn't entirely match >> "usual" hardware devices WRT test results and since we really only >> care to match hardware behavior (but we still want the tests to pass >> on the testbot) there are a number of hacks in the tests. >> > Should I don't care about pre Win8 test results ? Certainly you should care, but you need to test yourself on real hardware, or ask someone to run the test for you. > Both, d3d8 and d3d9 games, are likely to be used with WinXp or Win7. > Does it make sense to test them on Win8 or newer ? > As likely every wine user is running wined3d on real hardware, shouldn't > there be test systems that have real GPUs ? Yep, but we can't have that right now with the testbot. I can't find a specific bug number but I'm pretty sure Francois knows about it either way.

July 14, 2016

Re: Testbot 3D tests broken

by Patrick Rudolph

On 2016-07-13 09:53 PM, Matteo Bruni wrote: > 2016-07-12 17:51 GMT+02:00 Patrick Rudolph <siro(a)das-labor.org>: >> Hi, >> can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. >> Other 3D tests might be affected, too. >> As you can see here it reports no test failures, but it skipped all >> tests: >> https://testbot.winehq.org/JobDetails.pl?Key=24151 >> https://testbot.winehq.org/JobDetails.pl?Key=24150 > > Not sure if you already got an answer on IRC or elsewhere. Anyway, the > tests are actually executed on OS versions with the WARP device > available, i.e. Win8 and newer. WARP device doesn't entirely match > "usual" hardware devices WRT test results and since we really only > care to match hardware behavior (but we still want the tests to pass > on the testbot) there are a number of hacks in the tests. > Should I don't care about pre Win8 test results ? Both, d3d8 and d3d9 games, are likely to be used with WinXp or Win7. Does it make sense to test them on Win8 or newer ? As likely every wine user is running wined3d on real hardware, shouldn't there be test systems that have real GPUs ? >> Regards, >> Patrick

July 14, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Ken Thomases

On Jul 13, 2016, at 8:36 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 14.07.2016 00:46, Ken Thomases wrote: >>> >>> Please correct me if I'm wrong, but to my knowledge, the "ugly" shift >>> string method which depends on the exact memory layout only makes sense >>> on Linux. On all other operating systems the cmdline is obtained in a >>> different way and it does not matter what is stored in the process. >> >> That's what I thought at first, too, but no. Shifting the strings is what affects the output of ps on macOS, too. The call to setprogname() affects some other process metadata query APIs (e.g. libproc), but I'm not aware of built-in commands which demonstrate their output. >> >> The setproctitle() docs I've found online suggest that modifying argv (at least, argv[0]) works on FreeBSD, too. It's just that setproctitle() is preferred. >> <https://www.freebsd.org/cgi/man.cgi?query=setproctitle&sektion=3> >> >> -Ken >> > > Okay, if its unclear what else we might break then its probably better to keep > it in the version you already have. Thanks for the explanation. ;) You're welcome. Thank you for reviewing. :) -Ken

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Sebastian Lackner

On 14.07.2016 00:46, Ken Thomases wrote: >> >> Please correct me if I'm wrong, but to my knowledge, the "ugly" shift >> string method which depends on the exact memory layout only makes sense >> on Linux. On all other operating systems the cmdline is obtained in a >> different way and it does not matter what is stored in the process. > > That's what I thought at first, too, but no. Shifting the strings is what affects the output of ps on macOS, too. The call to setprogname() affects some other process metadata query APIs (e.g. libproc), but I'm not aware of built-in commands which demonstrate their output. > > The setproctitle() docs I've found online suggest that modifying argv (at least, argv[0]) works on FreeBSD, too. It's just that setproctitle() is preferred. > <https://www.freebsd.org/cgi/man.cgi?query=setproctitle&sektion=3> > > -Ken > Okay, if its unclear what else we might break then its probably better to keep it in the version you already have. Thanks for the explanation. ;) Regards, Sebastian

July 13, 2016

Re: [2/2] kernel32/tests: Add tests for GetThreadSelectorEntry.

by Sebastian Lackner

On 14.07.2016 00:26, Marvin wrote: > 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=24204 > > Your paranoid android. > > > === w1064 (32 bit thread) === > thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE) > This is an existing failure.

July 13, 2016

Re: [PATCH 05/12] d3drm: Implement IDirect3DRMDevice*::InitFromD3D.

by Aaryaman Vasishta

On Sun, Jul 10, 2016 at 9:10 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > > + hr = IDirect3DRMDevice2_InitFromD3D(device2, d3d1, d3ddevice1); > > + ok(hr == E_NOINTERFACE, "Expected hr == E_NOINTERFACE, got > %#x.\n", hr); > What happens if you QI IDirect3DRMDevice1 from IDirect3DRMDevice2 and call > InitFromD3D on it? I would expect it to succeed because common decency > suggests that CreateObject doesn't leave a history of which interface was > requested and there's no CLSID_CDirect3DRMDevice2 or > CLSID_CDirect3DRMDevice3. Still worth a check though I think. > It still returns E_NOINTERFACE. This means that CreateObject does keep track of which interface was requested within the object after all. We could probably mimic this by using a version field within the struct, which can be looked up and InitFromD3D would be handled accordingly, similar to the version field in struct d3d_device. This could potentially be used in other functions with similar behavior on different versions as well. Cheers, Aaryaman

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Ken Thomases

On Jul 13, 2016, at 3:13 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 13.07.2016 21:52, Ken Thomases wrote: >> On Jul 13, 2016, at 2:25 PM, Sebastian Lackner >> <sebastian(a)fds-team.de> wrote: >>> >>> On 13.07.2016 20:20, Ken Thomases wrote: >>> >>>> Moving the code to the bottom could be done, although it would >>>> mean two #ifdef HAVE_SETPROCTITLE blocks, one to set >>>> shift_strings and the other to actually make the call. The >>>> reason is that the shifting has to happen before the call to >>>> setprogname() because it's documented to keep the pointer that's >>>> passed in. We can't pass it (a substring of) argv[1] and then >>>> shift the strings. >>> >>> I'm not sure if two #ifdefs is actually that bad, it probably >>> should depend on the operating system anyway. >> >> By "it" you mean the decision to shift the strings? Why should that >> depend on the OS? What reliable way do we have to detect if the OS >> works that way other than the strings actually being contiguous? > > Please correct me if I'm wrong, but to my knowledge, the "ugly" shift > string method which depends on the exact memory layout only makes sense > on Linux. On all other operating systems the cmdline is obtained in a > different way and it does not matter what is stored in the process. That's what I thought at first, too, but no. Shifting the strings is what affects the output of ps on macOS, too. The call to setprogname() affects some other process metadata query APIs (e.g. libproc), but I'm not aware of built-in commands which demonstrate their output. The setproctitle() docs I've found online suggest that modifying argv (at least, argv[0]) works on FreeBSD, too. It's just that setproctitle() is preferred. <https://www.freebsd.org/cgi/man.cgi?query=setproctitle&sektion=3> -Ken

July 13, 2016

Re: [2/2] kernel32/tests: Add tests for GetThreadSelectorEntry.

by Marvin

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=24204 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Sebastian Lackner

On 13.07.2016 21:52, Ken Thomases wrote: > On Jul 13, 2016, at 2:25 PM, Sebastian Lackner > <sebastian(a)fds-team.de> wrote: >> >> On 13.07.2016 20:20, Ken Thomases wrote: >> >>> Moving the code to the bottom could be done, although it would >>> mean two #ifdef HAVE_SETPROCTITLE blocks, one to set >>> shift_strings and the other to actually make the call. The >>> reason is that the shifting has to happen before the call to >>> setprogname() because it's documented to keep the pointer that's >>> passed in. We can't pass it (a substring of) argv[1] and then >>> shift the strings. >> >> I'm not sure if two #ifdefs is actually that bad, it probably >> should depend on the operating system anyway. > > By "it" you mean the decision to shift the strings? Why should that > depend on the OS? What reliable way do we have to detect if the OS > works that way other than the strings actually being contiguous? Please correct me if I'm wrong, but to my knowledge, the "ugly" shift string method which depends on the exact memory layout only makes sense on Linux. On all other operating systems the cmdline is obtained in a different way and it does not matter what is stored in the process. > >> On systems where it doesn't make a difference (like FreeBSD, ...) >> this step can always be safely skipped. > > By "systems where it doesn't make a difference", you mean those that > have setproctitle()? By "this step" you mean shifting the strings? > That's what my patch already does. > What I mean is that checking the operating system might be better than checking if specific functions are available. To explain it with some pseudo code, I was thinking about something like this: --- snip --- #ifdef __linux__ // shift_strings check if (shift_strings) { // ... } else #endif { // fallback method } #ifdef HAVE_SETPROCTITLE // ... #endif #ifdef HAVE_SETPROGNAME // ... #endif #ifdef HAVE_PRCTL // ... #endif --- snip --- Regards, Sebastian

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Ken Thomases

On Jul 13, 2016, at 2:37 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 13.07.2016 21:25, Sebastian Lackner wrote: >> On 13.07.2016 20:20, Ken Thomases wrote: >>>>> However, setproctitle() is specifically documented as a preferred >>>>> alternative to the technique of overwriting the arg strings, so >>>>> don't shift the strings if that's available. >>>> >>>> Wouldn't it make sense to remove the directory component also in >>>> this case, to be consistent? By moving the code to the bottom all >>>> functions would be called in the same way. >>> >>> Well, the only reason we remove the directory component for the other >>> calls is because they only allow limited storage. I'm not aware of a >>> similar limit for setproctitle(). >>> >>> Also, setproctitle() is theoretically more similar to the shifting of >>> the argument strings than to setprogname() or prctl(PR_SET_NAME). >>> And we don't make any attempt to remove the directory component for >>> the string shifting. (I.e. "ps" will show the full command line, >>> potentially including Windows-style .exe path.) >> >> Well, its still very different compared to shifting because all the >> following arguments are stripped away. I did some quick tests and it >> seems like there are also methods which do preserve the additional >> arguments in the "ps" output: >> >> * Either a direct sysctl invocation as done in the setproctitle() >> implementation itself. >> >> * Or, first shift the arguments (both methods work), and then call: >> setproctitle("some string"); >> setproctitle(NULL); >> The second call restores the process title as seen by the app. > > Actually it looks like we can get the same result just by concatenating > all arguments on the Wine side. The separation of the arguments is lost > in the "ps" output anyway. Depending on how you want to proceed I'll > probably send a patch after you are done with the cleanup. ;) I'm happy to have my current patch committed and you can submit a patch to pass the concatenation of the args to setproctitle() if you like. :) -Ken

July 13, 2016

Re: Testbot 3D tests broken

by Matteo Bruni

2016-07-12 17:51 GMT+02:00 Patrick Rudolph <siro(a)das-labor.org>: > Hi, > can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. > Other 3D tests might be affected, too. > As you can see here it reports no test failures, but it skipped all > tests: > https://testbot.winehq.org/JobDetails.pl?Key=24151 > https://testbot.winehq.org/JobDetails.pl?Key=24150 Not sure if you already got an answer on IRC or elsewhere. Anyway, the tests are actually executed on OS versions with the WARP device available, i.e. Win8 and newer. WARP device doesn't entirely match "usual" hardware devices WRT test results and since we really only care to match hardware behavior (but we still want the tests to pass on the testbot) there are a number of hacks in the tests. > Regards, > Patrick

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Ken Thomases

On Jul 13, 2016, at 2:25 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 13.07.2016 20:20, Ken Thomases wrote: > >> Moving the code to the bottom could be done, although it would mean >> two #ifdef HAVE_SETPROCTITLE blocks, one to set shift_strings and the >> other to actually make the call. The reason is that the shifting has >> to happen before the call to setprogname() because it's documented to >> keep the pointer that's passed in. We can't pass it (a substring of) >> argv[1] and then shift the strings. > > I'm not sure if two #ifdefs is actually that bad, it probably should > depend on the operating system anyway. By "it" you mean the decision to shift the strings? Why should that depend on the OS? What reliable way do we have to detect if the OS works that way other than the strings actually being contiguous? > On systems where it doesn't make > a difference (like FreeBSD, ...) this step can always be safely skipped. By "systems where it doesn't make a difference", you mean those that have setproctitle()? By "this step" you mean shifting the strings? That's what my patch already does. In other words, I don't understand what you're getting at with this paragraph. -Ken

July 13, 2016

Re: [PATCH v2 2/3] winex11.drv: avoid passing NULL to memcpy (clang)

by Matteo Bruni

2016-07-09 8:42 GMT+02:00 Alexandre Julliard <julliard(a)winehq.org>: > Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > >> According to the standard, memcpy() and its friends >> should never accept NULL as argument, otherwise >> the behavior is undefined and optimizer takes this >> into account. >> >> Below in the same file (line 206) caller passes >> NULL as lpComp argument triggering this case. >> >> This patch is of the same nature as the following: >> >> commit 5a3ad0ecf08c00fc0b7b2f24e55be27b7c3f5da0 >> Author: Kirill Smirnov <kirill.k.smirnov(a)gmail.com> >> Date: Mon May 9 18:56:14 2016 +0300 >> >> winhlp32: Do not pass NULL to strchr() (spotted by clang). > > strchr has to access the pointer so obviously it can't take NULL, but > memcpy with a zero length shouldn't, so it's not very useful compiler > behavior IMO. Sadly it seems the standard does allow it... Yeah and gcc has also been exploiting that for more aggressive optimizations for a while (see https://gcc.gnu.org/gcc-4.9/porting_to.html) deb274226783ab886bdb44876944e156757efe2b was probably the one significant precedent for Wine.

July 13, 2016

Re: [PATCH 1/2] include: Fix include arguments.

by Matteo Bruni

This probably makes sense (although, WRT the patch title, this is probably more of a consistency improvement rather than a "fix"). Maybe split the d3dtypes.h change to a separate patch?

July 13, 2016

Re: include: Add d3dx10math.inl.

by Matteo Bruni

2016-07-04 19:26 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: +#ifndef __D3DX10MATH_INL__ +#define __D3DX10MATH_INL__ My copy of the file (from the latest DX SDK) uses __D3DXMATH_INL__ as header guard. I think we should do the same for compatibility. +/* constructors & operators */ Nitpicking but this comment doesn't seem particularly useful. +inline D3DXVECTOR2::D3DXVECTOR2(const FLOAT *pf) Just use plain float. + if(!pf) return; Space before '(', return on a separate line. +inline D3DXVECTOR2::operator FLOAT* () +{ + return (FLOAT*)&x; Please put a space between "float" and '*' in the cast. Probably do the same in the operator definition, although I don't really care in that regard. +inline D3DXMATRIX D3DXMATRIX::operator - () const +{ + return D3DXMATRIX(-_11, -_12, -_13, -_14, + -_21, -_22, -_23, -_24, + -_31, -_32, -_33, -_34, + -_41, -_42, -_43, -_44); +} This is almost identical to the MS's header. Please use 8 space indentation for line continuations. Probably drop the space between the "operator" keyword and the operator and between the operator and the opening parenthesis, in the operator declaration. +inline D3DXCOLOR::operator UINT () const +{ + UINT _r = r >= 1.0f ? 0xff : r <= 0.0f ? 0x00 : (UINT)(r * 255.0f + 0.5f); + UINT _g = g >= 1.0f ? 0xff : g <= 0.0f ? 0x00 : (UINT)(g * 255.0f + 0.5f); + UINT _b = b >= 1.0f ? 0xff : b <= 0.0f ? 0x00 : (UINT)(b * 255.0f + 0.5f); + UINT _a = a >= 1.0f ? 0xff : a <= 0.0f ? 0x00 : (UINT)(a * 255.0f + 0.5f); + + return (_a << 24) | (_r << 16) | (_g << 8) | (_b << 0); +} This one is also virtually identical. There seems to be room for writing a slightly different but equivalent implementation. FWIW identifiers starting with an underscore are supposed to be reserved, to some degree. It's generally better to avoid them. +inline D3DXFLOAT16::D3DXFLOAT16() +{ +} These default constructors are in (native) d3dx10math.h. I know that with d3dx9* headers we did put those in the .inl file but I think that was a bad idea. +inline BOOL D3DXFLOAT16::operator == (const D3DXFLOAT16 &f) const +{ This one is also almost identical, implementation-wise. Now maybe there isn't that much room for variations here but still, at the very least replace the "== 0" with a '!'. If you can find other reasonable ways to differentiate, that's even better. +inline D3DXCOLOR::D3DXCOLOR(UINT col) +{ + const FLOAT f = 1.0f / 255.0f; + r = f * (FLOAT)(unsigned char)(col >> 16); + g = f * (FLOAT)(unsigned char)(col >> 8); + b = f * (FLOAT)(unsigned char)(col >> 0); + a = f * (FLOAT)(unsigned char)(col >> 24); +} Another one essentially identical. I would write it as something like: inline D3DXCOLOR::D3DXCOLOR(UINT col) { float inv = 1.0f / 255.0f; a = ((col >> 24) & 0xff) * inv; r = ((col >> 16) & 0xff) * inv; g = ((col >> 8) & 0xff) * inv; b = (col & 0xff) * inv; } +static inline D3DXCOLOR* D3DXColorLerp(D3DXCOLOR *pout, const D3DXCOLOR *pc1, const D3DXCOLOR *pc2, FLOAT s) Don't use those prefixed argument names: out, c1 and c2 work just fine. Also you want a space between D3DXCOLOR and '*' and no space between '*' and the function name. +{ + if ( !pout || !pc1 || !pc2 ) return NULL; Please no spaces after the '(' and before the ')'. Return on a separate line. + pout->r = (1-s) * (pc1->r) + s *(pc2->r); You want spaces around the '-' operator and a space after the multiplication operator. No need for the parentheses around pc1->r and pc2->r. Regardless, MS's header uses the "optimized" linear interpolation formula, with just one multiplication. Your current implementation will generally give slightly different results (because of the limited precision of floats) so you should stick to the same formula instead. This isn't an exhaustive list of issues. Many of the above comments apply to multiple places over the patch.

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Sebastian Lackner

On 13.07.2016 21:25, Sebastian Lackner wrote: > On 13.07.2016 20:20, Ken Thomases wrote: >>>> However, setproctitle() is specifically documented as a preferred >>>> alternative to the technique of overwriting the arg strings, so >>>> don't shift the strings if that's available. >>> >>> Wouldn't it make sense to remove the directory component also in >>> this case, to be consistent? By moving the code to the bottom all >>> functions would be called in the same way. >> >> Well, the only reason we remove the directory component for the other >> calls is because they only allow limited storage. I'm not aware of a >> similar limit for setproctitle(). >> >> Also, setproctitle() is theoretically more similar to the shifting of >> the argument strings than to setprogname() or prctl(PR_SET_NAME). >> And we don't make any attempt to remove the directory component for >> the string shifting. (I.e. "ps" will show the full command line, >> potentially including Windows-style .exe path.) > > Well, its still very different compared to shifting because all the > following arguments are stripped away. I did some quick tests and it > seems like there are also methods which do preserve the additional > arguments in the "ps" output: > > * Either a direct sysctl invocation as done in the setproctitle() > implementation itself. > > * Or, first shift the arguments (both methods work), and then call: > setproctitle("some string"); > setproctitle(NULL); > The second call restores the process title as seen by the app. Actually it looks like we can get the same result just by concatenating all arguments on the Wine side. The separation of the arguments is lost in the "ps" output anyway. Depending on how you want to proceed I'll probably send a patch after you are done with the cleanup. ;)

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Sebastian Lackner

On 13.07.2016 20:20, Ken Thomases wrote: >>> However, setproctitle() is specifically documented as a preferred >>> alternative to the technique of overwriting the arg strings, so >>> don't shift the strings if that's available. >> >> Wouldn't it make sense to remove the directory component also in >> this case, to be consistent? By moving the code to the bottom all >> functions would be called in the same way. > > Well, the only reason we remove the directory component for the other > calls is because they only allow limited storage. I'm not aware of a > similar limit for setproctitle(). > > Also, setproctitle() is theoretically more similar to the shifting of > the argument strings than to setprogname() or prctl(PR_SET_NAME). > And we don't make any attempt to remove the directory component for > the string shifting. (I.e. "ps" will show the full command line, > potentially including Windows-style .exe path.) Well, its still very different compared to shifting because all the following arguments are stripped away. I did some quick tests and it seems like there are also methods which do preserve the additional arguments in the "ps" output: * Either a direct sysctl invocation as done in the setproctitle() implementation itself. * Or, first shift the arguments (both methods work), and then call: setproctitle("some string"); setproctitle(NULL); The second call restores the process title as seen by the app. > > Moving the code to the bottom could be done, although it would mean > two #ifdef HAVE_SETPROCTITLE blocks, one to set shift_strings and the > other to actually make the call. The reason is that the shifting has > to happen before the call to setprogname() because it's documented to > keep the pointer that's passed in. We can't pass it (a substring of) > argv[1] and then shift the strings. I'm not sure if two #ifdefs is actually that bad, it probably should depend on the operating system anyway. On systems where it doesn't make a difference (like FreeBSD, ...) this step can always be safely skipped. > > -Ken >

July 13, 2016

Re: [PATCH 4/5] d3d11/tests: Add test for writing special floating-point values to render target.

by Henri Verbeet

On 13 July 2016 at 10:52, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +#ifndef NAN > +static inline float __port_nan(void) > +{ > + static const unsigned __nan_bytes = 0x7fc00000; > + return *(const float *)&__nan_bytes; > +} > +#define NAN __port_nan() > +#endif This looks unused. > + const struct vec4 *value = get_readback_vec4(&rb, x, y); > + ok(isnan(value->x) && value->y == INFINITY && value->z == -INFINITY && value->w == 1.0f, > + "Got unexpected value {%.8e, %.8e, %.8e, %.8e} at (%u, %u).\n", > + value->x, value->y, value->z, value->w, x, y); It would slightly change the meaning of the test, but you could also just read these back as uvec4's and compare the bit patterns. > @@ -9312,4 +9400,5 @@ START_TEST(d3d11) > test_check_feature_support(); > test_create_unordered_access_view(); > test_immediate_constant_buffer(); > + test_special_float_values(); For what it's worth, those are usually called "floating-point specials". (And hence fp_special_test() in the d3d9 tests.)

July 13, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Ken Thomases

On Jul 12, 2016, at 2:45 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 12.07.2016 06:44, Ken Thomases wrote: >> This fixes several problems with the code: >> >> * The code had been assuming that the argument strings pointed to by the argv >> array are contiguous iff certain process-name-setting functions are available. >> This doesn't seem reliable. Instead, test if it's true and shift the strings >> if so. > > Thanks for working on this, looks indeed like a nice improvement. You're welcome and thanks. :) >> However, setproctitle() is specifically documented as a preferred alternative >> to the technique of overwriting the arg strings, so don't shift the strings >> if that's available. > > Wouldn't it make sense to remove the directory component also in this case, to > be consistent? By moving the code to the bottom all functions would be called > in the same way. Well, the only reason we remove the directory component for the other calls is because they only allow limited storage. I'm not aware of a similar limit for setproctitle(). Also, setproctitle() is theoretically more similar to the shifting of the argument strings than to setprogname() or prctl(PR_SET_NAME). And we don't make any attempt to remove the directory component for the string shifting. (I.e. "ps" will show the full command line, potentially including Windows-style .exe path.) Moving the code to the bottom could be done, although it would mean two #ifdef HAVE_SETPROCTITLE blocks, one to set shift_strings and the other to actually make the call. The reason is that the shifting has to happen before the call to setprogname() because it's documented to keep the pointer that's passed in. We can't pass it (a substring of) argv[1] and then shift the strings. -Ken

July 13, 2016

Re: ntdll/tests: Use inline implementation of NtCurrentTeb for exception tests.

by Huw Davies

On Wed, Jul 13, 2016 at 11:30:07AM +0200, Sebastian Lackner wrote: > On 13.07.2016 09:50, Marvin wrote: > > === wvistau64 (32 bit exception) === > > exception.c:489: Test failed: 42: Unexpected eip 0x3d0000/0x3d0001 > > exception: unhandled exception 80000004 at 003D0000 > > exception.c:489: Test failed: 42: Unexpected eip 0x77baed97/0x3d0001 > > > > === w7u (32 bit exception) === > > exception.c:489: Test failed: 42: Unexpected eip 0x280000/0x280001 > > exception: unhandled exception 80000004 at 00280000 > > exception.c:489: Test failed: 42: Unexpected eip 0x77cde34f/0x280001 > > These failures were already existing before and are unrelated to this patch. Indeed. <cough> vm1 kernel upgrade <cough> ;-) Huw.

July 13, 2016

Re: ntdll/tests: Use inline implementation of NtCurrentTeb for exception tests.

by Sebastian Lackner

On 13.07.2016 09:50, Marvin wrote: > 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=24168 > > Your paranoid android. > > > === wvistau64 (32 bit exception) === > exception.c:489: Test failed: 42: Unexpected eip 0x3d0000/0x3d0001 > exception: unhandled exception 80000004 at 003D0000 > exception.c:489: Test failed: 42: Unexpected eip 0x77baed97/0x3d0001 > > === w7u (32 bit exception) === > exception.c:489: Test failed: 42: Unexpected eip 0x280000/0x280001 > exception: unhandled exception 80000004 at 00280000 > exception.c:489: Test failed: 42: Unexpected eip 0x77cde34f/0x280001 > > === 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) > > === 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) > These failures were already existing before and are unrelated to this patch.

July 13, 2016

Re: ntdll/tests: Use inline implementation of NtCurrentTeb for exception tests.

by Marvin

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=24168 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:489: Test failed: 42: Unexpected eip 0x3d0000/0x3d0001 exception: unhandled exception 80000004 at 003D0000 exception.c:489: Test failed: 42: Unexpected eip 0x77baed97/0x3d0001 === w7u (32 bit exception) === exception.c:489: Test failed: 42: Unexpected eip 0x280000/0x280001 exception: unhandled exception 80000004 at 00280000 exception.c:489: Test failed: 42: Unexpected eip 0x77cde34f/0x280001 === 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) === 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)

July 13, 2016

Re: [PATCH] wined3d: Fix the size parameter of glVertexAttrib*Pointer().

by Józef Kucia

On Wed, Jul 13, 2016 at 9:01 AM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Yes, you're right, don't worry, only stupid local changes with unexpected > side-effects. > But anyway, shouldn't it be more explicit to use component_count in this > case ? I guess that "gl_vtx_format" might be a little misleading name.

July 13, 2016

Re: [PATCH] wined3d: Fix the size parameter of glVertexAttrib*Pointer().

by Guillaume Charifi

Yes, you're right, don't worry, only stupid local changes with unexpected side-effects. But anyway, shouldn't it be more explicit to use component_count in this case ? Le 13/07/2016 08:28, Józef Kucia a écrit : > On Wed, Jul 13, 2016 at 2:48 AM, Guillaume Charifi > <guillaume.charifi(a)sfr.fr> wrote: >> The mistake is obvious when looking at the GL 3.0 spec: >> p29: >> void VertexAttribPointer(uint index, int size, enum type, boolean normalized, sizei stride, const void *pointer); >> void VertexAttribIPointer(uint index, int size, enum type, sizei stride, const void *pointer); >> >> p30: >> Command Sizes >> VertexAttribPointer 1, 2, 3, 4 >> VertexAttribIPointer 1, 2, 3, 4 >> >> Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> >> --- >> dlls/wined3d/state.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > This looks wrong to me. The "gl_vtx_format" field is equal to the > "component_count" field. There's one exception though, the > "gl_vtx_format" is set to GL_BGRA for WINED3DFMT_B8G8R8A8_UNORM. > GL_BGRA was added as an accepted value by GL_ARB_vertex_array_bgra > (core since OpenGL 3.2). > > What are you trying to fix?

July 13, 2016

Re: [PATCH] wined3d: Fix the size parameter of glVertexAttrib*Pointer().

by Józef Kucia

On Wed, Jul 13, 2016 at 2:48 AM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > The mistake is obvious when looking at the GL 3.0 spec: > p29: > void VertexAttribPointer(uint index, int size, enum type, boolean normalized, sizei stride, const void *pointer); > void VertexAttribIPointer(uint index, int size, enum type, sizei stride, const void *pointer); > > p30: > Command Sizes > VertexAttribPointer 1, 2, 3, 4 > VertexAttribIPointer 1, 2, 3, 4 > > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/state.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This looks wrong to me. The "gl_vtx_format" field is equal to the "component_count" field. There's one exception though, the "gl_vtx_format" is set to GL_BGRA for WINED3DFMT_B8G8R8A8_UNORM. GL_BGRA was added as an accepted value by GL_ARB_vertex_array_bgra (core since OpenGL 3.2). What are you trying to fix?

July 13, 2016

Re: ncrypt: add some ncrypt stubs

by Sebastian Lackner

On 12.07.2016 17:47, Alex Henrie wrote: > + return NTE_INVALID_PARAMETER; > > I think NTE_NOT_SUPPORTED makes more sense for stub functions in this > DLL. Other than that, the patch looks good. > > -Alex > > I also agree that a different error code might be better, however even more important it does not compile here because there are semicolons missing in the header file. It probably would also make sense to send the header file changes in separate patches.

July 12, 2016

Re: kernel32: Overhaul the handling of argv in set_process_name().

by Sebastian Lackner

On 12.07.2016 06:44, Ken Thomases wrote: > This fixes several problems with the code: > > * The code had been assuming that the argument strings pointed to by the argv > array are contiguous iff certain process-name-setting functions are available. > This doesn't seem reliable. Instead, test if it's true and shift the strings > if so. Thanks for working on this, looks indeed like a nice improvement. > > However, setproctitle() is specifically documented as a preferred alternative > to the technique of overwriting the arg strings, so don't shift the strings > if that's available. Wouldn't it make sense to remove the directory component also in this case, to be consistent? By moving the code to the bottom all functions would be called in the same way. > > * Use the last path component, recognizing backslash as a path separator, for > setprogname() in addition to prctl(). First, setprogname() is documented as > searching for the last component itself, but it doesn't understand Windows- > style paths, so we need to help it. Second, on some platforms (e.g. macOS), > setprogname(), like prctl(), has a fairly small internal length limit (e.g. > 32 characters). So, concentrate on the most meaningful part of the path. > > * Remove argv[0] from argv whether or not there are any process-name-setting > functions available. This is necessary for the proper functioning of Wine, > so it must be done on all platforms. This part of the logic was lost with > commit 5a4576ee0. > > * Call all available process-name-setting functions instead of treating them > as mutually exclusive alternatives. This is also logic that was lost with > commit 5a4576ee0. > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > --- > dlls/kernel32/process.c | 63 +++++++++++++++++++++++++++++-------------------- > 1 file changed, 37 insertions(+), 26 deletions(-) >

July 12, 2016

Re: Ubuntu considering dropping 32-bit libraries

by Josh DuBois

On 7/6/16 10:47 AM, Josh DuBois wrote: > I will probably post to the Ubuntu thread to at least mention Wine, > unless someone here is involved in that community and thinks they can > do a better job. Fwiw I did post to the Ubuntu list asking them to take Wine into consideration with respect to building 32-bit libraries. I got an encouraging response: https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039452.html They emphasized that they're not even considering changes to the availability of 32-bit libraries until 18.10, which is a couple of years out. Also it sounds like they had Wine in mind to some degree already, even though it wasn't mentioned in the thread. They did mention asking users to run Wine in a Snap container, and also floated a vague idea that some kind of changes to Wine might make the issue easier for them. I don't know how either of those things would go (in terms of changes to Wine, there was no specific proposal, so neither do they). But, at least for now, things seem positive in that they're not taking any immediate steps which would break things and they haven't forgotten about us :-)

July 12, 2016

Testbot 3D tests broken

by Patrick Rudolph

Hi, can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. Other 3D tests might be affected, too. As you can see here it reports no test failures, but it skipped all tests: https://testbot.winehq.org/JobDetails.pl?Key=24151 https://testbot.winehq.org/JobDetails.pl?Key=24150 Regards, Patrick

July 12, 2016

Re: ncrypt: add some ncrypt stubs

by Alex Henrie

+ return NTE_INVALID_PARAMETER; I think NTE_NOT_SUPPORTED makes more sense for stub functions in this DLL. Other than that, the patch looks good. -Alex

July 12, 2016

Re: [PATCH 3/3] wined3d/resource: Performance improvements, try 2

by Henri Verbeet

This could do with a more descriptive subject line. On 11 July 2016 at 18:13, Patrick Rudolph <siro(a)das-labor.org> wrote: > Tests showed that D3DLOCK_NOOVERWRITE is prefered over D3DLOCK_DISCARD > and that D3DLOCK_NOOVERWRITE doesn't depend on dynamic buffers. "preferred", but you'll probably want to say "takes precedence over" instead. > Unigine Heavon maps a lot of buffers with both flags, but run on about > 85% GPU-load, as WINE removes both hints and the game has to wait for > the buffer to be mapped. "Unigine Heaven", "Wine" > OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.1.0-devel (git-60c68c5) It doesn't make much of a difference here, but note that unless you set the "MaxVersionGL" registry key, wined3d doesn't use core profiles. > --- > dlls/d3d9/tests/visual.c | 10 +++++----- > dlls/wined3d/resource.c | 33 ++++++++++++++++----------------- > 2 files changed, 21 insertions(+), 22 deletions(-) What about the d3d8 tests? > @@ -359,29 +359,28 @@ DWORD wined3d_resource_sanitize_map_flags(const struct wined3d_resource *resourc > { > /* Not all flags make sense together, but Windows never returns an error. > * Catch the cases that could cause issues. */ > - if (flags & WINED3D_MAP_READONLY) > + if ((flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) == > + (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > { > - if (flags & WINED3D_MAP_DISCARD) > - { > - WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_DISCARD, ignoring flags.\n"); > - return 0; > - } > - if (flags & WINED3D_MAP_NOOVERWRITE) > - { > - WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_NOOVERWRITE, ignoring flags.\n"); > - return 0; > - } > + WARN("WINED3D_MAP_DISCARD and WINED3D_MAP_NOOVERWRITE used together, using WINED3D_MAP_NOOVERWRITE.\n"); > + flags &= ~WINED3D_MAP_DISCARD; > + } > + if ((flags & (WINED3D_MAP_READONLY | WINED3D_MAP_NOOVERWRITE)) == > + (WINED3D_MAP_READONLY | WINED3D_MAP_NOOVERWRITE)) > + { > + WARN("WINED3D_MAP_READONLY and WINED3D_MAP_NOOVERWRITE used together, clearing WINED3D_MAP_READONLY.\n"); > + flags &= ~WINED3D_MAP_READONLY; > } > - else if ((flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > - == (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > + > + if ((flags & (WINED3D_MAP_READONLY | WINED3D_MAP_DISCARD)) == > + (WINED3D_MAP_READONLY | WINED3D_MAP_DISCARD)) > { > - WARN("WINED3D_MAP_DISCARD and WINED3D_MAP_NOOVERWRITE used together, ignoring.\n"); > + WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_DISCARD, ignoring flags.\n"); > return 0; > } > - else if (flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE) > - && !(resource->usage & WINED3DUSAGE_DYNAMIC)) > + else if ((flags & WINED3D_MAP_DISCARD) && !(resource->usage & WINED3DUSAGE_DYNAMIC)) > { > - WARN("DISCARD or NOOVERWRITE map on non-dynamic buffer, ignoring.\n"); > + WARN("DISCARD on non dynamic buffer, ignoring.\n"); > return 0; > } This changes several things at once. One (logical) change per commit, please.

July 12, 2016

Re: [PATCH 1/3] d3d9/tests/visual: Add Vertexbuffer locking tests, try 2

by Henri Verbeet

On 11 July 2016 at 18:13, Patrick Rudolph <siro(a)das-labor.org> wrote: > +static void test_vb_lock_flags(void) > +{ > + IDirect3DVertexBuffer9 *buffer; > + IDirect3DDevice9 *device; > + IDirect3D9 *d3d9; > + DWORD i, j, tri, quads; > + HWND window; > + HRESULT hr; > + ULONG size; > + unsigned refcount; "ULONG refcount;", but that's minor. > + { > + "0", > + 0, > + 0, > + FALSE, > + FALSE > + }, This may have been inspired by other tests, but as long as it fits I'd prefer the more compact option of keeping this all on a single line. You may have to shorten the "flags_s" values a bit to do that. > + static struct > + { > + struct > + { > + struct vec3 position; > + DWORD diffuse; > + } strip[4]; > + } > + *quad_strip_array, quad_strip1 = > + { > + { > + {{-1.0f, -1.0f, 0.0f}, 0xffff0000}, > + {{-1.0f, 1.0f, 0.0f}, 0xff00ff00}, > + {{ 1.0f, -1.0f, 0.0f}, 0xff0000ff}, > + {{ 1.0f, 1.0f, 0.0f}, 0xffffffff}, > + } > + }, > + quad_strip2 = > + { > + { > + {{-1.0f, -1.0f, 0.0f}, 0xffffff00}, > + {{-1.0f, 1.0f, 0.0f}, 0xffffff00}, > + {{ 1.0f, -1.0f, 0.0f}, 0xffffff00}, > + {{ 1.0f, 1.0f, 0.0f}, 0xffffff00}, > + } > + }; These are triangle strips or quads, but I don't think "quad strips" makes sense here. "quad_strip1" and "quad_strip2" can be const, and "quad_strip_array" doesn't need to be static, right? > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, tests[i].usage, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + ok(SUCCEEDED(hr), "Failed to create vertex buffer, hr %#x.\n", hr); > + if (!SUCCEEDED(hr)) > + continue; The continue is pointless, the test would have already failed at that point. > + if (tests[i].unsyncronized == unsyncronized) > + break; This means the test will only try the smallest buffer size for cases that you expect to be synchronised, right? That seems problematic, since the reason you try the larger buffer sizes is that you can't necessarily reliably detect the unsynchronised cases with the smaller buffer sizes. > + if (tests[i].todo) > + { > + todo_wine ok(tests[i].unsyncronized == unsyncronized, "Expected buffer mapped %s. Flags = %s. Usage = %d.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } > + else > + { > + ok(tests[i].unsyncronized == unsyncronized, "Expected buffer mapped %s. Flags = %s. Usage = %d.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } I think "todo_wine_if" would be appropriate here. Please use %#x to print the usage. Note that ddraw has the mostly equivalent flags DDLOCK_NOOVERWRITE and DDLOCK_DISCARDCONTENTS as well. Direct3D 10 has D3D10_MAP_WRITE_DISCARD and D3D10_MAP_WRITE_NO_OVERWRITE, but you can't use them at the same time because they're not flags. Direct3D 11 is similar to Direct3D 10. You'll need to account for the testbot failures in some way. They may be specific to WARP, but it's suspicious that the "D3DLOCK_NOOVERWRITE" tests do seem to pass. Also, please follow the usual conventions for the subject line. (I.e., "d3d9/tests:", "d3d8/tests:", "wined3d:".)

July 12, 2016

Re: [PATCH] dxgi: Implement IDXGISwapChain GetFullscreenState

by Henri Verbeet

On 11 July 2016 at 12:08, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +static HRESULT STDMETHODCALLTYPE dxgi_swapchain_GetFullscreenState(IDXGISwapChain *iface, > + BOOL *fullscreen, IDXGIOutput **target) > +{ > + HRESULT hr = S_OK; > + > + TRACE("iface %p, fullscreen %p, target %p semi-stub.\n", iface, fullscreen, target); > + > + if (fullscreen) > + *fullscreen = TRUE; > + > + if (target) > + hr = dxgi_swapchain_GetContainingOutput(iface, target); > + > + return hr; > +} That's not a real implementation, of course. > @@ -496,6 +498,22 @@ static void test_create_swapchain(void) > refcount = IUnknown_Release(parent); > todo_wine ok(refcount == 4, "Got unexpected refcount %u.\n", refcount); > > + hr = IDXGISwapChain_GetFullscreenState(swapchain, NULL, NULL); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, &fullscreen, NULL); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, NULL, &target); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + if(target) > + IDXGIOutput_Release(target); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, &fullscreen, &target); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + if(target) > + IDXGIOutput_Release(target); > + And this doesn't test much beyond the function returning S_OK.

July 12, 2016

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

by Ken Thomases

On Jul 7, 2016, at 6:02 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > Also, why should set_process_name() shift the strings up within the (supposedly contiguous) string buffer? For the HAVE_SETPROCTITLE, it doesn't do that. Prior to Chip's commit, it didn't do that on macOS. So, Theodore's original question, "Why wouldn’t setprogname(argv[1]) be adequate?", is pretty close. It should have been, "Why wouldn’t setprogname(argv[1]) followed by shifting the elements of argv up one be adequate?" > > I'm not even sure why the string buffer is shifted for Linux. It looks like it's leftover logic that's no longer relevant (having to do with vdm?). OK, I have figured out what I was missing. Much to my surprise, modifying the argv strings buffer is actually the means by which the command shown by, for example, ps is modified. The prctl() call on Linux affects a different value (the "comm" field rather than "command"). I have submitted a patch to address the other shortcomings of the current code. -Ken

July 11, 2016

Re: ntoskrnl.exe: add IoAttachDevice stub

by Sebastian Lackner

On 12.07.2016 05:07, Austin English wrote: > + > +/*********************************************************************** > + * IoAttachDevice (NTOSKRNL.EXE.@) > + */ > +NTSTATUS IoAttachDevice(DEVICE_OBJECT *source, UNICODE_STRING *target, DEVICE_OBJECT *attached) You forgot to specify the calling convention (WINAPI) - this is probably also the reason why your stub is not sufficient yet. Otherwise the patch looks fine to me. > +{ > + FIXME("(%p, %s, %p): stub\n", source, debugstr_us(target), attached); > + return STATUS_NOT_IMPLEMENTED; > +}

July 11, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by Sebastian Lackner

On 11.07.2016 22:07, John Sheu wrote: > Updating the patch now. Note in particular with the SetLastError() > calls, that the error messages immediately after the API calls do > print the result of GetLastError(), so it would be good to return the > last error to a known state for that. > > Thanks! > -John Sheu > Usually SetLastError() is only used when the error code is tested explicitly, not when the error is printed in an ok() message for debugging purposes. If there are test failures, a developer will have to investigate what exactly is going wrong anyway.

July 11, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by John Sheu

Updating the patch now. Note in particular with the SetLastError() calls, that the error messages immediately after the API calls do print the result of GetLastError(), so it would be good to return the last error to a known state for that. Thanks! -John Sheu

July 11, 2016

Re: [PATCH 3/3] wined3d/resource: Performance improvements, try 2

by Marvin

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=24152 Your paranoid android. === w8 (32 bit visual) === visual.c:8177: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:8345: Test failed: Got unexpected color 0x00ff0000 for no color attribute test. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (32 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (32 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (64 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (64 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512.

July 11, 2016

Re: [PATCH 1/3] d3d9/tests/visual: Add Vertexbuffer locking tests, try 2

by Marvin

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=24150 Your paranoid android. === w8 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (64 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (64 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512.

July 11, 2016

Re: [v3 1/2] winejoystick.drv: Print location ID in debugstr_device on the Mac

by Ken Thomases

OK. To answer your earlier question, anyway: yes, you would need to resubmit the whole series, even individual patches which didn't change. For those, you should mark them "resend" instead of bumping the version number. I'm not entirely sure it was right of me to sign off on the one which was fine, since it wouldn't work without the earlier patch. I wanted to indicate that it was fine. That uncertainty is why I didn't do it for the other one. *shrug* -Ken > On Jul 11, 2016, at 3:35 AM, DavidL <david.dljunk(a)gmail.com> wrote: > > Actually it looks like I am going to make a slight change to device_location_comparator to get rid of another set of compilation warnings - I took a look at button_usage_comparator and modeled the new version after that which eliminated the warning messages. > > Cheers, > David > > On Sun, Jul 10, 2016 at 10:25 PM, DavidL <david.dljunk(a)gmail.com <mailto:david.dljunk(a)gmail.com>> wrote: > Hi Ken, > > Thanks, I'll make the changes. For the dinput & winmm patch 2/3 & 2/2, should I resubmit them as part of my version 4 of the overall patches even if they have been signed-off on? (although I think only the dinput one was signed off on) I'm not anticipating making any changes to signed-off sorting code patch based on the comments. > > Cheers, > David > > On Sun, Jul 10, 2016 at 3:36 PM, Ken Thomases <ken(a)codeweavers.com <mailto:ken(a)codeweavers.com>> wrote: > On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com <mailto:david.dljunk(a)gmail.com>> wrote: > > > > Tested on OS X 10.10.5. > > > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com <mailto:david.dljunk(a)gmail.com>> > > --- > > dlls/winejoystick.drv/joystick_osx.c | 30 ++++++++++++++++++++++++++++-- > > 1 file changed, 28 insertions(+), 2 deletions(-) > > This has similar issues as the dinput version, the main one being the pointless "result" variable in get_device_property_long(). > > -Ken > > >

July 11, 2016

Re: [v3 2/3] dinput: Sort devices by location ID on the Mac

by DavidL

This patch will be superseded in a later version. Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> On Sun, Jul 10, 2016 at 3:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > > > >

July 11, 2016

Re: [v3 3/3] dinput: Alter function name and code style

by DavidL

I am compiling with -Wdeclaration-after-statement but oddly enough the compiler did not generate that warning for dinput. However, I don't know why not, because I see what you're saying and will make the necessary change anyway. David On Sun, Jul 10, 2016 at 3:33 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > @@ -490,10 +490,10 @@ static int find_osx_devices(void) > > if (devset) > > { > > CFIndex num_devices, num_main_elements, idx; > > - CFMutableArrayRef devices = > CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); > > - CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, > devices); > > - CFRelease( devset); > > - num_devices = CFArrayGetCount(devices); > > + num_devices = CFSetGetCount(devset); > > + CFMutableArrayRef devices = > CFArrayCreateMutable(kCFAllocatorDefault, num_devices, > &kCFTypeArrayCallBacks); > > You've now interleaved statements and declarations. Wine's code standard > requires that declarations all come before statements. So, you could > change the assignment of num_devices to an initialization or split the > declaration and initialization of devices to separate declaration and > assignment. > > Wine should be using -Wdeclaration-after-statement for its compile > commands. Therefore, this change would have added a new warning. I know > that some of the Mac files have a lot of warnings, which makes it hard to > see new ones, but you should strive to avoid adding more. > > -Ken > >

July 11, 2016

Re: usp10/tests: Use SetRect() instead of open coding it.

by Michael Stefaniuc

On 07/11/2016 10:06 AM, Marvin wrote: > 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=24145 > > Your paranoid android. > > > === w1064 (32 bit usp10) === > usp10.c:1467: Test failed: 0: uJustification incorrect (0) > usp10.c:1467: Test failed: 1: uJustification incorrect (0) > usp10.c:1467: Test failed: 2: uJustification incorrect (0) > usp10.c:1467: Test failed: 3: uJustification incorrect (0) > usp10.c:1467: Test failed: 4: uJustification incorrect (0) > usp10.c:1467: Test failed: 5: uJustification incorrect (0) > usp10.c:1467: Test failed: 6: uJustification incorrect (0) > usp10.c:1467: Test failed: 7: uJustification incorrect (0) > usp10.c:1467: Test failed: 8: uJustification incorrect (0) > usp10.c:1467: Test failed: 9: uJustification incorrect (0) > usp10.c:1483: Test failed: 3: uJustification incorrect (0) > usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) > usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) > usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) > usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) > > === w1064 (64 bit usp10) === > usp10.c:1467: Test failed: 0: uJustification incorrect (0) > usp10.c:1467: Test failed: 1: uJustification incorrect (0) > usp10.c:1467: Test failed: 2: uJustification incorrect (0) > usp10.c:1467: Test failed: 3: uJustification incorrect (0) > usp10.c:1467: Test failed: 4: uJustification incorrect (0) > usp10.c:1467: Test failed: 5: uJustification incorrect (0) > usp10.c:1467: Test failed: 6: uJustification incorrect (0) > usp10.c:1467: Test failed: 7: uJustification incorrect (0) > usp10.c:1467: Test failed: 8: uJustification incorrect (0) > usp10.c:1467: Test failed: 9: uJustification incorrect (0) > usp10.c:1483: Test failed: 3: uJustification incorrect (0) > usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) > usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) > usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) > usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) This are per-existing errors. bye michael

July 11, 2016

Re: [v3 1/2] winejoystick.drv: Print location ID in debugstr_device on the Mac

by DavidL

Actually it looks like I am going to make a slight change to device_location_comparator to get rid of another set of compilation warnings - I took a look at button_usage_comparator and modeled the new version after that which eliminated the warning messages. Cheers, David On Sun, Jul 10, 2016 at 10:25 PM, DavidL <david.dljunk(a)gmail.com> wrote: > Hi Ken, > > Thanks, I'll make the changes. For the dinput & winmm patch 2/3 & 2/2, > should I resubmit them as part of my version 4 of the overall patches even > if they have been signed-off on? (although I think only the dinput one was > signed off on) I'm not anticipating making any changes to signed-off > sorting code patch based on the comments. > > Cheers, > David > > On Sun, Jul 10, 2016 at 3:36 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: >> > >> > Tested on OS X 10.10.5. >> > >> > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> >> > --- >> > dlls/winejoystick.drv/joystick_osx.c | 30 ++++++++++++++++++++++++++++-- >> > 1 file changed, 28 insertions(+), 2 deletions(-) >> >> This has similar issues as the dinput version, the main one being the >> pointless "result" variable in get_device_property_long(). >> >> -Ken >> >> >

July 11, 2016

Re: usp10/tests: Use SetRect() instead of open coding it.

by Marvin

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=24145 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

July 11, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Aaryaman Vasishta

On Mon, Jul 11, 2016 at 1:11 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > CC'ing to wine-devel again. > > On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> >> >> On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta < >> jem456.vasishta(a)gmail.com> wrote: >> >>> >>> >>> On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger < >>> stefandoesinger(a)gmail.com> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta: >>>> > Anyways, the vtable qi tests tests written so far show that >>>> > querying IDirect3DRMObject from a particular interface will return >>>> > version 1 of that interface. So technically it all comes down to >>>> > calling >>>> > >>>> IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, >>>> > ...);. In our implementation of this method (see d3drm_main.c), we >>>> > have passed version 1 of the relevant interface while calling the >>>> > destroy callbacks within d3drm_object_destroy. The tests seem to >>>> > agree with that implementation so far. >>>> >>> Also, I may have written the example incorrectly. You're right about the >> fact that calling device3->AddDestroyCallback will pass device3 into this >> function. But internally this interface will be QI'd to IDirect3DRMObject, >> and then passed as the first parameter to the destroy callback itself. >> > Umm, It's still not clear whether the interface is QI'd to IDirect3DRMObject or referenced directly. Our implementation doesn't do the AddRef, but I don't think refcounting matters much in this case, since the callbacks happen right before the object gets destroyed.

July 11, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Aaryaman Vasishta

CC'ing to wine-devel again. On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> >> >> On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger < >> stefandoesinger(a)gmail.com> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta: >>> > Anyways, the vtable qi tests tests written so far show that >>> > querying IDirect3DRMObject from a particular interface will return >>> > version 1 of that interface. So technically it all comes down to >>> > calling >>> > >>> IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, >>> > ...);. In our implementation of this method (see d3drm_main.c), we >>> > have passed version 1 of the relevant interface while calling the >>> > destroy callbacks within d3drm_object_destroy. The tests seem to >>> > agree with that implementation so far. >>> >> Also, I may have written the example incorrectly. You're right about the > fact that calling device3->AddDestroyCallback will pass device3 into this > function. But internally this interface will be QI'd to IDirect3DRMObject, > and then passed as the first parameter to the destroy callback itself. > >

July 11, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Aaryaman Vasishta

On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger <stefandoesinger(a)gmail.com > wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta: > > Anyways, the vtable qi tests tests written so far show that > > querying IDirect3DRMObject from a particular interface will return > > version 1 of that interface. So technically it all comes down to > > calling > > IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, > > ...);. In our implementation of this method (see d3drm_main.c), we > > have passed version 1 of the relevant interface while calling the > > destroy callbacks within d3drm_object_destroy. The tests seem to > > agree with that implementation so far. > Well, but you can call AddDestroyCallback on the version 3 interface too: > > IDirect3DRMDevice *dev1; > IDirect3DRMDevice3 *dev3; > > dev1 = create_device(); > dev3 = dev1->qi(IID_IDirect3DRMDevice3); > > dev1->AddDestroyCallback(...); > dev3->AddDestroyCallback(...); > > The current code will always pass dev1 to the callback. It may be > correct, it may be wrong. > > This is where the obj == ctxt->obj test comes in. obj is the interface passed to the callback, and ctxt->obj is the one we pass into the context, which is our interface QI'd to IDirect3DRMObject. Now if we consider this test + the vtable QI tests, we can (in)directly prove that the interface passed to the destroy callback is always the version 1 of that interface. The tests would have failed on wine if e.g. I passed version 2 or 3 interface into the destroy callback. I agree that there are no direct tests confirming this though, but hopefully the two tests combined should be enough to confirm this. Cheers, Aaryaman

July 11, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta: > Anyways, the vtable qi tests tests written so far show that > querying IDirect3DRMObject from a particular interface will return > version 1 of that interface. So technically it all comes down to > calling > IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, > ...);. In our implementation of this method (see d3drm_main.c), we > have passed version 1 of the relevant interface while calling the > destroy callbacks within d3drm_object_destroy. The tests seem to > agree with that implementation so far. Well, but you can call AddDestroyCallback on the version 3 interface too: IDirect3DRMDevice *dev1; IDirect3DRMDevice3 *dev3; dev1 = create_device(); dev3 = dev1->qi(IID_IDirect3DRMDevice3); dev1->AddDestroyCallback(...); dev3->AddDestroyCallback(...); The current code will always pass dev1 to the callback. It may be correct, it may be wrong. But yeah, we won't accidentally pass an IDirect3DRMFrame interface to the callback if AddDestroyCallback was called on a device. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgz5NAAoJEN0/YqbEcdMw7RAP/1am78HbnuobIjjjBJYz+pCb lOPqKNZP2+dRIbJzTpd9Jgwz8Vonishwn9B+ZF6X71neWOHFG7xGFsGFq8OvuNBO c+jSOdrd/jkHLf61pllRBOk7QykoLCFIoaIbj843xeTeseabND7bwZwXVBKt34Gb hce0wquaITIntu5UPcLVnr3ak0meaADaXETRjiFamVnAPPmmyr3WyAYenVOT9P8c 1J8UneOEzBPXUtdsc8V4S0qQfpOEo9W8t1uh0M9FndAUNZyF9k7f6TzlEkA4e6C2 JzG5TfsIKg6LWgnX+WmGZ4ByZVfzdA/x0kWu7t0Gp9Wbb28rPMWs4yF2IU5uAw1q lHWIutHmmDCC7sxdyOOYp28ej1pxO3g23INynyUB3GTwAGyX2v/F+5a7Ge19IP1d 8A93T1id4ZZLzhF13oWHqFPhLLa1uoeAg0bpiXrC9SodK3x6YKrdBK/n/fyrHY3j 8fSrYBQwCt0ojV4Y7mqEZpG7M3+2asis26BdpaHGemcAlqEOThQOiIJiuvw/loWZ wkBGrzz5nkL6wTZHioPGCBkLm1vgD5H1N+wyYWDXQ2Adm+fgp7xP+VMMZ+66obCk CQgork1bnSkBsMWvafaGHim3+pbJdMXK1dbE3RjjdwC5bz2UsT2AxqH4ldJXEjxe gf+UMdoIzcyXS68E+Bpb =vqhG -----END PGP SIGNATURE-----

July 11, 2016

Re: [v3 1/2] winejoystick.drv: Print location ID in debugstr_device on the Mac

by DavidL

Hi Ken, Thanks, I'll make the changes. For the dinput & winmm patch 2/3 & 2/2, should I resubmit them as part of my version 4 of the overall patches even if they have been signed-off on? (although I think only the dinput one was signed off on) I'm not anticipating making any changes to signed-off sorting code patch based on the comments. Cheers, David On Sun, Jul 10, 2016 at 3:36 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > > > Tested on OS X 10.10.5. > > > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > > --- > > dlls/winejoystick.drv/joystick_osx.c | 30 ++++++++++++++++++++++++++++-- > > 1 file changed, 28 insertions(+), 2 deletions(-) > > This has similar issues as the dinput version, the main one being the > pointless "result" variable in get_device_property_long(). > > -Ken > >

July 11, 2016

Re: [PATCH] ddraw/tests: Skip A4R4G4B4 ckey tests on Nvidia (v3)

by Marvin

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=24144 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

July 10, 2016

Re: [v3 1/2] winejoystick.drv: Print location ID in debugstr_device on the Mac

by Ken Thomases

On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) This has similar issues as the dinput version, the main one being the pointless "result" variable in get_device_property_long(). -Ken

July 10, 2016

Re: [v3 3/3] dinput: Alter function name and code style

by Ken Thomases

On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > @@ -490,10 +490,10 @@ static int find_osx_devices(void) > if (devset) > { > CFIndex num_devices, num_main_elements, idx; > - CFMutableArrayRef devices = CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); > - CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, devices); > - CFRelease( devset); > - num_devices = CFArrayGetCount(devices); > + num_devices = CFSetGetCount(devset); > + CFMutableArrayRef devices = CFArrayCreateMutable(kCFAllocatorDefault, num_devices, &kCFTypeArrayCallBacks); You've now interleaved statements and declarations. Wine's code standard requires that declarations all come before statements. So, you could change the assignment of num_devices to an initialization or split the declaration and initialization of devices to separate declaration and assignment. Wine should be using -Wdeclaration-after-statement for its compile commands. Therefore, this change would have added a new warning. I know that some of the Mac files have a lot of warnings, which makes it hard to see new ones, but you should strive to avoid adding more. -Ken

July 10, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Aaryaman Vasishta

On Mon, Jul 11, 2016 at 3:18 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-10 um 21:49 schrieb Aaryaman Vasishta: > > I believe the "obj == ctxt->obj" tests in destroy_callback and > > destroy_callback1 should cover this. See test_destroy_callback. > If I understand it correctly not quite, because you're only ever > calling AddDestroyCallback via IDirect3DRMObject, never via > IDirect3DRMSomethingElse. > > (Re-CCed wine-devel) > My bad, I may have clicked on "Reply" instead of "Reply to All" on gmail again.. Anyways, the vtable qi tests tests written so far show that querying IDirect3DRMObject from a particular interface will return version 1 of that interface. So technically it all comes down to calling IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, ...);. In our implementation of this method (see d3drm_main.c), we have passed version 1 of the relevant interface while calling the destroy callbacks within d3drm_object_destroy. The tests seem to agree with that implementation so far. Do correct me if I have misunderstood something here, though. Cheers, Aaryaman

July 10, 2016

Re: [v3 1/3] dinput: Print location ID in debugstr_device on the Mac

by Ken Thomases

Hi, Sorry for the late review. See in-line comments: On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static void get_device_property_long(IOHIDDeviceRef in_device, CFStringRef in_key, long * out_value) As Dmitry suggested, you could make this simply return the property value rather than provide it through the indirect output parameter. > +{ > + Boolean result = FALSE; This variable isn't really used. It's assigned, but never read. > + CFTypeRef type; This variable isn't holding a type, it's holding a value or, if you prefer, an object reference. (The fact that its type is "CFTypeRef" doesn't imply it holds a type. Frankly, "CFTypeRef" is also a lousy name, but that's on Apple.) > + > + if (in_device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(in_device)); > + > + type = IOHIDDeviceGetProperty(in_device, in_key); > + > + if (type) > + { > + if (CFNumberGetTypeID() == CFGetTypeID(type)) You could combine these two "if" statements using &&. -Ken

July 10, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 21:49 schrieb Aaryaman Vasishta: > I believe the "obj == ctxt->obj" tests in destroy_callback and > destroy_callback1 should cover this. See test_destroy_callback. If I understand it correctly not quite, because you're only ever calling AddDestroyCallback via IDirect3DRMObject, never via IDirect3DRMSomethingElse. (Re-CCed wine-devel) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgsLBAAoJEN0/YqbEcdMwlsUP/2AIUfNl//T23Ik/gnL5FHVd 4axt1f/F5l1Hb5C3049Eh/se5SfF8jM6YYJte62al60f8nf0ERCW8S9JCzRueV2+ Q4ETvXbxhffKh9Ceb8W83ijxkwGf3GplypnXK7OQnqFUg88AR4YTGIL4I5pTPZVq Bw/MKgOfnDAHn+QsRDnzaQTtZcJPDNx+mrf26S/x15Wdi+PQjdVWb3uPbtgfkHN4 TWVwAgTQwPcnJQDaQ2wmWlEG+uxvxqpCF5BFCf1JwRV6oMdYYCQeHH+nvBrnPjEN /7Upv092RGbazucxMr6OWc9GJaCy4K9pfer8U2Ahdb47eAsF9UTO4AoW718GnIfU CJPvh8kMxukMw81U3U5Dr61v9cxd2xywz8ZMWMfKScrN4b6W7/hiE19B3+0w/XHi JHDf0NlPG8RDS+LR3N67X7dkaVqtEkRNCyVfAKdOozlz2EIlzs6lHmYNSxd17GO1 foIPVad9Ovo7nNQhB6FK+0zMZCKAz7be6ai9orlCk4ThhBhVwlaQXX16LBxgrYBi cU/3emOonGzto6sqzDrXyTNEqQTzvFMXnqitH/ITgvKuey0GBLHVSeOAHdECbrN3 bdGYdYPuXnxdksTey/zGORo4u0plUxS3gXiAGM0Ch0oCb6E9uzWMqKJpH6rIoR22 yAuKU7HOboWb3rlcAs0i =s5bk -----END PGP SIGNATURE-----

July 10, 2016

Re: [v2 01/10] webservices: Add support for writing double values.

by Sebastian Lackner

On 10.07.2016 20:30, Hans Leidekker wrote: > On Sun, 2016-07-10 at 03:28 +0200, Sebastian Lackner wrote: >> Unfortunately your patch does not work as expected here (gcc 5.3): >> >> ../../../tools/runtest -q -P wine -T ../../.. -M webservices.dll -p webservices_test.exe.so writer && touch writer.ok >> writer.c:358: Test failed: 1941: got 11 expected 10 >> writer.c:360: Test failed: 1941: got <t>:E-3</t>>000000004</t> expected <t>1E-2</t> >> writer.c:358: Test failed: 1941: got 12 expected 11 >> writer.c:360: Test failed: 1941: got <t>-:E-3</t>000000004</t> expected <t>-1E-2</t> >> Makefile:346: die Regel für Ziel „writer.ok“ scheiterte >> >> If you need any details to investigate this issue please let me know. > > Does this patch help? Note that it needs autoconf && autoheader. > Thanks. Yes, your proposed patch fixes the test failures. At first powl() wasn't detected, but then I remembered that this is a well-known bug when compiling with -Werror: conftest.c:370:6: warning: conflicting types for built-in function 'powl' Nevertheless, this also affects some other functions, so it probably should be fixed independently (if we care about it). Best regards, Sebastian

July 10, 2016

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 17:41 schrieb Aaryaman Vasishta: > static HRESULT WINAPI d3drm_device1_AddDestroyCallback(IDirect3DRMDevice *iface, > D3DRMOBJECTCALLBACK cb, void *ctx) > { > - FIXME("iface %p, cb %p, ctx %p stub!\n", iface, cb, ctx); > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, cb %p, ctx %p.\n", iface, cb, ctx); > + > + return d3drm_device3_AddDestroyCallback(&device->IDirect3DRMDevice3_iface, cb, ctx); > } It doesn't fit in this patch, but at some point we should test which interface is passed to the destroy callback: Is it the interface on which AddDestroyCallback was called, or is it the interface returned by iface->QueryInterface(&IID_IDirect3DRMObject)? Please correct me if we already have tests for that and I missed them :- ) . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgpstAAoJEN0/YqbEcdMwWkcP/j25Gk+jAQlDrb0l0YV5Tz0k V0D/PZW7lHMcGCeAW4Y8GyzzKAFVD+d8YL9RRHcxyWbUnl5f6nR/yjAe3da6FFpD AF+vDvKGlV1POG1QhC8d/34SxVYXsngKNq2tvxYVQOhldvKh9d9Ti255dLFicqG3 aBBzPF1OvY9ZaxQJQAyJdU9944YtaH3CUd6cxjOH95jR1hAiz55akKWDRQHm7Uc+ S77/XRaaUmGTX5gpma/EeY7Rb/eG3cEDF8UBoCI6rfu+kjIEa+KTJVZKzeSA5+RU xPETE28jUX94XZnRz8lqLJbSRboBXSa2MWDdb2KvBUqSTLPS1cTm55cLYRngWDAD czF8Wfo+UOfGeG9oGhorUE2GkOleDd/WtXQtAfJeAvxfBxd4aA5v66Z7IwhcVeEV sSEhsqxFfc31VBB/f4Ii3F/5nFyMN+LfcDUIHI4tmOMjwj+VMlIES//71BvYQpqm iJNo9DPSVUyqApIgPSNsYL7vORUl2AKsklJKk4fxka1j1010TLJdpFIyv4leLfL8 mBUY13S+wzaEObhztQJiMJ5usWu9BoClm38x4Oj5JzMZ2Pg2If0WAcVRLOLkb9Br GIyfN5K89SUmiJp6GoMtKG99QXypMsg1fanYe6imBTL8Cj5tGuVAoJlPDMpc8i07 JxITcNBrsu5/WwP8tGeq =Zf/v -----END PGP SIGNATURE-----

July 10, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by André Hentschel

Am 26.06.2016 um 17:31 schrieb André Hentschel: > Am 24.04.2016 um 21:12 schrieb Francois Gouget: >> >> I have added binaries compiled with my MinGW with -O2 and -O0, and >> compiled with the TestBot compiler. I also added assembly files and >> compiler version information. All of this is available at: >> >> http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz >> >> >> For immediate reference: >> My compiler is the Debian Testing compiler (buggy): >> $ i686-w64-mingw32-gcc --version >> i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> The TestBot compiler is the Debian 7.4 compiler (not buggy): >> $ i686-w64-mingw32-gcc --version >> i686-w64-mingw32-gcc (GCC) 4.6.3 >> Copyright (C) 2011 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> >> And the WineTest.exe binary is compiled with the Debian 8 compiler >> which is presumably close to the current Debian Testing one. > > What happens if we compile it using Clang? (totally easy to do so by using wclang [1] to generate a wrapper around clang and mingw-w64) > Or for me to try it, what's the best way to verify? does it depend on the wine version somewhat? > > [1] https://github.com/tpoechtrager/wclang > I noticed that my mingw-w64 has the same issue, so it was easy to try it out and it works! Could someone install wclang on that machine and make wine using it please? It's as easy as running configure like: ./configure CROSSCC=i686-w64-mingw32-clang ... or ./configure --host=i686-w64-mingw32 CC=i686-w64-mingw32-clang host_alias=i686-w64-mingw32 ... I compiled with (just exchanged i686-w64-mingw32-gcc with i686-w64-mingw32-clang): i686-w64-mingw32-clang -c -o device.cross.o ../../../../dlls/dinput8/tests/device.c -I. -I../../../../dlls/dinput8/tests \ -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 i686-w64-mingw32-clang -c -o dinput.cross.o ../../../../dlls/dinput8/tests/dinput.c -I. -I../../../../dlls/dinput8/tests \ -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 i686-w64-mingw32-clang -c -o testlist.cross.o testlist.c -I. -I../../../../dlls/dinput8/tests -I../../../include \ -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ../../../tools/winegcc/winegcc -o dinput8_crosstest.exe -b i686-w64-mingw32 -B../../../tools/winebuild \ --lib-suffix=.cross.a device.cross.o dinput.cross.o testlist.cross.o \ ../../../dlls/dinput8/libdinput8.cross.a ../../../dlls/ole32/libole32.cross.a \ ../../../dlls/user32/libuser32.cross.a ../../../dlls/advapi32/libadvapi32.cross.a

July 10, 2016

Re: [v2 01/10] webservices: Add support for writing double values.

by Hans Leidekker

On Sun, 2016-07-10 at 03:28 +0200, Sebastian Lackner wrote: > Unfortunately your patch does not work as expected here (gcc 5.3): > > ../../../tools/runtest -q -P wine -T ../../.. -M webservices.dll -p webservices_test.exe.so writer && touch writer.ok > writer.c:358: Test failed: 1941: got 11 expected 10 > writer.c:360: Test failed: 1941: got <t>:E-3</t>>000000004</t> expected <t>1E-2</t> > writer.c:358: Test failed: 1941: got 12 expected 11 > writer.c:360: Test failed: 1941: got <t>-:E-3</t>000000004</t> expected <t>-1E-2</t> > Makefile:346: die Regel für Ziel „writer.ok“ scheiterte > > If you need any details to investigate this issue please let me know. Does this patch help? Note that it needs autoconf && autoheader.

July 10, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by Sebastian Lackner

On 08.07.2016 00:16, John Sheu wrote: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/fiber.c | 291 +++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 258 insertions(+), 33 deletions(-) > > diff --git a/dlls/kernel32/tests/fiber.c b/dlls/kernel32/tests/fiber.c > index 1e4ca66..4f61f80 100644 > --- a/dlls/kernel32/tests/fiber.c > +++ b/dlls/kernel32/tests/fiber.c > @@ -33,9 +33,13 @@ static BOOL (WINAPI *pFlsFree)(DWORD); > static PVOID (WINAPI *pFlsGetValue)(DWORD); > static BOOL (WINAPI *pFlsSetValue)(DWORD,PVOID); > > -static LPVOID fibers[2]; > +static LPVOID fibers[3]; > static BYTE testparam = 185; > -static WORD cbCount; > +static DWORD fls_index_to_set = FLS_OUT_OF_INDEXES; > +static PVOID fls_value_to_set = NULL; > + > +static int fiberCount = 0; > +static int cbCount = 0; > > static VOID init_funcs(void) > { > @@ -59,15 +63,44 @@ static VOID init_funcs(void) > > static VOID WINAPI FiberLocalStorageProc(PVOID lpFlsData) > { > + ok(lpFlsData == fls_value_to_set, > + "FlsData expected not to be changed, value is %p, expected %p\n", > + lpFlsData, fls_value_to_set); > cbCount++; > - ok(lpFlsData == (PVOID) 1587, "FlsData expected not to be changed\n"); > } > > static VOID WINAPI FiberMainProc(LPVOID lpFiberParameter) > { > BYTE *tparam = (BYTE *)lpFiberParameter; > - cbCount++; > + fiberCount++; > ok(*tparam == 185, "Parameterdata expected not to be changed\n"); > + if (fls_index_to_set != FLS_OUT_OF_INDEXES) > + { > + if (!pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); You can get rid of this check, fls_index_to_set should not be set when Fiber Local Storage is not supported. > + } > + else > + { > + PVOID pret; Usually "void *" types and variable names without "p" prefix are preferred. > + BOOL bret; > + > + pret = pFlsGetValue(fls_index_to_set); > + ok(pret == NULL, "FlsGetValue returned %p, expected NULL\n", pret); > + > + /* Set the FLS value */ > + SetLastError( 0xdeadbeef ); You can remove this line when you are not testing the error value. > + bret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(bret, "FlsSetValue failed with error %u\n", GetLastError()); > + > + /* Verify that FlsGetValue retrieves the value set by FlsSetValue */ > + SetLastError( 0xdeadbeef ); > + pret = pFlsGetValue(fls_index_to_set); > + ok(pret == fls_value_to_set, > + "FlsGetValue returned %p, expected %p\n", pret, fls_value_to_set); > + ok(GetLastError() == ERROR_SUCCESS, "FlsGetValue error %u\n", GetLastError()); > + } > + } > pSwitchToFiber(fibers[0]); > } > > @@ -110,9 +143,23 @@ static void test_ConvertFiberToThread(void) > } > } > > +static void test_IsThreadAFiber(BOOL is_fiber) > +{ > + if (pIsThreadAFiber) > + { > + BOOL ret = pIsThreadAFiber(); > + ok(ret == is_fiber, "IsThreadAFiber reported %d, expected %d\n", ret, is_fiber); > + } > + else > + { > + win_skip( "IsThreadAFiber not present\n" ); > + return; return at the end of a function is unnecessary. Also, I'm not sure if it makes much sense to have this as a separate function. You could probably just inline it in this case. > + } > +} > + > static void test_FiberHandling(void) > { > - cbCount = 0; > + fiberCount = 0; > fibers[0] = pCreateFiber(0,FiberMainProc,&testparam); > ok(fibers[0] != 0, "CreateFiber failed with error %d\n", GetLastError()); > pDeleteFiber(fibers[0]); > @@ -124,12 +171,11 @@ static void test_FiberHandling(void) > else > test_ConvertThreadToFiber(); > > - > fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); > ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); > > pSwitchToFiber(fibers[1]); > - ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > pDeleteFiber(fibers[1]); > > if (!pCreateFiberEx) > @@ -143,46 +189,72 @@ static void test_FiberHandling(void) > ok(fibers[1] != 0, "CreateFiberEx failed with error %d\n", GetLastError()); > > pSwitchToFiber(fibers[1]); > - ok(cbCount == 2, "Wrong callback count: %d\n", cbCount); > + ok(fiberCount == 2, "Wrong fiber count: %d\n", fiberCount); > pDeleteFiber(fibers[1]); > > - if (!pIsThreadAFiber) > - { > - win_skip( "IsThreadAFiber not present\n" ); > - return; > - } > - > - ok(pIsThreadAFiber(), "IsThreadAFiber reported FALSE\n"); > + test_IsThreadAFiber(TRUE); > test_ConvertFiberToThread(); > - ok(!pIsThreadAFiber(), "IsThreadAFiber reported TRUE\n"); > + test_IsThreadAFiber(FALSE); > } > > -static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > +static void test_FiberLocalStorage(void) > { > - DWORD fls; > + DWORD fls, fls_2; > BOOL ret; > - PVOID val = (PVOID) 1587; > + PVOID val; "void *" would be preferred here. > > - if (!pFlsAlloc) > + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) > { > win_skip( "Fiber Local Storage not supported\n" ); > return; > } > - cbCount = 0; > > - fls = pFlsAlloc(cbfunc); > - ok(fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); > + /* Test an unallocated index > + * FlsFree should fail > + * FlsGetValue and FlsSetValue should succeed > + */ > + SetLastError( 0xdeadbeef ); > + ret = pFlsFree( 127 ); > + ok( !ret, "freeing fls index 127 (unallocated) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "freeing fls index 127 (unallocated) wrong error %u\n", GetLastError() ); > > - ret = pFlsSetValue(fls, val); > - ok(ret, "FlsSetValue failed\n"); > - ok(val == pFlsGetValue(fls), "FlsGetValue failed\n"); > + SetLastError( 0xdeadbeef ); This is unnecessary if you don't test the error. > + val = pFlsGetValue( 127 ); > + ok( val == NULL, > + "getting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsSetValue( 127, (PVOID) 0x217 ); "(void *)0x217" would be preferred here (and at a couple of places below). > + ok( ret, "setting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + val = pFlsGetValue( 127 ); > + ok( val == (PVOID) 0x217, "fls index 127 (unallocated) wrong value %p\n", val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + /* FlsFree, FlsGetValue, and FlsSetValue out of bounds should return > + * ERROR_INVALID_PARAMETER > + */ > + SetLastError( 0xdeadbeef ); > + ret = pFlsFree( 128 ); > + ok( !ret, "freeing fls index 128 (out of bounds) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "freeing fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); > > - ret = pFlsFree(fls); > - ok(ret, "FlsFree failed\n"); > - if (cbfunc) > - todo_wine ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + SetLastError( 0xdeadbeef ); > + ret = pFlsSetValue( 128, (PVOID) 0x217 ); > + ok( !ret, "setting fls index 128 (out of bounds) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "setting fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + val = pFlsGetValue( 128 ); It would make sense to test "val" aswell. > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "setting fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); The function above is no set function. > > - /* test index 0 */ > + /* Test index 0 */ > SetLastError( 0xdeadbeef ); > val = pFlsGetValue( 0 ); > ok( !val, "fls index 0 set to %p\n", val ); > @@ -196,6 +268,7 @@ static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > ok( !val, "fls index 0 wrong value %p\n", val ); > ok( GetLastError() == ERROR_INVALID_PARAMETER, "setting fls index wrong error %u\n", GetLastError() ); > > + /* Test creating an FLS index */ > fls = pFlsAlloc( NULL ); > ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed\n" ); > ok( fls != 0, "fls index 0 allocated\n" ); > @@ -205,11 +278,162 @@ static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > ok( ret, "setting fls index %u failed\n", fls ); > val = pFlsGetValue( fls ); > ok( val == (void *)0xdeadbeef, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls, GetLastError() ); > pFlsFree( fls ); > + > + /* Undefined behavior: verify the value is NULL after it the slot is freed */ > + val = pFlsGetValue( fls ); > + ok( val == NULL, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls, GetLastError() ); > + > + /* Undefined behavior: verify the value is settable after the slot is freed */ > ret = pFlsSetValue( fls, (void *)0xdeadbabe ); > ok( ret, "setting fls index %u failed\n", fls ); > val = pFlsGetValue( fls ); > ok( val == (void *)0xdeadbabe, "fls index %u wrong value %p\n", fls, val ); > + > + /* Try to create the same FLS index again, and verify that is initialized to NULL */ > + fls_2 = pFlsAlloc( NULL ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed\n" ); > + /* If this fails it is not an API error, but the test will be inconclusive */ > + ok( fls_2 == fls, "different FLS index allocated, was %u, now %u\n", fls, fls_2 ); > + val = pFlsGetValue( fls_2 ); > + ok( val == NULL, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls_2, GetLastError() ); A SetLastError() call is missing here, otherwise this test is not really convincing. > + pFlsFree( fls_2 ); > +} > + > +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { All the other functions have the "{" on the next line. > + DWORD fls; > + BOOL ret; > + PVOID val, val2; > + > + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + /* Test that the callback is executed */ > + SetLastError( 0xdeadbeef ); This is unnecessary. > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); This also. > + val = (PVOID) 0x1587; > + fls_value_to_set = val; > + ret = pFlsSetValue( fls, val ); > + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + val2 = pFlsGetValue( fls ); > + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsFree( fls ); > + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); > + todo_wine > + { > + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); > + } > + > + /* Test that callback is not executed if value is NULL */ > + SetLastError( 0xdeadbeef ); Same here. > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsSetValue( fls, NULL ); > + ok( ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + pFlsFree( fls ); > + ok( ret, "FlsFree failed with error %u\n", GetLastError() ); > + ok( cbCount == 0, "Wrong callback count: %d\n", cbCount ); > +} > + > +static void test_FiberLocalStorageWithFibers(PFLS_CALLBACK_FUNCTION cbfunc) { > + PVOID val1 = (PVOID) 0x314; > + PVOID val2 = (PVOID) 0x152; > + BOOL ret; > + > + if (!pConvertThreadToFiber || !pSwitchToFiber || !pDeleteFiber || !pConvertFiberToThread) > + { > + win_skip( "Fibers not supported\n" ); > + return; > + } > + if (!pFlsAlloc || !pFlsFree || !pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + > + fls_index_to_set = pFlsAlloc(cbfunc); > + ok(fls_index_to_set != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); Not really critical, but in the code above you used %u for GetLastError values. > + > + test_ConvertThreadToFiber(); > + > + fiberCount = 0; > + cbCount = 0; > + fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); > + fibers[2] = pCreateFiber(0,FiberMainProc,&testparam); > + ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); > + ok(fibers[2] != 0, "CreateFiber failed with error %d\n", GetLastError()); CreateFiber returns a pointer, so it would be better to compare against NULL. > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pSwitchToFiber(fibers[1]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val2; > + pSwitchToFiber(fibers[2]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fls_value_to_set = val2; > + ret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(ret, "FlsSetValue failed\n"); > + ok(val2 == pFlsGetValue(fls_index_to_set), "FlsGetValue failed\n"); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pDeleteFiber(fibers[1]); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + todo_wine > + { > + ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + } > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val2; > + pFlsFree(fls_index_to_set); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + todo_wine > + { > + ok(cbCount == 2, "Wrong callback count: %d\n", cbCount); > + } > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pDeleteFiber(fibers[2]); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + test_ConvertFiberToThread(); > } > > START_TEST(fiber) > @@ -223,6 +447,7 @@ START_TEST(fiber) > } > > test_FiberHandling(); > - test_FiberLocalStorage(NULL); > - test_FiberLocalStorage(FiberLocalStorageProc); > + test_FiberLocalStorage(); > + test_FiberLocalStorageCallback(FiberLocalStorageProc); > + test_FiberLocalStorageWithFibers(FiberLocalStorageProc); > } >

July 10, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by Sebastian Lackner

On 10.07.2016 19:51, André Hentschel wrote: > Am 10.07.2016 um 19:38 schrieb Nikolay Sivov: >> On 10.07.2016 20:31, André Hentschel wrote: >>> Hi, >>> >>> comments inline >>> >>> Am 08.07.2016 um 00:16 schrieb John Sheu: >>>> +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { >>>> + DWORD fls; >>>> + BOOL ret; >>>> + PVOID val, val2; >>>> + >>>> + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) >>>> + { >>>> + win_skip( "Fiber Local Storage not supported\n" ); >>>> + return; >>>> + } >>>> + >>>> + /* Test that the callback is executed */ >>>> + SetLastError( 0xdeadbeef ); >>>> + cbCount = 0; >>>> + fls = pFlsAlloc( cbfunc ); >>>> + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); >>>> + >>>> + SetLastError( 0xdeadbeef ); >>>> + val = (PVOID) 0x1587; >>>> + fls_value_to_set = val; >>>> + ret = pFlsSetValue( fls, val ); >>>> + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); >>>> + >>>> + val2 = pFlsGetValue( fls ); >>>> + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); >>>> + >>>> + SetLastError( 0xdeadbeef ); >>>> + ret = pFlsFree( fls ); >>>> + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); >>>> + todo_wine >>>> + { >>>> + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); >>>> + } >>> >>> >>> Please make those one-liners, like >>> todo_wine ok(...); >>> and the patch should be fine then >> >> How is this a stopper? > > It's not directly a stopper. > But I personally really don't like it that way and it somehow prevents me from a sign-off. And I think I'll add myself as a Maintainer for that file, so the style should fit somewhat. Its up to you of course, but please note that you can also send a fixed version yourself. Just make sure to add a From: header such that the original author does not get lost.

July 10, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by André Hentschel

Am 10.07.2016 um 19:38 schrieb Nikolay Sivov: > On 10.07.2016 20:31, André Hentschel wrote: >> Hi, >> >> comments inline >> >> Am 08.07.2016 um 00:16 schrieb John Sheu: >>> +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { >>> + DWORD fls; >>> + BOOL ret; >>> + PVOID val, val2; >>> + >>> + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) >>> + { >>> + win_skip( "Fiber Local Storage not supported\n" ); >>> + return; >>> + } >>> + >>> + /* Test that the callback is executed */ >>> + SetLastError( 0xdeadbeef ); >>> + cbCount = 0; >>> + fls = pFlsAlloc( cbfunc ); >>> + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); >>> + >>> + SetLastError( 0xdeadbeef ); >>> + val = (PVOID) 0x1587; >>> + fls_value_to_set = val; >>> + ret = pFlsSetValue( fls, val ); >>> + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); >>> + >>> + val2 = pFlsGetValue( fls ); >>> + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); >>> + >>> + SetLastError( 0xdeadbeef ); >>> + ret = pFlsFree( fls ); >>> + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); >>> + todo_wine >>> + { >>> + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); >>> + } >> >> >> Please make those one-liners, like >> todo_wine ok(...); >> and the patch should be fine then > > How is this a stopper? It's not directly a stopper. But I personally really don't like it that way and it somehow prevents me from a sign-off. And I think I'll add myself as a Maintainer for that file, so the style should fit somewhat.

July 10, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by Nikolay Sivov

On 10.07.2016 20:31, André Hentschel wrote: > Hi, > > comments inline > > Am 08.07.2016 um 00:16 schrieb John Sheu: >> +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { >> + DWORD fls; >> + BOOL ret; >> + PVOID val, val2; >> + >> + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) >> + { >> + win_skip( "Fiber Local Storage not supported\n" ); >> + return; >> + } >> + >> + /* Test that the callback is executed */ >> + SetLastError( 0xdeadbeef ); >> + cbCount = 0; >> + fls = pFlsAlloc( cbfunc ); >> + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); >> + >> + SetLastError( 0xdeadbeef ); >> + val = (PVOID) 0x1587; >> + fls_value_to_set = val; >> + ret = pFlsSetValue( fls, val ); >> + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); >> + >> + val2 = pFlsGetValue( fls ); >> + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); >> + >> + SetLastError( 0xdeadbeef ); >> + ret = pFlsFree( fls ); >> + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); >> + todo_wine >> + { >> + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); >> + } > > > Please make those one-liners, like > todo_wine ok(...); > and the patch should be fine then How is this a stopper? > > >> + >> + /* Test that callback is not executed if value is NULL */ >> + SetLastError( 0xdeadbeef ); >> + cbCount = 0; >> + fls = pFlsAlloc( cbfunc ); >> + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); >> + >> + SetLastError( 0xdeadbeef ); >> + ret = pFlsSetValue( fls, NULL ); >> + ok( ret, "FlsSetValue failed with error %u\n", GetLastError() ); >> + >> + SetLastError( 0xdeadbeef ); >> + pFlsFree( fls ); >> + ok( ret, "FlsFree failed with error %u\n", GetLastError() ); >> + ok( cbCount == 0, "Wrong callback count: %d\n", cbCount ); >> +} > > >

July 10, 2016

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.

by André Hentschel

Hi, comments inline Am 08.07.2016 um 00:16 schrieb John Sheu: > +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { > + DWORD fls; > + BOOL ret; > + PVOID val, val2; > + > + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + /* Test that the callback is executed */ > + SetLastError( 0xdeadbeef ); > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + val = (PVOID) 0x1587; > + fls_value_to_set = val; > + ret = pFlsSetValue( fls, val ); > + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + val2 = pFlsGetValue( fls ); > + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); > + > + SetLastError( 0xdeadbeef ); > + ret = pFlsFree( fls ); > + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); > + todo_wine > + { > + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); > + } Please make those one-liners, like todo_wine ok(...); and the patch should be fine then > + > + /* Test that callback is not executed if value is NULL */ > + SetLastError( 0xdeadbeef ); > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + ret = pFlsSetValue( fls, NULL ); > + ok( ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + pFlsFree( fls ); > + ok( ret, "FlsFree failed with error %u\n", GetLastError() ); > + ok( cbCount == 0, "Wrong callback count: %d\n", cbCount ); > +}

July 10, 2016

Re: [PATCH 07/12] d3drm: Implement IDirect3DRMViewport*::Init. (v4)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 17:34 schrieb Aaryaman Vasishta: > You mean accessing the struct directly instead of via the > interface functions? I'm fine with that too. The interface > functions do provide a way to get most of what's needed (I could be > wrong though, maybe some internal data that's not revealed outside > can still be utilized within calls), but I guess using the struct > directly would be cleaner, and safer in the long run. If you expect that the external API is enough stick to the interface. It's no big issue to change it later if needed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgoRjAAoJEN0/YqbEcdMwcBcQAI/7D9EYR3M+/ctNPdf1q2C7 YTZnYO6zbSUwflEP5zt7T2rDzZ+eG7PeLowu3LE+pNdUAkbLGGbJQ7tIaBTsYLG2 lOFCaqNehH0OPzW1CpOeu42US2qMRWnsmDJRnopUDiOnHyuNa5PqRlzncKJl1x3/ ci2JRQ2SiVdjvQTp0OGPkAXMLAri7R3kdrIIgZ+gnytWJ91fCeO016Jg1OxeV3Rr 5fOUx6Fk3+uS0e36+D8SRgF5mRBdP2o6g2Hzio+2+zScwonvIehVo/WeeTXRIZob 0AWhvs0Jf6JkQaVLYkR0p3LuRR2PhBsfVccr3pgt10kZG2hYKr4YCAXGsuhlp77r CasFGOTMv/f4AnzTpQSCvaR34omrZYbvVgHlP1X1VRHnUxUQfgqmDjuaHtAq8Kql miQ6cNkLW1AybZx43+rRJnKWsuvviXTgSTek8ccMOcPeB07RkS4bpRuepBNYW5mW Vz9uqMotRXqSpZaaggHZB2fIJ5uah/LPcSbwfdiqVNYcaVexbSeYdZm+tzHPO3Ie EydiWAYRDJ8LxG4t8hyjNGkUnk+aGa5o2XzGdKQLhY02wXWQKLFAKMez2280NK8T S8A1AoR04h2elZ85MyGh+bRs4zZwQGm0zKSHkkNa+uoaJLZfmPcNy3X1pMXyHK+b dDGyJaf2q/kwKA6w/UA9 =2S4r -----END PGP SIGNATURE-----

July 10, 2016

Re: [PATCH 07/12] d3drm: Implement IDirect3DRMViewport*::Init. (v4)

by Aaryaman Vasishta

On Sun, Jul 10, 2016 at 9:39 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > > - {&CLSID_CDirect3DRMTexture, d3drm_create_texture_object}, > > - {&CLSID_CDirect3DRMDevice, d3drm_create_device_object}, > > + { &CLSID_CDirect3DRMTexture, d3drm_create_texture_object }, > > + { &CLSID_CDirect3DRMDevice, d3drm_create_device_object }, > > + { &CLSID_CDirect3DRMViewport, d3drm_create_viewport_object }, > I guess Visual Studio or xcode re-added the spaces between { and &. Henri > removed them in the slightly modified version of "d3drm: Use a table in > d3drm3_CreateObject() to create objects in a generic manner." > True. I actually thought this was fine since the QI test tables were formatted in a similar way (see test_d3drm_qi, test_texture_qi etc). But I guess the current format is considered better, so I'll go with that for the implementations. > > > + if (FAILED(hr = IDirect3DRMFrame3_QueryInterface(camera, > &IID_IDirect3DRMFrame, (void **)&viewport->camera))) > > + goto cleanup; > Aren't you more likely to need the implementation structure of the camera > in the future? > You mean accessing the struct directly instead of via the interface functions? I'm fine with that too. The interface functions do provide a way to get most of what's needed (I could be wrong though, maybe some internal data that's not revealed outside can still be utilized within calls), but I guess using the struct directly would be cleaner, and safer in the long run. > > > + > > + if (material) > > + IDirect3DMaterial_Release(material); > In the success case this will destroy the material you just created. Our > IDirect3DViewport::SetBackground implementation does not AddRef the > material. I don't think we have any tests for this, but because > SetBackground accepts a handle instead of a COM object I don't expect it to > AddRef. > > Overall it seems questionable to call camera->GetSceneBackground and apply > the color here. I'd expect that the camera background can be changed after > creating the viewport. > Ah, I was under the impression that IDirect3DViewport keeps a reference to the material (should have studied its implementation here). So I guess a reference to the material should be stored in the struct as well, and released on destroy. Cheers, Aaryaman

July 10, 2016

Re: [PATCH 05/12] d3drm: Implement IDirect3DRMDevice*::InitFromD3D.

by Aaryaman Vasishta

On Sun, Jul 10, 2016 at 9:10 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Patches 1-4 look good to me, once the fixes you mentioned and we talked > about on IRC are implemented. > > Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > > struct d3drm_frame > > { > > + struct d3drm_object obj; > This seems unrelated. > Could be leftover from a rebase. Will remove it. > > > + if (device->ddraw) > > + hr = D3DRMERR_BADOBJECT; > I guess you're not returning here right away because you want to addref > d3drm later. Wouldn't it be better to move those AddRefs in front in this > case? > > The QueryInterface / GetRenderTarget code below is unlikely to fail, if it > does something is severely wrong (A d3d device without a render target???) > and getting the reference leak right is the last of your worries. > This also brings me to another problem. What if init is called using a different d3d/device? I don't think it should re-set the new d3d/device on an existing object. I guess the double initialization path should be handled separately. I should probably add tests for this and change implementations accordingly. > > > device->width = desc.dwWidth; > > device->height = desc.dwHeight; > If I read the diff right this code will set width and height to 0 on an > already initialized device. > Right, this should probably be only set in the case where the device is not already initialized. > > > static HRESULT WINAPI > d3drm_device3_GetDirect3DDevice2(IDirect3DRMDevice3 *iface, > IDirect3DDevice2 **d3d_device) > > { > > struct d3drm_device *device = impl_from_IDirect3DRMDevice3(iface); > > + HRESULT hr; > > > > TRACE("iface %p, d3d_device %p.\n", iface, d3d_device); > > > > - IDirect3DDevice_QueryInterface(device->device, > &IID_IDirect3DDevice2, (void**)d3d_device); > > + if (FAILED(hr = IDirect3DDevice_QueryInterface(device->device, > &IID_IDirect3DDevice2, (void**)d3d_device))) > > + hr = D3DRMERR_BADOBJECT; > > > > - return D3DRM_OK; > > + return hr; > > } > I think this change (like the device2_GetDirect3DDevice2 one) can be moved > to a separate patch. > Right, this was noticed by me and I've split these changes into a separate patch (as discussed on IRC). > > > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, d3ddevice1); > > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, > got %#x.\n", hr); > > + ref3 = get_refcount((IUnknown *)d3ddevice1); > > + ok(ref3 > device_ref2, "Expected ref3 > device_ref2, got ref3 = %u, > device_ref2 = %u.\n", ref3, device_ref2); > > + ref3 = get_refcount((IUnknown *)d3d1); > > + ok(ref3 > d3d_ref2, "Expected ref3 > d3d_ref2, got ref3 = %u, > d3d_ref2 = %u.\n", ref3, d3d_ref2); > You forgot to test the reference of d3drm1. > > > + hr = IDirect3DRMDevice_QueryInterface(device1, > &IID_IDirect3DRMDevice2, (void **)&device2); > > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 Interface (hr = > %x).\n", hr); > > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > > + ok(SUCCEEDED(hr), "Expected hr == D3DRM_OK, got %#x.\n", hr); > > + ok(d3ddevice2 == NULL, "Expected d3ddevice2 == NULL, got %p.\n", > d3ddevice2); > > + IDirect3DRMDevice2_Release(device2); > You forgot d3ddevice2 = 0xdeadbeef here. > > > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMDevice, > NULL, &IID_IDirect3DRMDevice2, (void **)&device2); > > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 interface (hr = > %#x).\n", hr); > > + > > + hr = IDirectDraw_QueryInterface(ddraw1, &IID_IDirect3D, (void > **)&d3d1); > > + ok(SUCCEEDED(hr), "Cannot get IDirect3D interface (hr = %x).\n", > hr); > > + if (SUCCEEDED(hr = IDirect3DDevice2_QueryInterface(d3ddevice2, > &IID_IDirect3DDevice, (void **)&d3ddevice1))) > > + { > > + hr = IDirect3DRMDevice2_InitFromD3D(device2, d3d1, d3ddevice1); > > + ok(hr == E_NOINTERFACE, "Expected hr == E_NOINTERFACE, got > %#x.\n", hr); > What happens if you QI IDirect3DRMDevice1 from IDirect3DRMDevice2 and call > InitFromD3D on it? I would expect it to succeed because common decency > suggests that CreateObject doesn't leave a history of which interface was > requested and there's no CLSID_CDirect3DRMDevice2 or > CLSID_CDirect3DRMDevice3. Still worth a check though I think. > True, it makes sense. These tests should be added in here as well. Will do the same for patch 6 too. I will do the rest of the changes and resend the patch, along with the fixes to similar problems to patch 6 as well. Thanks for the review! :) Cheers, Aaryaman

July 10, 2016

Re: [PATCH 07/12] d3drm: Implement IDirect3DRMViewport*::Init. (v4)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > - {&CLSID_CDirect3DRMTexture, d3drm_create_texture_object}, > - {&CLSID_CDirect3DRMDevice, d3drm_create_device_object}, > + { &CLSID_CDirect3DRMTexture, d3drm_create_texture_object }, > + { &CLSID_CDirect3DRMDevice, d3drm_create_device_object }, > + { &CLSID_CDirect3DRMViewport, d3drm_create_viewport_object }, I guess Visual Studio or xcode re-added the spaces between { and &. Henri removed them in the slightly modified version of "d3drm: Use a table in d3drm3_CreateObject() to create objects in a generic manner." > + if (FAILED(hr = IDirect3DRMFrame3_QueryInterface(camera, &IID_IDirect3DRMFrame, (void **)&viewport->camera))) > + goto cleanup; Aren't you more likely to need the implementation structure of the camera in the future? > + > + color = IDirect3DRMFrame3_GetSceneBackground(camera); > + /* Create material (ambient/diffuse/emissive?), set material */ > + if (FAILED(hr = IDirect3D_CreateMaterial(d3d1, &material, NULL))) > + goto cleanup; > + > + memset(&mat, 0, sizeof(mat)); > + memcpy(&mat.diffuse, &color, sizeof(color)); > + > + if (FAILED(hr = IDirect3DMaterial_SetMaterial(material, &mat))) > + goto cleanup; > + > + if (FAILED(hr = IDirect3DMaterial_GetHandle(material, d3d_device, &hmat))) > + goto cleanup; > + > + hr = IDirect3DViewport_SetBackground(viewport->d3d_viewport, hmat); > + > +cleanup: > + > + if (material) > + IDirect3DMaterial_Release(material); In the success case this will destroy the material you just created. Our IDirect3DViewport::SetBackground implementation does not AddRef the material. I don't think we have any tests for this, but because SetBackground accepts a handle instead of a COM object I don't expect it to AddRef. Overall it seems questionable to call camera->GetSceneBackground and apply the color here. I'd expect that the camera background can be changed after creating the viewport. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgnMdAAoJEN0/YqbEcdMwk+IP/2DZH4tPgtCN/PHoB/ZdsVwJ oodz6Sax5LZUaumbXZme4CPgPZKSKr44ue3qho/5cQicRISuJ3G6I6vFmkiiHol6 nFmY9cTJiNeXzd6NcJq5KK6IUmgrzO5YjGgXIbzgzEiTycbws/lo5fVwF74LSYn7 RMPg+U4qMaHVT/w/rb7dWWqPugSbm8cIGfp8Zjz2VrO+JX+S1Qs3ymCZViyMfCRz A1VtyJh/u72GlfCoRoUiT6DDsMjw1BCMogR4asDkQmoTdkc7XFRU3MYQwUN7cFY2 bxos78d6xozUwvDRoezrtRLh4gQis9gudaNYv4Dt4fZjNOSvCtA8fMbl35gXuJog ooROiaXSoW5oBrzv++Fvp38cixS0j9MMECNDgs1yCCKt0a/B4/IFEQMvyGt5LzRG zeJ2XzDEZI3ntsbeVdKPRuH6m7ROlQLfp+Q0ac+MrhJSQtnAd88mXVfU5U8330b4 DNyeSmyPhBpaRp62WZxMCeOct7psy1p4LYkbbE5QZ3eFS2QhHlnPC6PzNtcUbDqI RG4J+ZhquDnT57ViyjX1vKt6tXPlDOkwJf0AApwQ84OGs7ATNci/7Z1WuyULx9sR xPrpNYUPbFIxcadmvaa7jO+aaOXoNWFQQz7rJdCVBxUY1T4Bz8+FyzQ0O8Ld/xNj b7LndQJz3AbU//fQ1gdO =8gsI -----END PGP SIGNATURE-----

July 10, 2016

Re: [PATCH 05/12] d3drm: Implement IDirect3DRMDevice*::InitFromD3D.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Patches 1-4 look good to me, once the fixes you mentioned and we talked about on IRC are implemented. Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > struct d3drm_frame > { > + struct d3drm_object obj; This seems unrelated. > + if (device->ddraw) > + hr = D3DRMERR_BADOBJECT; I guess you're not returning here right away because you want to addref d3drm later. Wouldn't it be better to move those AddRefs in front in this case? The QueryInterface / GetRenderTarget code below is unlikely to fail, if it does something is severely wrong (A d3d device without a render target???) and getting the reference leak right is the last of your worries. > device->width = desc.dwWidth; > device->height = desc.dwHeight; If I read the diff right this code will set width and height to 0 on an already initialized device. > static HRESULT WINAPI d3drm_device3_GetDirect3DDevice2(IDirect3DRMDevice3 *iface, IDirect3DDevice2 **d3d_device) > { > struct d3drm_device *device = impl_from_IDirect3DRMDevice3(iface); > + HRESULT hr; > > TRACE("iface %p, d3d_device %p.\n", iface, d3d_device); > > - IDirect3DDevice_QueryInterface(device->device, &IID_IDirect3DDevice2, (void**)d3d_device); > + if (FAILED(hr = IDirect3DDevice_QueryInterface(device->device, &IID_IDirect3DDevice2, (void**)d3d_device))) > + hr = D3DRMERR_BADOBJECT; > > - return D3DRM_OK; > + return hr; > } I think this change (like the device2_GetDirect3DDevice2 one) can be moved to a separate patch. > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, d3ddevice1); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + ref3 = get_refcount((IUnknown *)d3ddevice1); > + ok(ref3 > device_ref2, "Expected ref3 > device_ref2, got ref3 = %u, device_ref2 = %u.\n", ref3, device_ref2); > + ref3 = get_refcount((IUnknown *)d3d1); > + ok(ref3 > d3d_ref2, "Expected ref3 > d3d_ref2, got ref3 = %u, d3d_ref2 = %u.\n", ref3, d3d_ref2); You forgot to test the reference of d3drm1. > + hr = IDirect3DRMDevice_QueryInterface(device1, &IID_IDirect3DRMDevice2, (void **)&device2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 Interface (hr = %x).\n", hr); > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + ok(SUCCEEDED(hr), "Expected hr == D3DRM_OK, got %#x.\n", hr); > + ok(d3ddevice2 == NULL, "Expected d3ddevice2 == NULL, got %p.\n", d3ddevice2); > + IDirect3DRMDevice2_Release(device2); You forgot d3ddevice2 = 0xdeadbeef here. > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMDevice, NULL, &IID_IDirect3DRMDevice2, (void **)&device2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 interface (hr = %#x).\n", hr); > + > + hr = IDirectDraw_QueryInterface(ddraw1, &IID_IDirect3D, (void **)&d3d1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3D interface (hr = %x).\n", hr); > + if (SUCCEEDED(hr = IDirect3DDevice2_QueryInterface(d3ddevice2, &IID_IDirect3DDevice, (void **)&d3ddevice1))) > + { > + hr = IDirect3DRMDevice2_InitFromD3D(device2, d3d1, d3ddevice1); > + ok(hr == E_NOINTERFACE, "Expected hr == E_NOINTERFACE, got %#x.\n", hr); What happens if you QI IDirect3DRMDevice1 from IDirect3DRMDevice2 and call InitFromD3D on it? I would expect it to succeed because common decency suggests that CreateObject doesn't leave a history of which interface was requested and there's no CLSID_CDirect3DRMDevice2 or CLSID_CDirect3DRMDevice3. Still worth a check though I think. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgmxrAAoJEN0/YqbEcdMw9dQP/RbovFFjwIdo5ho2BcxWi1Sm 68U7n+sX+HAPmHPc2W/fOK1scbPaQz84e3cHj+dsFClCUKNLUpZ1eGdJDu1u9Fgh ZJVC9hgw8rzC+IDGr5vdmuzzOj65mI7KslJX9CfD9tnXigLtlvPf3me8jnhjL51b Eq8N1rStZTh805gDBEnmr/oqgQFkRoHKgs5lLIWq2inAfF3dq0BiThBGpC+eq19H YcihqOJWgSXrbXQYtTPjFtjp3jqqFa32+/ZQufCEAELcYUjM2gG23+O/rT5sa4d2 QuQOIhdUnTR9G6WnoZXgxKwxtJTvTu02GKlk5gaIkpWFJ2O+mPJuiBmylLoucQ6V BkYkhORuT2WYKainbTx3qNJaxBPSa5/y4HWTpQhzYH0LryFBLkL8MiVjO+pGk7QM 4wHTeL4ZXmjtyYOs6qfuxNIEJyfDs0hU5850lWdVD6MLaj3JwZYRLedCJ9TwV7Jb Qz3JQIK6YPOgTSqehIGTwzxgcbvjjiLP2zalEV4HOIqKeEkodcBxVS0QiXSDbuAj gLhbqwlRMshT5Dtt1Umi2KUoGljFjh1rbe42cyVxXcoa72D+g9LQUb4d0hUP/Ppt 6lNhfq+Vf2W+FmdB2Hv/WWof7vBV59r/TwjjExrN00yRGCLNLF3BaK8lzjeJprGO H6J9OAsscEyzMNpB+l0W =exYP -----END PGP SIGNATURE-----

July 10, 2016

Re: [PATCH 1/2] d3d9/tests/visual: Add Vertexbuffer locking tests

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Patrick, I ran your tests on one of my Nvidia machines, see below. Thanks for looking into this. I had problems with a few games (3DMark2001, Call of Duty Modern Warfare) doing stupid buffer / texture mapping calls that forced my command stream code to wait. Your findings may have some answers to why they work better on Windows. Please port this test to ddraw, d3d8, d3d10 and d3d11 as well. I know it's a lot of work, but the APIs might have different behavior for compatibility reasons, and I know at least one ddraw game that requires that we ignore redundant D3DLOCK_DISCARD locks (see commit d3520ef4, bug 32485). Am 2016-07-08 um 17:15 schrieb Patrick Rudolph: > + { > + "D3DLOCK_NOOVERWRITE", > + D3DLOCK_NOOVERWRITE, > + FALSE, > + TRUE, > + TRUE > + }, > + { It seems that this is not true on my Nvidia card: > visual.c:21966: Driver string: "nvd3dum.dll" > visual.c:21967: Description string: "NVIDIA GeForce GT 650M" > visual.c:21970: Device name string: "\\.\DISPLAY1" > visual.c:21972: Driver version 10.18.13.5900 > ... > visual.c:5503: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE. Dynamic = 0. > visual.c:5503: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. If AMD GPUs accept D3DLOCK_NOOVERWRITE on non-dynamic buffers we can pick any behavior in Wine because games can't rely on it on Windows. I'll run the test on AMD GPUs later, currently all my machines with AMD GPUs are in a rather bad shape :-\ . > + hr = IDirect3DDevice9_SetRenderState(device, D3DRS_FOGENABLE, FALSE); > + ok(SUCCEEDED(hr), "Failed to disable fog, hr %#x.\n", hr); This is redundant. > + /* sanity check */ > + hr = IDirect3DDevice9_CreateVertexBuffer(device, sizeof(quad_strip1), 0, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + ok(SUCCEEDED(hr), "Failed to create vertex buffer, hr %#x.\n", hr); Is there any place where this would fail, but the other tests succeed? My sense is that if something as basic as a vertex buffer draw is broken we'd have mass test failures anyway. > + /* Increase triangle draw count for faster GPUs. > + Limit size to 0x40000 as bigger values causes the Nvidia driver to crash. */ As mentioned I'll test this on other machines as well, it might make sense to use a pixel shader that calculates square roots in a loop to slow down the GPU if the current setup is unreliable. > + if (tests[i].dynamic) > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, D3DUSAGE_DYNAMIC, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + else > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, 0, 0, D3DPOOL_DEFAULT, &buffer, NULL); You could store a DWORD of flags in the tests structure and set it either to 0 or D3DUSAGE_DYNAMIC. That way you can avoid the branch and it makes the tests array easier to read IMO. > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, size, (void **)&quad_strip_array, 0); > + ok(SUCCEEDED(hr), "Failed to lock vertex buffer, hr %#x.\n", hr); > + if (!SUCCEEDED(hr) || !quad_strip_array) > + { > + IDirect3DVertexBuffer9_Release(buffer); > + continue; > + } You don't really need the if branch. If the call fails the ok() call will already mean that the test fails, and we don't really care about error handling after that. I.e., if you have a test failure it's no problem if you segfault afterwards. (It would matter if you ok is marked todo_wine or has a broken() clause because it fails in some cases on Windows.) > + ok(hr == D3D_OK, "Failed to set stream source, hr %#x.\n", hr); Please consistently use SUCCEEDED(hr). Yeah, I know the existing code isn't perfect regarding this :-( . > + hr = IDirect3DVertexBuffer9_Lock(buffer, (quads - 1) * sizeof(quad_strip1), sizeof(quad_strip1), (void **)&quad_strip_array, D3DLOCK_READONLY); What is the purpose of the readonly lock here? I think it would be interesting to test how D3DLOCK_READONLY behaves regarding synchronization too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgk0zAAoJEN0/YqbEcdMwDDMP/3lJ/4Uu4hHSy9KWeLz5wDxH mq9cmVCon/34BlPOTAzIvYJ1tEoFnNGrXur5iuYgOuCq/4m8TZA7W10pCYEJ7yYE xS90d2udHsxYBEBoPDXzUff5GFdkRv53AX6IdYc2BmuPN+jA9+j51TxN9qWqYMHK XNV76BDZC8EZ+mQyTov82CsSsn0K3TvhBa/1njDlbUvuNuvuaDm7qzBMqooZycgv AejEiI/dwHPyu0dmAJxHjpEJl5FozdOELJwoRtXFCp2LANnWqCAugKkjD9O1kQsb u0/iKowANpHkP+VS1PkG5dZeIEJjM2lHlopUigwjeBY/SQ/Pdlh2wfJT3HWGKnEo mnACOI4xHGp5XyNX6iit1W5mjRtv0ZiMNaTawjvptTfMM54XopsuMw+hAK+6itLo 7fgccAGUhZo+Uun2p5ceZSr+2+J7q3TUtWlh633m8yW1jz/82jer2soyDoiFw+ap uo3+w8iQ2RUTrmD2kJ7dh0ZSaHeqSh522yi3fExbyyyFQiGd5S1CBaUgrHdnt56Z ciQWEb/hhJyAhLhlbjqJuaYaaozBwXrWCkpX2uRluOoMZFN3H7mi76jtNLys8mOO eQRQrw1j9vuN/vxEz1yg5NQMvV9PImrc1p56HYn2NXMqVptABjhcnyRpNwnB2ar+ PH/xwUDQRY9CTGRkt4dR =d9bG -----END PGP SIGNATURE-----

July 10, 2016

Re: [v2 01/10] webservices: Add support for writing double values.

by Sebastian Lackner

On 08.07.2016 10:20, Hans Leidekker wrote: > v2: Fix build failure. > > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/webservices/reader.c | 8 +-- > dlls/webservices/tests/writer.c | 113 +++++++++++++++++++++++++++++++++ > dlls/webservices/webservices_private.h | 2 + > dlls/webservices/writer.c | 100 +++++++++++++++++++++++++++++ > include/webservices.h | 5 ++ > 5 files changed, 224 insertions(+), 4 deletions(-) > Unfortunately your patch does not work as expected here (gcc 5.3): ../../../tools/runtest -q -P wine -T ../../.. -M webservices.dll -p webservices_test.exe.so writer && touch writer.ok writer.c:358: Test failed: 1941: got 11 expected 10 writer.c:360: Test failed: 1941: got <t>:E-3</t>>000000004</t> expected <t>1E-2</t> writer.c:358: Test failed: 1941: got 12 expected 11 writer.c:360: Test failed: 1941: got <t>-:E-3</t>000000004</t> expected <t>-1E-2</t> Makefile:346: die Regel für Ziel „writer.ok“ scheiterte If you need any details to investigate this issue please let me know. Regards, Sebastian

July 9, 2016

Re: explorerframe/tests: Use SetRect() instead of open coding it.

by Michael Stefaniuc

On 07/09/2016 02:09 PM, Marvin wrote: > 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=24129 > > Your paranoid android. > > > === w7pro64 (64 bit nstc) === > nstc.c:1953: Test failed: Got event 17, count 1 This is a spurious error on Win7 according to the daily test results. For whatever reason it seems to fail more reliable when run standalone as all my 3 patches produced it. bye michael

July 9, 2016

Re: explorerframe/tests: Use EqualRect() instead of open coding it.

by Marvin

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=24131 Your paranoid android. === w7pro64 (32 bit nstc) === nstc.c:1941: Test failed: Got event 17, count 1 === w7pro64 (64 bit nstc) === nstc.c:1951: Test failed: Got event 17, count 1

July 9, 2016

Re: explorerframe/tests: The width is between the RECT left and right fields

by Marvin

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=24130 Your paranoid android. === w7pro64 (64 bit nstc) === nstc.c:1946: Test failed: Got event 17, count 1

July 9, 2016

Re: explorerframe/tests: Use SetRect() instead of open coding it.

by Marvin

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=24129 Your paranoid android. === w7pro64 (64 bit nstc) === nstc.c:1953: Test failed: Got event 17, count 1

July 9, 2016

Re: [PATCH v2 2/3] winex11.drv: avoid passing NULL to memcpy (clang)

by Alexandre Julliard

Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > According to the standard, memcpy() and its friends > should never accept NULL as argument, otherwise > the behavior is undefined and optimizer takes this > into account. > > Below in the same file (line 206) caller passes > NULL as lpComp argument triggering this case. > > This patch is of the same nature as the following: > > commit 5a3ad0ecf08c00fc0b7b2f24e55be27b7c3f5da0 > Author: Kirill Smirnov <kirill.k.smirnov(a)gmail.com> > Date: Mon May 9 18:56:14 2016 +0300 > > winhlp32: Do not pass NULL to strchr() (spotted by clang). strchr has to access the pointer so obviously it can't take NULL, but memcpy with a zero length shouldn't, so it's not very useful compiler behavior IMO. Sadly it seems the standard does allow it... -- Alexandre Julliard julliard(a)winehq.org

July 9, 2016

Re: [PATCH 2/2] wined3d/resource: Performance improvements

by Marvin

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=24126 Your paranoid android. === w8 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (64 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (64 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1.

July 8, 2016

Re: [PATCH 1/2] d3d9/tests/visual: Add Vertexbuffer locking tests

by Marvin

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=24125 Your paranoid android. === w8 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (64 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (64 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1.

July 8, 2016

Re: [PATCH] xmllite/writer: Support trivial case of WriteAttributeString()

by Marvin

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

July 8, 2016

Re: [PATCH 2/2] wscript: Added WScript.Quit tests.

by Marvin

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

July 8, 2016

Re: [PATCH 5/5] d3d11/tests: Add test for immediate constant buffer.

by Marvin

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

July 8, 2016

Re: [PATCH 3/5] d3d10core/tests: Add test for vertex formats.

by Marvin

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

July 8, 2016

Re: [PATCH 2/5] d3d11/tests: Add test for vertex formats.

by Marvin

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

July 8, 2016

Re: [3/3] wininet/tests: Add a test for recently introduced regression related to InternetCrackUrl.

by Marvin

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

July 8, 2016

Re: [2/3] wininet/tests: Avoid unnecessary initialization of variables.

by Marvin

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

July 8, 2016

Re: [1/3] wininet: Correctly set lpszUrlPath in InternetCrackUrlW for urls without path component.

by Marvin

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

July 8, 2016

Re: gdi32: Remove unused function.

by Huw Davies

On Fri, Jul 08, 2016 at 03:58:04PM +0200, Sebastian Lackner wrote: > I assume it was intentional to remove the is_in_rect() check from PtInRegion, but > is it really such a good idea? For points outside of the extents rectangle it > increased runtime from O(1) to O(log N), which could still matter in practice. Good catch. I hadn't meant to remove the extents test which is why I didn't remove is_in_rect() in the original patch. Thanks, Huw.

July 8, 2016

Re: gdi32: Remove unused function.

by Sebastian Lackner

On 08.07.2016 12:25, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/gdi32/region.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/dlls/gdi32/region.c b/dlls/gdi32/region.c > index 0b0ff47..1e10221 100644 > --- a/dlls/gdi32/region.c > +++ b/dlls/gdi32/region.c > @@ -149,11 +149,6 @@ static inline void empty_region( WINEREGION *reg ) > reg->extents.left = reg->extents.top = reg->extents.right = reg->extents.bottom = 0; > } > > -static inline BOOL is_in_rect( const RECT *rect, int x, int y ) > -{ > - return (rect->right > x && rect->left <= x && rect->bottom > y && rect->top <= y); > -} > - > /* > * number of points to buffer before sending them off > * to scanlines() : Must be an even number > I assume it was intentional to remove the is_in_rect() check from PtInRegion, but is it really such a good idea? For points outside of the extents rectangle it increased runtime from O(1) to O(log N), which could still matter in practice.

July 8, 2016

Re: gdi32: Optionally return the type from GDI_GetObjPtr().

by Huw Davies

On Fri, Jul 08, 2016 at 08:28:56PM +0900, Alexandre Julliard wrote: > The performance impact is negligible, but it doesn't make a lot of sense > to return the type when it was already specified by the caller. Some > kind of get_any_obj_ptr(HGDIOBJ, WORD *) function for the any type case > would probably be cleaner. Hmm, ok. Yes, that makes sense. New version sent. Huw.

July 8, 2016

Re: gdi32: Optionally return the type from GDI_GetObjPtr().

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > On Fri, Jul 08, 2016 at 05:24:29PM +0800, Dmitry Timoshkov wrote: >> Huw Davies <huw(a)codeweavers.com> wrote: >> >> > This enables get_dc_obj() to check the type without calling GetObjectType() >> > and thus it saves additional calls to Enter/LeaveCriticalSection(). >> > >> > Signed-off-by: Huw Davies <huw(a)codeweavers.com> >> > --- >> > This reduces the runtime of the dib tests by about 8% and achieves a similar >> > increase in performance with the drawing phase of a (gdi heavy) app I'm >> > looking at. >> ... >> > - bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP ); >> > + bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP, NULL ); >> >> Did you consider introducing GDI_GetObjPtrEx() with additional pointer to >> type, and making a shortcut by defining/calling it by a not Ex version? > > No. > >> That would simplify the patch and avoid penalizing/changing the callers >> that don't need the type. > > We don't don't need to retain backwards compatibility so I don't see > the point, indeed an additional 'Ex' version would be more > confusing IMO. Almost all of the time in that function is spent > grabbing the crit sec, so any time saved by not filling in the out > param is totally negligible. The performance impact is negligible, but it doesn't make a lot of sense to return the type when it was already specified by the caller. Some kind of get_any_obj_ptr(HGDIOBJ, WORD *) function for the any type case would probably be cleaner. -- Alexandre Julliard julliard(a)winehq.org

July 8, 2016

Re: [v3] riched20: Add support for ECO_NOHIDESEL flag

by Huw Davies

On Fri, Jul 08, 2016 at 12:32:55PM +0200, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/riched20/editor.c | 9 +++++++-- > dlls/riched20/paint.c | 6 ++++-- > 2 files changed, 11 insertions(+), 4 deletions(-) > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 13a2857..cb6fe3d 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -3453,14 +3453,15 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > ME_RewrapRepaint(editor); > } > > + if ((changedSettings & settings & ECO_NOHIDESEL) && !editor->bHaveFocus) > + ME_InvalidateSelection( editor ); > + Actually on reflection, I think comparing with ES_NOHIDESEL is slightly less confusing, so let's go with v2. Huw.

July 8, 2016

Re: riched20: Add support for ECO_NOHIDESEL flag

by Huw Davies

On Fri, Jul 08, 2016 at 12:33:41PM +0200, Piotr Caban wrote: > On 07/08/16 12:29, Piotr Caban wrote: > >On 07/08/16 12:11, Huw Davies wrote: > >>I think this, and all subsequent ECO_NOHIDESELs, would be better as > >>ES_NOHIDESEL. > >>The first one is fine as ECO_NOHIDESEL, since that's the setting one. > >I've sent a fixed version. I'm not sure if I have changed it as you wanted. > I guess v3 is what you were asking about. It was, but let's go with v2, on reflection it's a bit less confusing. Huw.

July 8, 2016

Re: riched20: Add support for ECO_NOHIDESEL flag

by Piotr Caban

On 07/08/16 12:29, Piotr Caban wrote: > On 07/08/16 12:11, Huw Davies wrote: >> I think this, and all subsequent ECO_NOHIDESELs, would be better as >> ES_NOHIDESEL. >> The first one is fine as ECO_NOHIDESEL, since that's the setting one. > I've sent a fixed version. I'm not sure if I have changed it as you wanted. I guess v3 is what you were asking about. Thanks, Piotr

July 8, 2016

Re: riched20: Add support for ECO_NOHIDESEL flag

by Piotr Caban

On 07/08/16 12:11, Huw Davies wrote: > I think this, and all subsequent ECO_NOHIDESELs, would be better as ES_NOHIDESEL. > The first one is fine as ECO_NOHIDESEL, since that's the setting one. I've sent a fixed version. I'm not sure if I have changed it as you wanted. Thanks, Piotr

July 8, 2016

Re: riched20: Add support for ECO_NOHIDESEL flag

by Huw Davies

On Fri, Jul 08, 2016 at 11:34:11AM +0200, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > > This patch also fixes control behavior when ECO_NOHIDESEL is not specified > and the control looses focus (for bug 40915). > --- > dlls/riched20/editor.c | 9 +++++++-- > dlls/riched20/paint.c | 6 ++++-- > 2 files changed, 11 insertions(+), 4 deletions(-) > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 13a2857..b7864eb 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -3453,14 +3453,15 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > ME_RewrapRepaint(editor); > } > > + if ((changedSettings & settings & ECO_NOHIDESEL) && !editor->bHaveFocus) > + ME_InvalidateSelection( editor ); > + > if (changedSettings & settings & ECO_VERTICAL) > FIXME("ECO_VERTICAL not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOHSCROLL) > FIXME("ECO_AUTOHSCROLL not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOVSCROLL) > FIXME("ECO_AUTOVSCROLL not implemented yet!\n"); > - if (changedSettings & settings & ECO_NOHIDESEL) > - FIXME("ECO_NOHIDESEL not implemented yet!\n"); > if (changedSettings & settings & ECO_WANTRETURN) > FIXME("ECO_WANTRETURN not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOWORDSELECTION) > @@ -4257,6 +4258,8 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > editor->bHaveFocus = TRUE; > ME_ShowCaret(editor); > ME_SendOldNotify(editor, EN_SETFOCUS); > + if (!editor->bHideSelection && !(editor->styleFlags & ECO_NOHIDESEL)) I think this, and all subsequent ECO_NOHIDESELs, would be better as ES_NOHIDESEL. The first one is fine as ECO_NOHIDESEL, since that's the setting one. Huw.

July 8, 2016

Re: gdi32: Optionally return the type from GDI_GetObjPtr().

by Huw Davies

On Fri, Jul 08, 2016 at 05:24:29PM +0800, Dmitry Timoshkov wrote: > Huw Davies <huw(a)codeweavers.com> wrote: > > > This enables get_dc_obj() to check the type without calling GetObjectType() > > and thus it saves additional calls to Enter/LeaveCriticalSection(). > > > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > > --- > > This reduces the runtime of the dib tests by about 8% and achieves a similar > > increase in performance with the drawing phase of a (gdi heavy) app I'm > > looking at. > ... > > - bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP ); > > + bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP, NULL ); > > Did you consider introducing GDI_GetObjPtrEx() with additional pointer to > type, and making a shortcut by defining/calling it by a not Ex version? No. > That would simplify the patch and avoid penalizing/changing the callers > that don't need the type. We don't don't need to retain backwards compatibility so I don't see the point, indeed an additional 'Ex' version would be more confusing IMO. Almost all of the time in that function is spent grabbing the crit sec, so any time saved by not filling in the out param is totally negligible. Huw.

July 8, 2016

Re: gdi32: Optionally return the type from GDI_GetObjPtr().

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > This enables get_dc_obj() to check the type without calling GetObjectType() > and thus it saves additional calls to Enter/LeaveCriticalSection(). > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > This reduces the runtime of the dib tests by about 8% and achieves a similar > increase in performance with the drawing phase of a (gdi heavy) app I'm > looking at. ... > - bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP ); > + bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP, NULL ); Did you consider introducing GDI_GetObjPtrEx() with additional pointer to type, and making a shortcut by defining/calling it by a not Ex version? That would simplify the patch and avoid penalizing/changing the callers that don't need the type. -- Dmitry.

July 8, 2016

Re: [PATCH 02/12] d3drm: Move d3drm_device struct to d3drm_private.h.

by Aaryaman Vasishta

> > +struct d3drm_device > +{ > + IDirect3DRMDevice IDirect3DRMDevice_iface; > + IDirect3DRMDevice2 IDirect3DRMDevice2_iface; > + IDirect3DRMDevice3 IDirect3DRMDevice3_iface; > + IDirect3DRMWinDevice IDirect3DRMWinDevice_iface; > + IDirect3DRM *d3drm; > + IDirectDraw *ddraw; > + IDirectDrawSurface *primary_surface, *render_target; > + IDirectDrawClipper *clipper; > + IDirect3DDevice *device; > + LONG ref; > + BOOL dither; > + D3DRMRENDERQUALITY quality; > + DWORD rendermode; > + DWORD height; > + DWORD width; > +}; > + > > I should remove the current forward declaration now that this patch moves the definition here.

July 8, 2016

Re: [PATCH 04/12] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback.

by Aaryaman Vasishta

On Thu, Jul 7, 2016 at 7:22 PM, Aaryaman Vasishta <jem456.vasishta(a)gmail.com > wrote: > > @@ -65,6 +65,7 @@ void d3drm_device_destroy(struct d3drm_device *device) > IDirectDraw_Release(device->ddraw); > IDirect3DRM_Release(device->d3drm); > } > + d3drm_object_cleanup((IDirect3DRMObject > *)&device->IDirect3DRMDevice_iface, &device->obj); > HeapFree(GetProcessHeap(), 0, device); > } > I should've probably put d3drm_object_cleanup at the beginning.

July 8, 2016

Re: [PATCH v2 2/3] winex11.drv: avoid passing NULL to memcpy (clang)

by Kirill Smirnov

According to the standard, memcpy() and its friends should never accept NULL as argument, otherwise the behavior is undefined and optimizer takes this into account. Below in the same file (line 206) caller passes NULL as lpComp argument triggering this case. This patch is of the same nature as the following: commit 5a3ad0ecf08c00fc0b7b2f24e55be27b7c3f5da0 Author: Kirill Smirnov <kirill.k.smirnov(a)gmail.com> Date: Mon May 9 18:56:14 2016 +0300 winhlp32: Do not pass NULL to strchr() (spotted by clang). Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> On 08.07.2016 06:16, Alexandre Julliard wrote: > Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > >> @@ -92,7 +92,8 @@ static void X11DRV_ImmSetInternalString(DWORD dwOffset, >> ptr_new = CompositionString + byte_offset; >> memmove(ptr_new + byte_length, ptr_new + byte_selection, >> dwCompStringLength - byte_offset - byte_selection); >> - memcpy(ptr_new, lpComp, byte_length); >> + /* Do not pass NULL even if the length == 0 */ >> + if (lpComp) memcpy(ptr_new, lpComp, byte_length); >> dwCompStringLength += byte_expansion; > > Why would that be a problem? >

July 8, 2016

Re: [PATCH v2 3/3] winex11.drv: fix NULL pointer dereference (clang)

by Alexandre Julliard

Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > @@ -1679,6 +1679,11 @@ static void xrender_put_image( Pixmap src_pixmap, Picture src_pict, Picture mask > } > else > { > + if (!physdev) > + { > + ERR("physdev is NULL\n"); > + return; > + } This should never happen. -- Alexandre Julliard julliard(a)winehq.org

July 7, 2016

Re: [PATCH v2 2/3] winex11.drv: avoid passing NULL to memcpy (clang)

by Alexandre Julliard

Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > @@ -92,7 +92,8 @@ static void X11DRV_ImmSetInternalString(DWORD dwOffset, > ptr_new = CompositionString + byte_offset; > memmove(ptr_new + byte_length, ptr_new + byte_selection, > dwCompStringLength - byte_offset - byte_selection); > - memcpy(ptr_new, lpComp, byte_length); > + /* Do not pass NULL even if the length == 0 */ > + if (lpComp) memcpy(ptr_new, lpComp, byte_length); > dwCompStringLength += byte_expansion; Why would that be a problem? -- Alexandre Julliard julliard(a)winehq.org

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Sebastian Lackner

On 08.07.2016 03:05, flan wrote: > On Fri, Jul 08, 2016 at 01:17:01AM +0200, Sebastian Lackner wrote: >> I'm not the maintainer of this component, but Alex is right that you >> will have to use your real name (both as author and also in the >> Signed-off-by message). >> >> I also believe that the variable names link_bno1W and link_bno1_str >> are chosen a bit badly. The 1 does not really make any sense, and instead >> of "bno" it might be better to use the same abbreviation "basenamed" as >> above. If you make any changes, please also adjust the whitespace >> inbetween of the variable name and "=" to match the surrounding code. >> >> If \\Sessions\\1 contains all the elements from \\, you could also >> think about symlinking it to root (instead of symlinking each component >> separately). >> >> Regards, >> Sebastian >> > > Thank you for the feedback, I'll change variable names and adjust the > whitespace. \\Sessions\\1 does not seem to contain all elements from \\. The > only element besides BaseNamedObjects that's both in \\ and \\Sessions\\1 > seems to be \\Windows and its child directory, WindowStations. Okay, then the current approach should be fine. > > Is there any particular reason behind the real name requirement? > For the Wine project it is very important to make sure that all developers are trustworthy and that they do not violate any laws, for example by disassembling or looking at original Microsoft code. You can find more about the requirements and guidelines on the following pages: https://wiki.winehq.org/Submitting_Patches https://wiki.winehq.org/Clean_Room_Guidelines Although your patch is just a simple fix, for reasons of simplicity the rules are the same for all kind of submissions.

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by flan

On Fri, Jul 08, 2016 at 01:17:01AM +0200, Sebastian Lackner wrote: > I'm not the maintainer of this component, but Alex is right that you > will have to use your real name (both as author and also in the > Signed-off-by message). > > I also believe that the variable names link_bno1W and link_bno1_str > are chosen a bit badly. The 1 does not really make any sense, and instead > of "bno" it might be better to use the same abbreviation "basenamed" as > above. If you make any changes, please also adjust the whitespace > inbetween of the variable name and "=" to match the surrounding code. > > If \\Sessions\\1 contains all the elements from \\, you could also > think about symlinking it to root (instead of symlinking each component > separately). > > Regards, > Sebastian > Thank you for the feedback, I'll change variable names and adjust the whitespace. \\Sessions\\1 does not seem to contain all elements from \\. The only element besides BaseNamedObjects that's both in \\ and \\Sessions\\1 seems to be \\Windows and its child directory, WindowStations. Is there any particular reason behind the real name requirement?

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Alex Henrie

2016-07-07 17:31 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: > On 08.07.2016 01:29, Alex Henrie wrote: >> 2016-07-07 17:17 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: >>> I'm not the maintainer of this component >> >> MAINTAINERS seems to say that you're in charge of everything under >> server/ - if that's not the case, it should be updated to be more >> specific. > > I fear you are mixing up the meaning of M and P. ;) > > M: Primary maintainer. CC patches to: FullName <address(a)domain> > P: Other knowledgeable person. FullName <address(a)domain> You're right, sorry. I'll pay more attention to that in the future. -Alex

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Sebastian Lackner

On 08.07.2016 01:29, Alex Henrie wrote: > 2016-07-07 17:17 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: >> I'm not the maintainer of this component > > MAINTAINERS seems to say that you're in charge of everything under > server/ - if that's not the case, it should be updated to be more > specific. I fear you are mixing up the meaning of M and P. ;) M: Primary maintainer. CC patches to: FullName <address(a)domain> P: Other knowledgeable person. FullName <address(a)domain> > > Thanks for giving Flan some suggestions. > > -Alex >

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Alex Henrie

2016-07-07 17:17 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: > I'm not the maintainer of this component MAINTAINERS seems to say that you're in charge of everything under server/ - if that's not the case, it should be updated to be more specific. Thanks for giving Flan some suggestions. -Alex

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Sebastian Lackner

On 07.07.2016 23:59, Alex Henrie wrote: > Hi Flan, > > Thanks for your interest in contributing to Wine. The Wine project > requires you to use your real name (both first and last name) when > submitting patches. It might also be a good idea to contact Sebastian > Lackner, who is listed as a maintainer of this part of Wine. He might > be able to give you more specific feedback, or he might decide to > include your patch in Wine Staging to test it with a wider audience. > > -Alex > I'm not the maintainer of this component, but Alex is right that you will have to use your real name (both as author and also in the Signed-off-by message). I also believe that the variable names link_bno1W and link_bno1_str are chosen a bit badly. The 1 does not really make any sense, and instead of "bno" it might be better to use the same abbreviation "basenamed" as above. If you make any changes, please also adjust the whitespace inbetween of the variable name and "=" to match the surrounding code. If \\Sessions\\1 contains all the elements from \\, you could also think about symlinking it to root (instead of symlinking each component separately). Regards, Sebastian

July 7, 2016

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

by Ken Thomases

On Apr 26, 2016, at 3:38 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > On 26.04.2016 22:35, Theodore Dubois wrote: >> I have both a custom wine loader and a hacked version of Wine, so I just reverted the patch. >> >> It would be really nice to have this work for when I’m not using a custom loader. Maybe you could check if argv is in the malloc heap? Or maybe I could somehow indicate when calling wine_init that the argv is malloced? >> >> ~Theodore >> > > May I ask why you are not just allocating the argv array in a way compatible to the OS? > When you have full control in your custom loader, this should be trivial and the easiest > way to fix it. Forgive me for reviving an old thread, but how was it determined that allocating all of the strings pointed to by argv as a single buffer is what the OS does? This does not seem like a portable assumption. Also, why should set_process_name() shift the strings up within the (supposedly contiguous) string buffer? For the HAVE_SETPROCTITLE, it doesn't do that. Prior to Chip's commit, it didn't do that on macOS. So, Theodore's original question, "Why wouldn’t setprogname(argv[1]) be adequate?", is pretty close. It should have been, "Why wouldn’t setprogname(argv[1]) followed by shifting the elements of argv up one be adequate?" I'm not even sure why the string buffer is shifted for Linux. It looks like it's leftover logic that's no longer relevant (having to do with vdm?). I'll also note that Chip's commit broke things for the case where none of HAVE_SETPROCTITLE, HAVE_SETPROGNAME, or HAVE_PRCTL is defined. In that case, nothing shifts the elements of argv up one anymore. It used to. -Ken

July 7, 2016

Re: [PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by Alex Henrie

Hi Flan, Thanks for your interest in contributing to Wine. The Wine project requires you to use your real name (both first and last name) when submitting patches. It might also be a good idea to contact Sebastian Lackner, who is listed as a maintainer of this part of Wine. He might be able to give you more specific feedback, or he might decide to include your patch in Wine Staging to test it with a wider audience. -Alex

July 7, 2016

[PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by flan

What is wrong with the patch? Right now the most glaring formatting issue I can find is inconsistent spacing in a variable declaration, but I'm asking just in case there are more problems I haven't noticed.

July 7, 2016

[PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.

by flan

What is wrong with the patch? Right now the most glaring formatting issue I can find is inconsistent spacing in a variable declaration, but I'm asking just in case there are more problems I haven't noticed.

July 7, 2016

Re: [PATCH 01/12] d3drm: Store reference to IDirect3DRM in struct d3drm_device.

by Aaryaman Vasishta

The end of the subject should have "d3drm_device_create" instead of "struct d3drm_device". On Thu, Jul 7, 2016 at 8:18 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 "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

July 7, 2016

Re: [PATCH] wininet: fix the bug can not save proxy bypass server into regedit by ie internet options dialog

by Alex Henrie

Hi huangxuewei, Thanks for your interest in contributing to Wine! The Wine project requires you to use your real name (with capitalization and spaces) when submitting patches. It would also help to link to a bug report in the patch email, and to add tests to demonstrate that the behavior you want is the correct behavior. -Alex

July 7, 2016

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4)

by Marvin

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=24060 Your paranoid android. === wvistau64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). sock: unhandled exception c0000005 at 00000000 === w7u (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w8 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === wvistau64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well).

July 7, 2016

Re: [PATCH 3/3] mshtml: Export IElementSelector for all elements in compatibility mode >= IE8.

by Marvin

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

July 7, 2016

Re: [10/10] webservices: Implement WsWriteBody.

by Marvin

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

July 7, 2016

Re: [09/10] webservices: Implement WsWriteEnvelopeEnd.

by Marvin

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

July 7, 2016

Re: [08/10] webservices: Implement WsWriteEnvelopeStart.

by Marvin

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

July 7, 2016

Re: [07/10] webservices: Implement WsAddressMessage.

by Marvin

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

July 7, 2016

Re: [06/10] webservices: Implement WsInitializeMessage.

by Marvin

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

July 7, 2016

Re: [05/10] webservices: Implement WsCreateMessageForChannel.

by Marvin

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

July 7, 2016

Re: [03/10] webservices: Allow integer values to be passed by pointer in WsWriteType.

by Marvin

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

July 7, 2016

Re: [02/10] webservices: Inherit the prefix only if parent and child namespaces match.

by Marvin

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

July 7, 2016

Re: [01/10] webservices: Add support for writing double values.

by Marvin

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

July 7, 2016

Re: [PATCH v3 6/6] shell32: Set output interfaces to NULL in FolderItems functions.

by Alex Henrie

2016-07-06 11:39 GMT-06:00 Alex Henrie <alexhenrie24(a)gmail.com>: > 2016-07-06 1:13 GMT-06:00 Michael Stefaniuc <mstefani(a)redhat.com>: >> On 07/06/2016 06:55 AM, Alex Henrie wrote: >>> [...] >> >> This two if's look odd: one for ppid and then for !ppid. >> Why don't you just unconditionally do the NULL assignment after the >> check below? >> >>> if (!ppid) >>> return E_INVALIDARG; > > Thanks for catching that. This is a mistake, according to the tests > get_Parent should never return E_INVALIDARG. The only difference between v3 and v4 of the patchset is the removal of these two lines from FolderItemsImpl_get_Parent. -Alex

July 7, 2016

Re: [2/2] kernel32/tests: Add a test for sorting of InMemoryOrderModuleList.

by Sebastian Lackner

On 07.07.2016 06:54, Marvin wrote: > 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=24042 > > Your paranoid android. > > > === w7u (32 bit loader) === > loader.c:2308: Test failed: WaitForSingleObject failed: 102 > loader.c:2310: Test failed: expected exit code 199, got 259 > loader.c:2329: Test failed: expected 198, got 199 > > === w1064 (32 bit loader) === > loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 0: expected 74374550, got 00000000 > loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 1: expected 72BC2CF0, got 00000000 > loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 2: expected 74372DC0, got 00000000 > loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 > loader.c:2742: Test failed: Test 3: Wrong callback count: 0 > loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 > loader.c:2742: Test failed: Test 4: Wrong callback count: 0 > loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 > loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 > > === w864 (64 bit loader) === > loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 > loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 > > === w1064 (64 bit loader) === > loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 0: expected 00007FFC76DA5510, got 0000000000000000 > loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 1: expected 00007FFC6EFE1B00, got 0000000000000000 > loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed > loader.c:2734: Test failed: Test 2: expected 00007FFC76DA2390, got 0000000000000000 > loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 0000000000000000 > loader.c:2742: Test failed: Test 3: Wrong callback count: 0 > loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 0000000000000000 > loader.c:2742: Test failed: Test 4: Wrong callback count: 0 > loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 > loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 > These are all existing failures.

July 6, 2016

Re: [2/2] kernel32/tests: Add a test for sorting of InMemoryOrderModuleList.

by Marvin

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=24042 Your paranoid android. === w7u (32 bit loader) === loader.c:2308: Test failed: WaitForSingleObject failed: 102 loader.c:2310: Test failed: expected exit code 199, got 259 loader.c:2329: Test failed: expected 198, got 199 === w1064 (32 bit loader) === loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2742: Test failed: Test 3: Wrong callback count: 0 loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2742: Test failed: Test 4: Wrong callback count: 0 loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w864 (64 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w1064 (64 bit loader) === loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 0: expected 00007FFC76DA5510, got 0000000000000000 loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 1: expected 00007FFC6EFE1B00, got 0000000000000000 loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 2: expected 00007FFC76DA2390, got 0000000000000000 loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2742: Test failed: Test 3: Wrong callback count: 0 loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2742: Test failed: Test 4: Wrong callback count: 0 loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195

July 6, 2016

Re: [PATCH 1/3] kernel32/tests/fiber: Add tests for fiber-local storage.

by John Sheu

Thanks! I'm interested in using fiber-local storage, particularly for the callback behavior (which is not implemented right now). The Tls* API in Windows does not support this. This is for the purposes of better thread-local storage for the Ion library: see https://github.com/google/ion On Sat, Jul 2, 2016 at 7:55 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > Am 02.07.2016 um 04:41 schrieb John Sheu: >> Signed-off-by: John Sheu <sheu(a)google.com> > > Hi and welcome to Wine development! > May I ask if you could name an application which will benefit from your fixes? > Your tests currently fail on our testbot as you can see here: https://source.winehq.org/patches/ > Some inline comments: > >> static VOID WINAPI FiberMainProc(LPVOID lpFiberParameter) >> { >> BYTE *tparam = (BYTE *)lpFiberParameter; >> - cbCount++; >> + fiberCount++; >> ok(*tparam == 185, "Parameterdata expected not to be changed\n"); >> + if (fls_index_to_set != FLS_OUT_OF_INDEXES) >> + { >> + if (!pFlsSetValue || !pFlsGetValue) >> + { >> + win_skip( "Fiber Local Storage not supported\n" ); >> + } >> + else >> + { >> + PVOID pret; >> + BOOL bret; >> + >> + pret = FlsGetValue(fls_index_to_set); >> + ok(pret == NULL, "FlsGetValue returned %p, expected NULL\n", pret); >> + >> + /* Set the FLS value */ >> + SetLastError( 0xdeadbeef ); >> + bret = pFlsSetValue(fls_index_to_set, fls_value_to_set); >> + ok(bret, "FlsSetValue failed with error %u\n", GetLastError()); >> + >> + /* Verify that FlsGetValue retrieves the value set by FlsSetValue */ >> + SetLastError( 0xdeadbeef ); >> + pret = FlsGetValue(fls_index_to_set); >> + ok(pret == fls_value_to_set, >> + "FlsGetValue returned %p, expected %p\n", pret, fls_value_to_set); >> + ok(GetLastError() == ERROR_SUCCESS, >> + "FlsGetValue error %u\n", GetLastError()); >> + } >> + } >> pSwitchToFiber(fibers[0]); >> } > > You are mixing tabs and spaces in FiberMainProc, spaces are preferred. Further you can avoid some line brakes in ok() calls, only wrap at around 100 > >> +static void test_FiberLocalStorageWithFibers(PFLS_CALLBACK_FUNCTION cbfunc) { >> + PVOID val1 = (PVOID) 0x314; >> + PVOID val2 = (PVOID) 0x152; >> + BOOL ret; >> + >> + if (!pConvertThreadToFiber || !pSwitchToFiber || !pDeleteFiber) >> + { >> + win_skip( "Fibers not supported\n" ); >> + return; >> + } >> + if (!pFlsAlloc || !pFlsFree || !pFlsSetValue || !pFlsGetValue) >> + { >> + win_skip( "Fiber Local Storage not supported\n" ); >> + return; >> + } >> + >> + >> + fls_index_to_set = pFlsAlloc(cbfunc); >> + ok(fls_index_to_set != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); >> + >> + fiberCount = 0; >> + cbCount = 0; >> + fibers[0] = pConvertThreadToFiber(&testparam); > > Why do you convert the current thread into a fiber? It seems to me that is causing the crash on w2k3. > You could try to run that test in a seperate thread > >> + fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); >> + fibers[2] = pCreateFiber(0,FiberMainProc,&testparam); >> + ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); >> + ok(fibers[2] != 0, "CreateFiber failed with error %d\n", GetLastError()); >> + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); >> + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); >> + >> + fiberCount = 0; >> + cbCount = 0; >> + fls_value_to_set = val1; >> + pSwitchToFiber(fibers[1]); >> + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); >> + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); >> + >> + fiberCount = 0; >> + cbCount = 0; >> + fls_value_to_set = val2; >> + pSwitchToFiber(fibers[2]); >> + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); >> + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); >> + >> + fls_value_to_set = val2; >> + ret = pFlsSetValue(fls_index_to_set, fls_value_to_set); >> + ok(ret, "FlsSetValue failed\n"); >> + ok(val2 == pFlsGetValue(fls_index_to_set), "FlsGetValue failed\n"); >> + >> + fiberCount = 0; >> + cbCount = 0; >> + fls_value_to_set = val1; >> + pDeleteFiber(fibers[1]); >> + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); >> + todo_wine >> + { >> + ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); >> + } > > You can make that a one liner: > todo_wine ok(); > > > > > Hope that helps > Have fun!

July 6, 2016

Re: [PATCH v3 6/6] shell32: Set output interfaces to NULL in FolderItems functions.

by Alex Henrie

2016-07-06 1:13 GMT-06:00 Michael Stefaniuc <mstefani(a)redhat.com>: > On 07/06/2016 06:55 AM, Alex Henrie wrote: >> [...] > > This two if's look odd: one for ppid and then for !ppid. > Why don't you just unconditionally do the NULL assignment after the > check below? > >> if (!ppid) >> return E_INVALIDARG; Thanks for catching that. This is a mistake, according to the tests get_Parent should never return E_INVALIDARG. -Alex

July 6, 2016

Ubuntu considering dropping 32-bit libraries

by Josh DuBois

A Slashdot post yesterday pointed to a worrying thread on the Ubuntu mailing list archive about dropping 32-bit support from Ubuntu. The Ubuntu thread is here: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html It is not 100% clear to me what they are considering - they mention dropping 32-bit .isos and also ceasing to support users who want to run 32-bit apps (at least unless the app is packaged in a container alongside all of the necessary libraries). Their thought is to do this in a couple of years, with Ubuntu 18.10: 18.10+: * Stop providing i386 port * Run legacy i386 only application in snaps / containers / virtual machines Disturbingly, no one on the Ubuntu thread ever mentions Wine. Oddly there is discussion about IoT applications which might need 32-bit libraries and a proposal to continue building select libs for those things, but maybe minus the graphics stack :-(. In the Slashdot post someone at least mentions Wine, but the little discussion that prompted was seemingly in error until Francois came along to correct them. I think Wine should be aware of the issue and make some noise about it before distros grow attached to the idea of ceasing to build 32-bit libraries. I will probably post to the Ubuntu thread to at least mention Wine, unless someone here is involved in that community and thinks they can do a better job. The more distros hear from the Wine community about the value of 32-bit libraries, the better. It might be that they will conclude on their own that users need them to continue building 32-bit libraries, but I don't know that we can trust distros not to break things if we don't speak up.

July 6, 2016

Re: [PATCH 3/3] wininet: Added semi-stub INTERNET_OPTION_END_BROWSER_SESSION implementation.

by Marvin

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=24024 Your paranoid android. === w7u (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w8 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14

July 6, 2016

Re: [PATCH 2/3] wininet: Always set returned size in InternetGetCookieExA.

by Marvin

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=24023 Your paranoid android. === w7u (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w8 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14

July 6, 2016

Re: [PATCH 1/6] wined3d: Implement d3d11_immediate_context_Begin().

by Józef Kucia

On Wed, Jul 6, 2016 at 12:02 PM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d11/async.c | 5 +++++ > dlls/d3d11/d3d11_private.h | 1 + > dlls/d3d11/device.c | 10 +++++++++- > 3 files changed, 15 insertions(+), 1 deletion(-) The subject prefix should be "d3d11".

July 6, 2016

Re: [PATCH] explorer: add registry support to disable Virtual Desktop systray

by Alexandre Julliard

Rob Walker <bob.mt.wya(a)gmail.com> writes: > Workaround for https://bugs.winehq.org/show_bug.cgi?id=40828 A better approach would be to detect the fullscreen window and automatically hide the taskbar. -- Alexandre Julliard julliard(a)winehq.org

July 6, 2016

Re: [PATCH v3 6/6] shell32: Set output interfaces to NULL in FolderItems functions.

by Michael Stefaniuc

On 07/06/2016 06:55 AM, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 9 ++++++++- > dlls/shell32/tests/shelldispatch.c | 3 --- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index 6d7973e..2705389 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -1063,12 +1063,16 @@ static HRESULT WINAPI FolderItemsImpl_get_Application(FolderItems3 *iface, IDisp > if (!ppid) > return E_INVALIDARG; > > + *ppid = NULL; > return E_NOTIMPL; > } > > static HRESULT WINAPI FolderItemsImpl_get_Parent(FolderItems3 *iface, IDispatch **ppid) > { > - FIXME("(%p,%p)\n", iface, ppid); > + TRACE("(%p,%p)\n", iface, ppid); > + > + if (ppid) > + *ppid = NULL; This two if's look odd: one for ppid and then for !ppid. Why don't you just unconditionally do the NULL assignment after the check below? > if (!ppid) > return E_INVALIDARG; bye michael

July 6, 2016

Re: [PATCH v2 1/3] comdlg32: Init clipboard format only once in filedlg.

by Alexandre Julliard

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > @@ -3798,6 +3789,25 @@ static void COMCTL32_ReleaseStgMedium (STGMEDIUM medium) > } > > /*********************************************************************** > + * GetFormatEtc > + * > + * Get the FORMATETC used in the shell id list > + */ > +static FORMATETC* GetFormatEtc(void) > +{ > + static FORMATETC formatetc; > + if (!formatetc.cfFormat) > + { > + formatetc.cfFormat = RegisterClipboardFormatA(CFSTR_SHELLIDLISTA); > + formatetc.ptd = 0; > + formatetc.dwAspect = DVASPECT_CONTENT; > + formatetc.lindex = -1; > + formatetc.tymed = TYMED_HGLOBAL; > + } > + return &formatetc; > +} This looks a little risky, since the structure is passed to the application. Caching only the clipboard format should be enough. -- Alexandre Julliard julliard(a)winehq.org

July 6, 2016

Re: [PATCH] explorer: add registry support to disable Virtual Desktop systray

by Alex Henrie

+ if (using_root) + { + enable_shell = FALSE; + initialize_systray( graphics_driver, using_root, enable_shell ); + } + else + { + enable_systray=get_default_systray_state(); + initialize_systray( graphics_driver, !enable_systray, enable_shell ); + } I think you should put the same whitespace around the equals sign in both cases. -Alex

July 6, 2016

Re: [1/3] imm32, user32: Create and destroy the default IME window implicitly. (try 8)

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 8: > - Fix user32 test failures. To achieve this, we create the default IME window > as message-only window for now. This doesn't match Windows behavior, as the tests show: ../../../tools/runtest -q -P wine -T ../../.. -M imm32.dll -p imm32_test.exe.so imm32 && touch imm32.ok imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x30066 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:994: Test failed: Expected IME window existence imm32.c:996: Test failed: Expected (nil), got 0x50066 imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x60066 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:994: Test failed: Expected IME window existence imm32.c:996: Test failed: Expected (nil), got 0x80066 imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0xb005e imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x20040 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence make: *** [imm32.ok] Error 40 -- Alexandre Julliard julliard(a)winehq.org

July 6, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace().

by Zebediah Figura

On 07/03/2016 02:38 AM, GOUJON Alexandre wrote: > On 07/02/2016 10:57 PM, Zebediah Figura wrote: >> On 07/02/2016 07:47 AM, Marvin wrote: >>> 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=23920 >>> >>> Your paranoid android. >>> >>> >>> === wxppro (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w2003std (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === wvistau64 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w2008s64 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w7u (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w7pro64 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w8 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w864 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> === w1064 (32 bit eventlog) === >>> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >>> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >>> eventlog.c:1272: Test failed: Expected success >>> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >>> >>> >> This test is failing when built 32 bits, but I tried building both >> 64-bit and 32-bit executables using mingw-w64 on my win7 machine, and >> they both worked. I'm a newbie (this is my first patch), so I'm probably >> doing something wrong, but I don't know what. The error in question (87) >> is probably associated with the wrong sizeof() being returned, but I >> don't know why that would happen. >> >> Thanks, >> Zeb > Welcome to wine ! > > Nothing really wrong at a first look but we can nitpick (inconsistent > formatting, PFOO usage instead of FOO *, etc.). > Returned error may depend on Windows version, installed Service Pack, > dll version, structure version... > To broaden your tests, you can use the test bot > (https://wiki.winehq.org/Wine_TestBot) > > In your case, it may be an alignment issue (see > http://stackoverflow.com/questions/9049971/windows-etw-starttrace-failing-w…) > > I tried fixing the alignment issue by padding, but this raised ERROR_BAD_PATHNAME instead. I can't figure out why. I checked using gdb, and LogFileNameOffset points to a valid pathname, and the other apparent condition (LogFileMode = 0) is not met. I can't figure out why this error is being raised.

July 5, 2016

Re: [PATCH 3/3] regedit: Process the next file, if any, on error (v2)

by Hugh McMaster

On Wednesday, 6 July 2016 12:09 AM, Sebastian Lackner wrote: >On 05.07.2016 11:13, Hugh McMaster wrote: >> @@ -113,7 +113,9 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) >> if (size == 0) >> { >> output_message(STRING_FILE_NOT_FOUND, filename); >> - exit(1); >> + if (realname) >> + HeapFree(GetProcessHeap(), 0, realname); > > I haven't reviewed the whole series, but passing a NULL pointer to HeapFree() > is perfectly fine, and its better to avoid such checks. Okay, thanks for pointing that out. Alexandre has already fixed this in both places (see http://source.winehq.org/git/wine.git/commitdiff/6ad44d7a3190d8e9a3daa9bd72…) so no action is necessary. Thanks for the review.

July 5, 2016

[v3] secur32 : add and fix some algids

by Max Qian

On 2016-07-05 5:55 am, Jacek Caban wrote: > Hi Max, > > On 03.07.2016 23:41, Max Qian wrote: >> diff --git a/include/wincrypt.h b/include/wincrypt.h >> index 55c9509..19af6ca 100644 >> --- a/include/wincrypt.h >> +++ b/include/wincrypt.h >> @@ -1583,6 +1583,7 @@ typedef const CERT_CRL_CONTEXT_PAIR >> *PCCERT_CRL_CONTEXT_PAIR; >> #define ALG_SID_AGREED_KEY_ANY 3 >> #define ALG_SID_KEA 4 >> #define ALG_SID_ECDH 5 >> +#define ALG_SID_ECDH_EPHEM 6 >> /* RC2 SIDs */ >> #define ALG_SID_RC4 1 >> #define ALG_SID_RC2 2 >> @@ -1639,6 +1640,7 @@ typedef const CERT_CRL_CONTEXT_PAIR >> *PCCERT_CRL_CONTEXT_PAIR; >> #define CALG_KEA_KEYX (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_DH | ALG_SID_KEA) >> #define CALG_HUGHES_MD5 (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_ANY | ALG_SID_MD5) >> #define CALG_ECDH (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_DH | ALG_SID_ECDH) >> +#define CALG_ECDH_EPHEM (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_DH | ALG_SID_ECDH_EPHEM) >> #define CALG_RSA_KEYX (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_RSA | ALG_SID_RSA_ANY) >> #define CALG_ECMQV (ALG_CLASS_KEY_EXCHANGE | >> ALG_TYPE_ANY | ALG_SID_ECMQV) >> #define CALG_DES (ALG_CLASS_DATA_ENCRYPT | >> ALG_TYPE_BLOCK | ALG_SID_DES) > > Do you have a version of PSDK that has this definition? I can't see it > here. If those are not in MS headers, we shouldn't have them unless we > have a strong reason. When I asked you about adding a comment, I was > hoping for something like > > /* MSDN mentions CALG_ECDH_EPHEM, but it's not available in headers. */ > case ....: return CALG_ECDH; > > Thanks, > Jacek For v3 I replaced CALG_ECDH_EPHEM with a comment in the header file, because both backends have locations where CALG_ECDH_EPHEM could be used. I thought you meant that CALG_ECDH_EPHEM wasn't in the Wine header files, whoops.

July 5, 2016

Re: [PATCH 02/15] mshtml: Rewrite navigation tests using new HTTP emulation framework.

by Jacek Caban

On 7/5/16 10:51 PM, Marvin wrote: > 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=24000 > > Your paranoid android. > > > === build (build) === > Make failed It looks like testbot is missing make depend step. Jacek

July 5, 2016

Re: [PATCH 14/15] mshtml: Reimplement IHTMLDocument5::get_compatMode based on document mode.

by Marvin

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

July 5, 2016

Re: [PATCH 13/15] mshtml: Added document.documentMode tests.

by Marvin

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

July 5, 2016

Re: [PATCH 02/15] mshtml: Rewrite navigation tests using new HTTP emulation framework.

by Marvin

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

July 5, 2016

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)

by Bruno Jesus

On Tue, Jul 5, 2016 at 10:33 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. It still looks like there is a formatting problem with the patch, please attach it in a new attempt or use git send-email, also see the comments below. > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++------------- > dlls/ws2_32/tests/sock.c | 51 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 59 insertions(+), 14 deletions(-) > > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY ((LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } If the ok() is supposed to always fail use ok(0, ...). But according to msdn this option is not present in 2003/XP, so you would end up with an error. Better to use win_skip then to avoid this problem. The testbot will test against many different Windows versions so we need to ensure it works everywhere, before resending it would be useful to do a manual run at https://testbot.winehq.org/ to check the patch. > + ok(enabled == 1, "IPV6_V6ONLY is not enabled by default.\n"); > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } This should never fail as the previous test already took care of checking for IPV6_V6ONLY support, so drop the if and goto. > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } Again I think getsockopt must always work at this point. > + ok(!enabled, "IPV6_V6ONLY is enabled after bind.\n"); > + v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); > + if (v4 == INVALID_SOCKET) { > + skip("Could not create IPv4 socket (LastError: %d).\n", > + WSAGetLastError()); > + goto end; > + } > + WSASetLastError(0xdeadbeef); > + ret = bind(v4, (struct sockaddr*)&sin4, sizeof(sin4)); Please also test ok(ret,...); Best wishes, Bruno

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Nikolay Sivov

On 05.07.2016 20:04, Alex Henrie wrote: > 2016-07-05 10:59 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 05.07.2016 19:56, Alex Henrie wrote: >>> 2016-07-05 10:54 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>>> On 05.07.2016 18:46, Alex Henrie wrote: >>>>> 2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>>> On 05.07.2016 8:47, Alex Henrie wrote: >>>>>>> + if (0) /* crashes on all versions of Windows */ >>>>>>> + { >>>>>>> + r = FolderItems_get_Count(items, NULL); >>>>>>> +todo_wine >>>>>>> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >>>>>>> + } >>>>>> >>>>>> Why do you want to handle this case if it crashes consistently on >>>>>> Windows? And todo_wine is not going to do anything in commented block >>>>>> obviously. >>>>> >>>>> Good point. Would you like me to remove this code altogether, or just >>>>> the todo_wine and ok statement? Also, would you like me to change the >>>>> other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid >>>>> having todo_wine's in if (0) blocks? >>>> >>>> If it crashes on some windows versions just put it in 'if (0)' with >>>> appropriate comment for documentation purposes, and a NULL check could >>>> be implemented. Version 5,1 means XP, right? if it does not crash since >>>> XP just make it a regular test, enabled unconditionally. >>> >>> It crashes on XP, and I'm pretty sure that it's not OK to have tests >>> that crash the XP testbot. I'll remove the todo_wine's though. >> >> Ah, right, it was a greater-than check. So yes, if it only crashes on >> XP, and works on everything newer we should implement newer behavior and >> have disabled test that documents all that. No need for todo_wine. > > And you don't want any if (0) blocks that crash on all versions of > Windows, right? I usually add them, but I don't think it's a strict requirement. > > -Alex >

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Alex Henrie

2016-07-05 10:59 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: > On 05.07.2016 19:56, Alex Henrie wrote: >> 2016-07-05 10:54 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>> On 05.07.2016 18:46, Alex Henrie wrote: >>>> 2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>> On 05.07.2016 8:47, Alex Henrie wrote: >>>>>> + if (0) /* crashes on all versions of Windows */ >>>>>> + { >>>>>> + r = FolderItems_get_Count(items, NULL); >>>>>> +todo_wine >>>>>> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >>>>>> + } >>>>> >>>>> Why do you want to handle this case if it crashes consistently on >>>>> Windows? And todo_wine is not going to do anything in commented block >>>>> obviously. >>>> >>>> Good point. Would you like me to remove this code altogether, or just >>>> the todo_wine and ok statement? Also, would you like me to change the >>>> other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid >>>> having todo_wine's in if (0) blocks? >>> >>> If it crashes on some windows versions just put it in 'if (0)' with >>> appropriate comment for documentation purposes, and a NULL check could >>> be implemented. Version 5,1 means XP, right? if it does not crash since >>> XP just make it a regular test, enabled unconditionally. >> >> It crashes on XP, and I'm pretty sure that it's not OK to have tests >> that crash the XP testbot. I'll remove the todo_wine's though. > > Ah, right, it was a greater-than check. So yes, if it only crashes on > XP, and works on everything newer we should implement newer behavior and > have disabled test that documents all that. No need for todo_wine. And you don't want any if (0) blocks that crash on all versions of Windows, right? -Alex

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Nikolay Sivov

On 05.07.2016 19:56, Alex Henrie wrote: > 2016-07-05 10:54 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 05.07.2016 18:46, Alex Henrie wrote: >>> 2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>>> On 05.07.2016 8:47, Alex Henrie wrote: >>>>> + if (0) /* crashes on all versions of Windows */ >>>>> + { >>>>> + r = FolderItems_get_Count(items, NULL); >>>>> +todo_wine >>>>> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >>>>> + } >>>> >>>> Why do you want to handle this case if it crashes consistently on >>>> Windows? And todo_wine is not going to do anything in commented block >>>> obviously. >>> >>> Good point. Would you like me to remove this code altogether, or just >>> the todo_wine and ok statement? Also, would you like me to change the >>> other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid >>> having todo_wine's in if (0) blocks? >> >> If it crashes on some windows versions just put it in 'if (0)' with >> appropriate comment for documentation purposes, and a NULL check could >> be implemented. Version 5,1 means XP, right? if it does not crash since >> XP just make it a regular test, enabled unconditionally. > > It crashes on XP, and I'm pretty sure that it's not OK to have tests > that crash the XP testbot. I'll remove the todo_wine's though. Ah, right, it was a greater-than check. So yes, if it only crashes on XP, and works on everything newer we should implement newer behavior and have disabled test that documents all that. No need for todo_wine. > > -Alex >

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Alex Henrie

2016-07-05 10:54 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: > On 05.07.2016 18:46, Alex Henrie wrote: >> 2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>> On 05.07.2016 8:47, Alex Henrie wrote: >>>> + if (0) /* crashes on all versions of Windows */ >>>> + { >>>> + r = FolderItems_get_Count(items, NULL); >>>> +todo_wine >>>> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >>>> + } >>> >>> Why do you want to handle this case if it crashes consistently on >>> Windows? And todo_wine is not going to do anything in commented block >>> obviously. >> >> Good point. Would you like me to remove this code altogether, or just >> the todo_wine and ok statement? Also, would you like me to change the >> other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid >> having todo_wine's in if (0) blocks? > > If it crashes on some windows versions just put it in 'if (0)' with > appropriate comment for documentation purposes, and a NULL check could > be implemented. Version 5,1 means XP, right? if it does not crash since > XP just make it a regular test, enabled unconditionally. It crashes on XP, and I'm pretty sure that it's not OK to have tests that crash the XP testbot. I'll remove the todo_wine's though. -Alex

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Nikolay Sivov

On 05.07.2016 18:46, Alex Henrie wrote: > 2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> On 05.07.2016 8:47, Alex Henrie wrote: >>> + if (0) /* crashes on all versions of Windows */ >>> + { >>> + r = FolderItems_get_Count(items, NULL); >>> +todo_wine >>> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >>> + } >> >> Why do you want to handle this case if it crashes consistently on >> Windows? And todo_wine is not going to do anything in commented block >> obviously. > > Good point. Would you like me to remove this code altogether, or just > the todo_wine and ok statement? Also, would you like me to change the > other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid > having todo_wine's in if (0) blocks? If it crashes on some windows versions just put it in 'if (0)' with appropriate comment for documentation purposes, and a NULL check could be implemented. Version 5,1 means XP, right? if it does not crash since XP just make it a regular test, enabled unconditionally. > > -Alex >

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Alex Henrie

2016-07-05 0:26 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: > On 05.07.2016 8:47, Alex Henrie wrote: >> + if (0) /* crashes on all versions of Windows */ >> + { >> + r = FolderItems_get_Count(items, NULL); >> +todo_wine >> + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); >> + } > > Why do you want to handle this case if it crashes consistently on > Windows? And todo_wine is not going to do anything in commented block > obviously. Good point. Would you like me to remove this code altogether, or just the todo_wine and ok statement? Also, would you like me to change the other if (0) blocks to if (GetVersion() > MAKELONG(5,1)) to avoid having todo_wine's in if (0) blocks? -Alex

July 5, 2016

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)

by Henri Verbeet

On 27 June 2016 at 23:54, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > static HRESULT WINAPI d3drm_viewport1_Init(IDirect3DRMViewport *iface, IDirect3DRMDevice *device, > IDirect3DRMFrame *camera, DWORD x, DWORD y, DWORD width, DWORD height) > { > - FIXME("iface %p, device %p, camera %p, x %u, y %u, width %u, height %u stub!\n", > - iface, device, camera, x, y, width, height); > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport(iface); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(camera); Using impl_from_IDirect3DRMFrame() here is unusual. > + if (!device || !camera) > + return D3DRMERR_BADOBJECT; And note that this only works because of the d3drm_frame structure layout. You'll want to use unsafe_impl_from_IDirect3DRMFrame() if "camera" can be NULL.

July 5, 2016

Re: ntdll: Add RtlRestoreContext implementation

by Piotr Caban

On 07/05/16 16:07, Sebastian Lackner wrote: > On 04.07.2016 10:55, Piotr Caban wrote: >> Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> >> --- >> dlls/kernel32/kernel32.spec | 2 +- >> dlls/ntdll/ntdll.spec | 1 + >> dlls/ntdll/signal_x86_64.c | 73 +++++++++++++++++++++++++-------------------- >> 3 files changed, 42 insertions(+), 34 deletions(-) >> > > Your patch also changes unwinding behavior in case of MSVCRT_JUMP_BUFFER. > Previously the instruction pointer stored in the jump buffer was ignored, > now it will overwrite the value passed as target_ip. Is that intentional? My bad, I'll send a fixed version. Thank you, Piotr

July 5, 2016

Re: [PATCH 3/3] regedit: Process the next file, if any, on error (v2)

by Sebastian Lackner

On 05.07.2016 11:13, Hugh McMaster wrote: > Changes since v1: > * Do not leak memory when moving to the next file. > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regedit.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/programs/regedit/regedit.c b/programs/regedit/regedit.c > index 04dd317..8a6a975 100644 > --- a/programs/regedit/regedit.c > +++ b/programs/regedit/regedit.c > @@ -88,7 +88,7 @@ typedef enum { > ACTION_ADD, ACTION_EXPORT, ACTION_DELETE > } REGEDIT_ACTION; > > -static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > +static void PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > { > switch (action) { > case ACTION_ADD: { > @@ -113,7 +113,9 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > if (size == 0) > { > output_message(STRING_FILE_NOT_FOUND, filename); > - exit(1); > + if (realname) > + HeapFree(GetProcessHeap(), 0, realname); I haven't reviewed the whole series, but passing a NULL pointer to HeapFree() is perfectly fine, and its better to avoid such checks. > + return; > } > reg_file = _wfopen(realname, rb_mode); > if (reg_file == NULL) > @@ -121,7 +123,9 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > WCHAR regedit[] = {'r','e','g','e','d','i','t',0}; > _wperror(regedit); > output_message(STRING_CANNOT_OPEN_FILE, filename); > - exit(1); > + if (realname) > + HeapFree(GetProcessHeap(), 0, realname); Same here. > + return; > } > import_registry_file(reg_file); > if (realname) > @@ -150,7 +154,6 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > exit(1); > break; > } > - return TRUE; > } > > BOOL ProcessCmdLine(WCHAR *cmdline) >

July 5, 2016

Re: ntdll: Add RtlRestoreContext implementation

by Sebastian Lackner

On 04.07.2016 10:55, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/kernel32/kernel32.spec | 2 +- > dlls/ntdll/ntdll.spec | 1 + > dlls/ntdll/signal_x86_64.c | 73 +++++++++++++++++++++++++-------------------- > 3 files changed, 42 insertions(+), 34 deletions(-) > Your patch also changes unwinding behavior in case of MSVCRT_JUMP_BUFFER. Previously the instruction pointer stored in the jump buffer was ignored, now it will overwrite the value passed as target_ip. Is that intentional?

July 5, 2016

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)

by Marvin

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

July 5, 2016

Re: [v2] secur32 : add and fix some algids

by Jacek Caban

Hi Max, On 03.07.2016 23:41, Max Qian wrote: > diff --git a/include/wincrypt.h b/include/wincrypt.h > index 55c9509..19af6ca 100644 > --- a/include/wincrypt.h > +++ b/include/wincrypt.h > @@ -1583,6 +1583,7 @@ typedef const CERT_CRL_CONTEXT_PAIR *PCCERT_CRL_CONTEXT_PAIR; > #define ALG_SID_AGREED_KEY_ANY 3 > #define ALG_SID_KEA 4 > #define ALG_SID_ECDH 5 > +#define ALG_SID_ECDH_EPHEM 6 > /* RC2 SIDs */ > #define ALG_SID_RC4 1 > #define ALG_SID_RC2 2 > @@ -1639,6 +1640,7 @@ typedef const CERT_CRL_CONTEXT_PAIR *PCCERT_CRL_CONTEXT_PAIR; > #define CALG_KEA_KEYX (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_KEA) > #define CALG_HUGHES_MD5 (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_ANY | ALG_SID_MD5) > #define CALG_ECDH (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_ECDH) > +#define CALG_ECDH_EPHEM (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_ECDH_EPHEM) > #define CALG_RSA_KEYX (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_RSA | ALG_SID_RSA_ANY) > #define CALG_ECMQV (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_ANY | ALG_SID_ECMQV) > #define CALG_DES (ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_DES) Do you have a version of PSDK that has this definition? I can't see it here. If those are not in MS headers, we shouldn't have them unless we have a strong reason. When I asked you about adding a comment, I was hoping for something like /* MSDN mentions CALG_ECDH_EPHEM, but it's not available in headers. */ case ....: return CALG_ECDH; Thanks, Jacek

July 5, 2016

Re: krnl386.exe16: Fix a typo in comment.

by Huw Davies

On Tue, Jul 05, 2016 at 03:36:30PM +0300, Andrey Gusev wrote: > diff --git a/dlls/krnl386.exe16/file.c b/dlls/krnl386.exe16/file.c > index 4e7f7c4..44b1e75 100644 > --- a/dlls/krnl386.exe16/file.c > +++ b/dlls/krnl386.exe16/file.c > @@ -549,7 +549,7 @@ INT16 WINAPI GetPrivateProfileString16( LPCSTR section, LPCSTR entry, > if (!entry) > { > /* We have to return the list of keys in the section but without the values > - * so we need to massage the results of GetPrivateProfileSectionA. > + * so we need to message the results of GetPrivateProfileSectionA. > */ > UINT ret, oldlen = len, size = min( len, 1024 ); > LPSTR data, src; No, again the original is correct. Huw.

July 5, 2016

Re: gdi32/dibdrv: Fix a typo in comment.

by Huw Davies

On Tue, Jul 05, 2016 at 03:33:39PM +0300, Andrey Gusev wrote: > diff --git a/dlls/gdi32/dibdrv/graphics.c b/dlls/gdi32/dibdrv/graphics.c > index bfb3451..ca357b2 100644 > --- a/dlls/gdi32/dibdrv/graphics.c > +++ b/dlls/gdi32/dibdrv/graphics.c > @@ -1567,7 +1567,7 @@ COLORREF dibdrv_SetPixel( PHYSDEV dev, INT x, INT y, COLORREF color ) > rect.bottom = rect.top + 1; > add_clipped_bounds( pdev, &rect, pdev->clip ); > > - /* SetPixel doesn't do the 1bpp massaging like other fg colors */ > + /* SetPixel doesn't do the 1bpp messaging like other fg colors */ > pixel = get_pixel_color( dev->hdc, &pdev->dib, color, FALSE ); > color = pdev->dib.funcs->pixel_to_colorref( &pdev->dib, pixel ); No, the original is correct. Huw.

July 5, 2016

Re: [PATCH 2/5] shell32: Stub out FolderItems.

by Michael Stefaniuc

Alex, On 07/05/2016 07:50 AM, Alex Henrie wrote: > I grepped the code and the names ppTInfo, rgszNames, and rgDispId are > used pretty consistently throughout Wine. I think that unless we're > going to refactor the names across the entire codebase, we might as > well keep them. you miss the point. That is *old* code when Alexandre was "still young and needed the money"... The rules have changed and new code should be clean even if it is surrounded by old ugly code. bye michael

July 5, 2016

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.

by Nikolay Sivov

On 05.07.2016 8:47, Alex Henrie wrote: > + if (0) /* crashes on all versions of Windows */ > + { > + r = FolderItems_get_Count(items, NULL); > +todo_wine > + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); > + } Why do you want to handle this case if it crashes consistently on Windows? And todo_wine is not going to do anything in commented block obviously.

July 5, 2016

Re: [PATCH v2 2/5] shell32: Stub out FolderItems.

by Nikolay Sivov

On 05.07.2016 8:47, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index 492f79f..64a26bb 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -234,6 +234,7 @@ enum tid_t { > IShellDispatch6_tid, > IShellFolderViewDual3_tid, > Folder3_tid, > + FolderItems3_tid, > FolderItem2_tid, > FolderItemVerb_tid, > FolderItemVerbs_tid, That's not going to work, you have to update tid_ids[] too. Also please keep it sorted. > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index 6dece6d..3661430 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -65,6 +65,11 @@ typedef struct { > } FolderImpl; > > typedef struct { > + FolderItems3 FolderItems3_iface; > + LONG ref; > +} FolderItemsImpl; > + > +typedef struct { > FolderItem2 FolderItem2_iface; > LONG ref; > VARIANT dir; > @@ -97,6 +102,11 @@ static inline FolderImpl *impl_from_Folder(Folder3 *iface) > return CONTAINING_RECORD(iface, FolderImpl, Folder3_iface); > } > > +static inline FolderItemsImpl *impl_from_FolderItems(FolderItems3 *iface) > +{ > + return CONTAINING_RECORD(iface, FolderItemsImpl, FolderItems3_iface); > +} > + > static inline FolderItemImpl *impl_from_FolderItem(FolderItem2 *iface) > { > return CONTAINING_RECORD(iface, FolderItemImpl, FolderItem2_iface); > @@ -939,6 +949,200 @@ static HRESULT FolderItem_Constructor(VARIANT *dir, FolderItem **ppfi) > return ret; > } > > +static HRESULT WINAPI FolderItemsImpl_QueryInterface(FolderItems3 *iface, > + REFIID riid, LPVOID *ppv) > +{ > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + > + TRACE("(%p,%p,%p)\n", iface, riid, ppv); Usually we trace riid. > + > + if (!ppv) return E_INVALIDARG; This is unusual, do we have a test for that?

July 5, 2016

Re: [PATCH 2/5] shell32: Stub out FolderItems.

by Alex Henrie

2016-07-04 8:37 GMT-06:00 Alex Henrie <alexhenrie24(a)gmail.com>: > 2016-07-04 5:09 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: >> On 04.07.2016 07:25, Alex Henrie wrote: >>> [...] >> >> Some of the variable names (for example ppTInfo, rgszNames, rgDispId) sound >> a bit odd. Usually variable names without ugly prefix are preferred for new >> code (except we want to keep it for compatibility with old code here?). > > I was trying to make the new code match the surrounding code. I don't > think the variable names matter very much here, but I'll change them > if you feel strongly about it. > >>> +static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) >>> +{ >>> + FIXME("(%p,%p)\n", iface, ppid); >> >> You forgot to trace the index parameter here. > > Good point. I'll fix that and resubmit the series (although hopefully > Alexandre will have taken patch 1 without changes). > >>> @@ -1093,8 +1297,7 @@ static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) >>> { >>> FIXME("(%p,%p)\n", iface, ppid); >> >> You forgot to change the FIXME to a TRACE. > > This is actually intentional, because the patch makes this function > return a list of items, but the list is empty. I'm going to change the > FIXME to a TRACE in the patch that populates the list: > https://github.com/alexhenrie/wine/commits/master > > Thanks for the feedback. > > -Alex I grepped the code and the names ppTInfo, rgszNames, and rgDispId are used pretty consistently throughout Wine. I think that unless we're going to refactor the names across the entire codebase, we might as well keep them. So, the only change I've made between v1 and v2 of this patchset is adding the missing parameter to FolderItemsImpl_Item's FIXME statement. -Alex

July 5, 2016

Re: PATCH] ws2_32: Allow user to enable IP dual stack.

by Bruno Jesus

On Mon, Jul 4, 2016 at 6:35 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. Hi, thanks for the updated version. I believe the patch failed to apply because you added text after it and also an attachment which is inlined while the email is being parsed. The result you can see at [1]. The subject should show how many attempts the patch was sent to, so next subject should be: [PATCH] ws2_32: Allow user to enable IP dual stack (v3) Please see some nitpicks below. [1] http://source.winehq.org/patches/data/123921 > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++-------------- > dlls/ws2_32/tests/sock.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 48 insertions(+), 14 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index b0af3d7..c29bd2b 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3240,20 +3240,6 @@ int WINAPI WS_bind(SOCKET s, const struct > WS_sockaddr* name, int namelen) > } > else > { > -#ifdef IPV6_V6ONLY > - const struct sockaddr_in6 *in6 = (const struct > sockaddr_in6*) &uaddr; > - if (name->sa_family == WS_AF_INET6 && > - !memcmp(&in6->sin6_addr, &in6addr_any, sizeof(struct > in6_addr))) > - { > - int enable = 1; > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, > sizeof(enable)) == -1) > - { > - release_sock_fd( s, fd ); > - SetLastError(WSAEAFNOSUPPORT); > - return SOCKET_ERROR; > - } > - } > -#endif > if (name->sa_family == WS_AF_INET) > { > struct sockaddr_in *in4 = (struct sockaddr_in*) &uaddr; > @@ -7163,6 +7149,14 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + /* Winsock documentation stipulates that IPV6_V6ONLY is enabled > by default*/ The documentation is not always useful (and sometimes wrong) and now we should have a test to back this up, I believe a better comment to be: /* AF_INET6 sockets have IPV6_V6ONLY enabled by default. */ Watch out for missing space between the last comment word and the */ > + int enable = 1; > + WS_setsockopt(ret, WS_IPPROTO_IPV6, WS_IPV6_V6ONLY, &enable, > sizeof(enable)); > + } > +#endif > return ret; > } > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 6853279..7c8d834 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -6114,6 +6114,46 @@ static void test_ipv6only(void) > ok(!ret, "Could not bind IPv4 address (LastError: %d; %d expected if > IPv6 binds to IPv4 as well).\n", > WSAGetLastError(), WSAEADDRINUSE); > > + if (v4 != INVALID_SOCKET) > + closesocket(v4); > + if (v6 != INVALID_SOCKET) > + closesocket(v6); > + > + /* Test again, this time disabling V6ONLY*/ > + v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); > + if (v6 == INVALID_SOCKET) { > + skip("Could not create IPv6 socket (LastError: %d; %d expected if > IPv6 not available).\n", > + WSAGetLastError(), WSAEAFNOSUPPORT); > + goto end; > + } Do a getsockopt at this point to check what is the default enabled value. Set enabled to the opposite of what you expected before the call and test its value after. > + DWORD enabled = 0; > + int len = sizeof(enabled); You cannot declare variables like this in C89 (?) so do it in the function beginning. > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } I understand that you are trying to skip when IPV6_V6ONLY is not present. It will be better if you catch the explicit error case and bail out, something like: WSASetLastError(0xdeadbeef); ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); error = WSAGetLastError(); if (ret) { ok(error == EXPECTED_ERROR, "Failed to disable IPV6_V6ONLY (LastError %d, %d expected).\n", error, EXPECTED_ERROR); goto end; } > ... Best wishes, Bruno

July 4, 2016

Re: [PATCH 2/5] shell32: Stub out FolderItems.

by Alex Henrie

2016-07-04 5:09 GMT-06:00 Sebastian Lackner <sebastian(a)fds-team.de>: > On 04.07.2016 07:25, Alex Henrie wrote: >> [...] > > Some of the variable names (for example ppTInfo, rgszNames, rgDispId) sound > a bit odd. Usually variable names without ugly prefix are preferred for new > code (except we want to keep it for compatibility with old code here?). I was trying to make the new code match the surrounding code. I don't think the variable names matter very much here, but I'll change them if you feel strongly about it. >> +static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) >> +{ >> + FIXME("(%p,%p)\n", iface, ppid); > > You forgot to trace the index parameter here. Good point. I'll fix that and resubmit the series (although hopefully Alexandre will have taken patch 1 without changes). >> @@ -1093,8 +1297,7 @@ static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) >> { >> FIXME("(%p,%p)\n", iface, ppid); > > You forgot to change the FIXME to a TRACE. This is actually intentional, because the patch makes this function return a list of items, but the list is empty. I'm going to change the FIXME to a TRACE in the patch that populates the list: https://github.com/alexhenrie/wine/commits/master Thanks for the feedback. -Alex

July 4, 2016

Re: [PATCH v2 05/11] d3d11/tests: Add test for creating unordered access views.

by Henri Verbeet

On 4 July 2016 at 12:26, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static void test_create_unordered_access_view(void) > +{ > + static const D3D_FEATURE_LEVEL feature_level = D3D_FEATURE_LEVEL_11_0; > + D3D11_UNORDERED_ACCESS_VIEW_DESC uav_desc; > + D3D11_TEXTURE3D_DESC texture3d_desc; > + D3D11_TEXTURE2D_DESC texture2d_desc; > + ULONG refcount, expected_refcount; > + D3D11_SUBRESOURCE_DATA data = {0}; > + ID3D11UnorderedAccessView *uav; > + struct device_desc device_desc; > + D3D11_BUFFER_DESC buffer_desc; > + ID3D11Device *device, *tmp; > + ID3D11Texture3D *texture3d; > + ID3D11Texture2D *texture2d; > + ID3D11Resource *texture; > + ID3D11Buffer *buffer; > + IUnknown *iface; This is unused.

July 4, 2016

Re: [PATCH 2/5] shell32: Stub out FolderItems.

by Sebastian Lackner

On 04.07.2016 07:25, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. Actually the patch looks very similar, but this is probably caused by the fact that you both wrote it based on existing code. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > Some of the variable names (for example ppTInfo, rgszNames, rgDispId) sound a bit odd. Usually variable names without ugly prefix are preferred for new code (except we want to keep it for compatibility with old code here?). > +static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > +{ > + FIXME("(%p,%p)\n", iface, ppid); You forgot to trace the index parameter here. > + > + return E_NOTIMPL; > +} [...] > @@ -1093,8 +1297,7 @@ static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) > { > FIXME("(%p,%p)\n", iface, ppid); You forgot to change the FIXME to a TRACE. > > - *ppid = NULL; > - return E_NOTIMPL; > + return FolderItems_Constructor(ppid); > } > > static HRESULT WINAPI FolderImpl_ParseName(Folder3 *iface, BSTR name, FolderItem **item) >

July 4, 2016

Re: PATCH] ws2_32: Allow user to enable IP dual stack.

by Marvin

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

July 4, 2016

Re: [PATCH 1/2] msvcr120: Add fegetenv implementation

by Marvin

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=23946 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 0 === w2008s64 (64 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 10

July 4, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)

by Marvin

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=23944 Your paranoid android. === wxppro (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2003std (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === wvistau64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2008s64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7u (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7pro64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w8 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w864 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w1064 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161

July 4, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)

by Austin English

On Jul 4, 2016 1:25 AM, "Zebediah Figura" <z.figura12(a)gmail.com> wrote: > > --- > dlls/advapi32/tests/eventlog.c | 139 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 139 insertions(+) > > diff --git a/dlls/advapi32/tests/eventlog.c b/dlls/advapi32/tests/eventlog.c > index 3ca59c3..5163537 100644 > --- a/dlls/advapi32/tests/eventlog.c > +++ b/dlls/advapi32/tests/eventlog.c > @@ -20,12 +20,15 @@ > > #include <stdarg.h> > > +#include "initguid.h" > #include "windef.h" > #include "winbase.h" > #include "winerror.h" > #include "winnt.h" > #include "winreg.h" > #include "sddl.h" > +#include "wmistr.h" > +#include "evntrace.h" > > #include "wine/test.h" > > @@ -1142,6 +1145,141 @@ static void cleanup_eventlog(void) > ok(bret, "Expected MoveFileEx to succeed: %d\n", GetLastError()); > } > > +static void test_trace(void) > +{ > + const char sessionname[] = "Wine"; > + const char filepath[] = "wine.etl"; > + const LONG lnoffset = ((sizeof(EVENT_TRACE_PROPERTIES) >> 3) + 1) << 3; //pad to 8 bytes > + const LONG lfnoffset = (((lnoffset + sizeof(sessionname)) >> 3) + 1) << 3; //pad to 8 bytes Please avoid C++ style comments, use /* this instead */

July 4, 2016

Re: [PATCH signed-off] secur32 : add and fix some algids

by Max Qian

Fixed the tabs and added CALG_ECDH_EPHEM in v2 of the patch. Can you look over it?

July 3, 2016

Re: [PATCH signed-off] secur32 : add and fix some algids

by Maxqia

Fixed the tabs and added CALG_ECDH_EPHEM in v2 of the patch. Can you look over it?

July 3, 2016

Re: [PATCH] wined3d/resource: Performance improvement

by Patrick Rudolph

On 2016-07-03 11:55 AM, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-03 um 10:04 schrieb Henri Verbeet: >> Finally, there the possibility that Windows filters invalid flag >> combinations like Wine currently does, and picking either DISCARD >> or NOOVERWRITE will break an application that depends on that. > When I originally added support for dynamic buffers in 2010 or so I > just forwarded the flags to the driver. That did break some > applications. I'll try to find out which one it was, I believe I put > some details in the patch description. > > It's also possible that there are some differences between textures > and buffers. In d3d <= 9, D3DLOCK_NOOVERWRITE is not supported on > textures. So it might be filtered out, and DISCARD prevails. But my > understanding is that Unigine uses the questionable combination on > buffers, not textures. > It uses both flags on buffers in d3d9 mode. I'm going to add tests for it. Regards, Patrick > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXeOEWAAoJEN0/YqbEcdMwBRQP/jsjUZXuKbUeoh3iaorwY02B > qZXhtc2IbQlZt2989jAGIjuZoCtE2sP8oRkmtbGI3nfIthOxFKrwcPKnqYiz40aF > JqCqYiwMNSpcqDKEhC92w8ad4F8AMBIG/4IUVBtU/uL0W2fBKNJ0rKE4v2sNefo1 > OTa0ZCtUSCbvErO9xgen43KparIRNK1juxlkE7CVHkWwK3oBl8GO+IzJ6ZKSN54A > ftz48C7if3y0ul2Xs/HVC/J3UqnksgL1sRnxUeDrFC6MRsNQZaf0D3Gn9vUdqukt > t+hxArnt6DEgMiPlbh3Zhoso4lNzoJJxPpldmWYAgEiU5l6BqVnvSuDUzZZGjLqz > 8dg0QEzjDbta5rLwMi6NnZxTYinx8F61YMOUSfMIkKofz4Xc7v2TnEsgMRI9XuoV > f9KZVssvpYoBuQHI0qEpK4eEBqlU/ZtFh39O+j13980Z6wNtnCQVYUtMcY8hU8Nv > kf5iN/eOuMVrMV6EKqZswJe1CHfAfhVhLfD9kOMRREb5MjrAVyreigbHR/RXG3BH > K9bWwCnnaVfQDtJzUw9ab+e+uSbkkiymjrkWY8JKI3E0d8YBnupxS8GcwJTT0y0t > x5K/Fzp/a2U+x4FV8MZewIhT4azA+DEsgHi/6dviRi6/8ct6J4TTZZqCRKtgWFBy > O8waYy1TvNoBQETnhMaC > =7Pmz > -----END PGP SIGNATURE-----

July 3, 2016

Re: [PATCH] wined3d/resource: Performance improvement

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-03 um 10:04 schrieb Henri Verbeet: > Finally, there the possibility that Windows filters invalid flag > combinations like Wine currently does, and picking either DISCARD > or NOOVERWRITE will break an application that depends on that. When I originally added support for dynamic buffers in 2010 or so I just forwarded the flags to the driver. That did break some applications. I'll try to find out which one it was, I believe I put some details in the patch description. It's also possible that there are some differences between textures and buffers. In d3d <= 9, D3DLOCK_NOOVERWRITE is not supported on textures. So it might be filtered out, and DISCARD prevails. But my understanding is that Unigine uses the questionable combination on buffers, not textures. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXeOEWAAoJEN0/YqbEcdMwBRQP/jsjUZXuKbUeoh3iaorwY02B qZXhtc2IbQlZt2989jAGIjuZoCtE2sP8oRkmtbGI3nfIthOxFKrwcPKnqYiz40aF JqCqYiwMNSpcqDKEhC92w8ad4F8AMBIG/4IUVBtU/uL0W2fBKNJ0rKE4v2sNefo1 OTa0ZCtUSCbvErO9xgen43KparIRNK1juxlkE7CVHkWwK3oBl8GO+IzJ6ZKSN54A ftz48C7if3y0ul2Xs/HVC/J3UqnksgL1sRnxUeDrFC6MRsNQZaf0D3Gn9vUdqukt t+hxArnt6DEgMiPlbh3Zhoso4lNzoJJxPpldmWYAgEiU5l6BqVnvSuDUzZZGjLqz 8dg0QEzjDbta5rLwMi6NnZxTYinx8F61YMOUSfMIkKofz4Xc7v2TnEsgMRI9XuoV f9KZVssvpYoBuQHI0qEpK4eEBqlU/ZtFh39O+j13980Z6wNtnCQVYUtMcY8hU8Nv kf5iN/eOuMVrMV6EKqZswJe1CHfAfhVhLfD9kOMRREb5MjrAVyreigbHR/RXG3BH K9bWwCnnaVfQDtJzUw9ab+e+uSbkkiymjrkWY8JKI3E0d8YBnupxS8GcwJTT0y0t x5K/Fzp/a2U+x4FV8MZewIhT4azA+DEsgHi/6dviRi6/8ct6J4TTZZqCRKtgWFBy O8waYy1TvNoBQETnhMaC =7Pmz -----END PGP SIGNATURE-----

July 3, 2016

Re: Re: [PATCH] wined3d/resource: Performance improvement

by Henri Verbeet

On 2 July 2016 at 08:49, Patrick Rudolph <siro(a)das-labor.org> wrote: >> It makes logical sense to me that mapping a buffer with both DISCARD and >> NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at >> least some engines will map a part of a buffer with NOOVERWRITE and draw >> with that part, map the next part of the buffer with NOOVERWRITE and >> draw with that part, etc, then after the last part of the buffer it maps >> with DISCARD to get new memory and keep going while the previous buffer >> memory is handled asynchronously by the driver or card. >> >> I notice that wined3d has some parts where it ignores/removes DISCARD, >> so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. >> In such a case, the driver will get NOOVERWRITE for a part of the buffer >> that's still in use. It would probably be better to remove NOOVERWRITE >> when both DISCARD and NOOVERWRITE are set. > > Both flags are independent of each other and provide useful information > to the OpenGL driver. The driver knows best how to map the resource. > By passing NOOVERWRITE and DISCARD it's likely going to use NOOVERWRITE, > as it's even less overhead than DISCARD. > > I don't think that WINE should drop flags, except there's a driver bug > that can't be fixed (in the near future). > The patch is at the very least questionable. The way NOOVERWRITE/DISCARD are normally intended to be used is for streaming vertex data from the CPU to the GPU. NOOVERWRITE means the application promises it won't touch data that may be in use by the GPU, DISCARD means the application doesn't need the contents of the buffer any more, and it can go away after the GPU is done with it. In practice this means applications use NOOVERWRITE to append to the buffer until it's full, and then use DISCARD to get a new block of video memory. It's unclear what should happen when the application specifies both, but "have the driver pick one" seems unlikely to be what the application intended. In particular, if the application specified NOOVERWRITE because it determined (somehow, e.g. using fences) that it's not going to touch any data in use by the GPU, DISCARD is redundant and would lead to the driver doing unnecessary work if it picked DISCARD. On the other hand, if the application didn't make that determination and the driver picks NOOVERWRITE, the application is potentially going to write over data still in use by the GPU and cause geometry corruption. Finally, there the possibility that Windows filters invalid flag combinations like Wine currently does, and picking either DISCARD or NOOVERWRITE will break an application that depends on that. It could very well be the case that "DISCARD | NOOVERWRITE" behaves like e.g. just "DISCARD", but having the driver just pick one of them is almost certainly the wrong thing to do. Like so many other things, determining the correct behaviour would require some tests. This is of course one of the harder things to write tests for, but I don't think it's impossible.

July 3, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace().

by GOUJON Alexandre

On 07/02/2016 10:57 PM, Zebediah Figura wrote: > On 07/02/2016 07:47 AM, Marvin wrote: >> 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=23920 >> >> Your paranoid android. >> >> >> === wxppro (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w2003std (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === wvistau64 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w2008s64 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w7u (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w7pro64 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w8 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w864 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> === w1064 (32 bit eventlog) === >> eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 >> eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 >> eventlog.c:1272: Test failed: Expected success >> eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 >> >> > This test is failing when built 32 bits, but I tried building both > 64-bit and 32-bit executables using mingw-w64 on my win7 machine, and > they both worked. I'm a newbie (this is my first patch), so I'm probably > doing something wrong, but I don't know what. The error in question (87) > is probably associated with the wrong sizeof() being returned, but I > don't know why that would happen. > > Thanks, > Zeb Welcome to wine ! Nothing really wrong at a first look but we can nitpick (inconsistent formatting, PFOO usage instead of FOO *, etc.). Returned error may depend on Windows version, installed Service Pack, dll version, structure version... To broaden your tests, you can use the test bot (https://wiki.winehq.org/Wine_TestBot) In your case, it may be an alignment issue (see http://stackoverflow.com/questions/9049971/windows-etw-starttrace-failing-w…)

July 3, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace().

by Zebediah Figura

On 07/02/2016 07:47 AM, Marvin wrote: > 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=23920 > > Your paranoid android. > > > === wxppro (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w2003std (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === wvistau64 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w2008s64 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w7u (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w7pro64 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w8 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w864 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > === w1064 (32 bit eventlog) === > eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 > eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 > eventlog.c:1272: Test failed: Expected success > eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 > > This test is failing when built 32 bits, but I tried building both 64-bit and 32-bit executables using mingw-w64 on my win7 machine, and they both worked. I'm a newbie (this is my first patch), so I'm probably doing something wrong, but I don't know what. The error in question (87) is probably associated with the wrong sizeof() being returned, but I don't know why that would happen. Thanks, Zeb

July 2, 2016

Re: [PATCH 1/3] kernel32/tests/fiber: Add tests for fiber-local storage.

by André Hentschel

Am 02.07.2016 um 04:41 schrieb John Sheu: > Signed-off-by: John Sheu <sheu(a)google.com> Hi and welcome to Wine development! May I ask if you could name an application which will benefit from your fixes? Your tests currently fail on our testbot as you can see here: https://source.winehq.org/patches/ Some inline comments: > static VOID WINAPI FiberMainProc(LPVOID lpFiberParameter) > { > BYTE *tparam = (BYTE *)lpFiberParameter; > - cbCount++; > + fiberCount++; > ok(*tparam == 185, "Parameterdata expected not to be changed\n"); > + if (fls_index_to_set != FLS_OUT_OF_INDEXES) > + { > + if (!pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + } > + else > + { > + PVOID pret; > + BOOL bret; > + > + pret = FlsGetValue(fls_index_to_set); > + ok(pret == NULL, "FlsGetValue returned %p, expected NULL\n", pret); > + > + /* Set the FLS value */ > + SetLastError( 0xdeadbeef ); > + bret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(bret, "FlsSetValue failed with error %u\n", GetLastError()); > + > + /* Verify that FlsGetValue retrieves the value set by FlsSetValue */ > + SetLastError( 0xdeadbeef ); > + pret = FlsGetValue(fls_index_to_set); > + ok(pret == fls_value_to_set, > + "FlsGetValue returned %p, expected %p\n", pret, fls_value_to_set); > + ok(GetLastError() == ERROR_SUCCESS, > + "FlsGetValue error %u\n", GetLastError()); > + } > + } > pSwitchToFiber(fibers[0]); > } You are mixing tabs and spaces in FiberMainProc, spaces are preferred. Further you can avoid some line brakes in ok() calls, only wrap at around 100 > +static void test_FiberLocalStorageWithFibers(PFLS_CALLBACK_FUNCTION cbfunc) { > + PVOID val1 = (PVOID) 0x314; > + PVOID val2 = (PVOID) 0x152; > + BOOL ret; > + > + if (!pConvertThreadToFiber || !pSwitchToFiber || !pDeleteFiber) > + { > + win_skip( "Fibers not supported\n" ); > + return; > + } > + if (!pFlsAlloc || !pFlsFree || !pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + > + fls_index_to_set = pFlsAlloc(cbfunc); > + ok(fls_index_to_set != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); > + > + fiberCount = 0; > + cbCount = 0; > + fibers[0] = pConvertThreadToFiber(&testparam); Why do you convert the current thread into a fiber? It seems to me that is causing the crash on w2k3. You could try to run that test in a seperate thread > + fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); > + fibers[2] = pCreateFiber(0,FiberMainProc,&testparam); > + ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); > + ok(fibers[2] != 0, "CreateFiber failed with error %d\n", GetLastError()); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pSwitchToFiber(fibers[1]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val2; > + pSwitchToFiber(fibers[2]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fls_value_to_set = val2; > + ret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(ret, "FlsSetValue failed\n"); > + ok(val2 == pFlsGetValue(fls_index_to_set), "FlsGetValue failed\n"); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pDeleteFiber(fibers[1]); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + todo_wine > + { > + ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + } You can make that a one liner: todo_wine ok(); Hope that helps Have fun!

July 2, 2016

Re: [PATCH] advapi32: Add some tests for StartTrace().

by Marvin

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=23920 Your paranoid android. === wxppro (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7pro64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w864 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w1064 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87

July 2, 2016