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

Re: [PATCH 3/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromD3D (try 8).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-06-28 um 11:14 schrieb Aaryaman Vasishta: > + if (FAILED(IDirectDraw2_CreateSurface(ddraw, &surface_desc, ds, NULL))) > + continue; > + > + hr = IDirectDrawSurface_AddAttachedSurface(surface, *ds); > + ok(SUCCEEDED(hr), "Failed to attach depth buffer, hr %#x.\n", hr); > + if (FAILED(hr)) > + continue; You're leaking the depth surface in this case. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVkUYtAAoJEN0/YqbEcdMwCt4P/09yNvjELjIyH5T/5HRdUWm4 LoJLtK/OhmlwdaHCvsShqImde4IjszHm/wzL7sIokNxXJ9zDOvmFPjQ+8jcyBJoG ZPNGB7o2QT1RqVhgXRBJkAGWkrG7Pwd6oTShibKmbxySsTVuol62hcjqSZkZshCz 6iO/9MwhzW1KdpHrVGbXcKAQZzPg8rsqDb+97k5350FYdJFFd0935WOCUiNfHOuu iqAm6V3sJbcQ3SBxJN5l2vPLG2m4j40307fEFNJor9jOkFOGv9RnxzGCp2O+gUcV h6n6l/bmznT/lVl4IedUFYkxIQUgdGIMoUXZfgs5MZZYhuaUrR9XxeNlv7oJrcVQ i1fp3pjEQldw7X4KQXqlwzOn7CvVZTtSqH4D4Glyn/3rHFD0V9fIWINg6Fj/Nd73 fZf8TAHM45WqQ+9ueVmnaYGdkUhN0bq8JDE2QfCKUfXNIOC8j5vLgJ7NC5YhC7xc WtOAsXxF7RRVmbQbfMUYOWJcMWR9XUbTNGyWQhWsiWx92rz3n1m7C3e+K9fp2F2P Eybs30FWbPuKuBxvEy0Ws1bA1xY+my1iD/mQN4YEc1aet2X/YpZ4EqYSWOzwKLM/ FuAchmQFwo7Hyr+9nrAc47441ENMBdQQ/dpAS90wGy/uQPJURj08LFt3EWDjXy/O bkMhBscSpcPpizrksvna =U/er -----END PGP SIGNATURE-----

June 29, 2015

Re: vbscript: Treat empty regexp pattern the same way as NULL pattern.

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=14818 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

June 29, 2015

Re: ntdll: Randomize security cookie when available (try 4)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -1278,6 +1281,26 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > } > } > > + > + /* randomize security cookie */ > + > + if (IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG < nt->OptionalHeader.NumberOfRvaAndSizes && > + (pos = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG].VirtualAddress)) > + { > + IMAGE_LOAD_CONFIG_DIRECTORY *loadcfg = (IMAGE_LOAD_CONFIG_DIRECTORY *)(ptr + pos); > + ULONG_PTR *cookie = (ULONG_PTR *)loadcfg->SecurityCookie; > + struct timeval tv; > + > + gettimeofday( &tv, NULL ); > + srand( tv.tv_usec * getpid() ); > + *cookie = rand(); That's not much better. It doesn't make sense to reset the seed on every call. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2015

Re: [PATCH]winecfg: Double click in dlls list to edit overides. (try 4)

by Nikolay Sivov

On 29.06.2015 12:35, Hao Peng wrote: > Add a feature to winecfg. User can double click in dlls list to edit > overides of selected item. > > superseded all earlier patches. > > --- > programs/winecfg/libraries.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > + case CBN_DBLCLK: > + if (LOWORD(wParam) == IDC_DLLS_LIST) > + { > + int index; > + POINT p; > + if (GetCursorPos(&p) && ScreenToClient((HWND)lParam, &p)) > + { > + index = SendDlgItemMessageW(hDlg, IDC_DLLS_LIST, > + LB_ITEMFROMPOINT, 0, MAKELPARAM(p.x, p.y)); > + if (!HIWORD(index)) > + on_edit_click(hDlg); > + } > + } > + break; Correct me if I'm wrong, but I don't think you get CBN_DBLCLK unless clicked on an item. Quick test with ControlSpy on Windows confirms that. And by the time you get CBN_DBLCLK something is always selected I think, which makes all that cursor complexity redundant.

June 29, 2015

Re: [1/2] user32/tests: Add some tests to show that WS_CLIPCHILDREN doesn't exclude children from update region.

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=14817 Your paranoid android. === wvistau64 (64 bit msg) === msg.c:10561: Test failed: expected PeekMessage to return FALSE, got 1

June 29, 2015

Re: [1/2] qcap: Distinguish interface and implementation pointer for VfwCapture output pin.

by Sebastian Lackner

On 29.06.2015 12:50, Nikolay Sivov wrote: > On 29.06.2015 13:13, Sebastian Lackner wrote: >> Thanks for the feedback. In this case pOutputPin is basically part of the same object, >> not an arbitrary external interface. It is constructed with VfwPin_Construct -> >> BaseOutputPin_Construct, and also holds a reference to the critical section of the parent >> object for example, so there is no clear distinction between public/private interfaces >> anyway. >> >> Most other code parts which use BaseOutputPin_Construct store the result in something like: >> (IPin **)&This->store_impl_pointer_here where the variable already has the corresponding >> implementation type. Should we change it here too? Using only the public interface is not possible, >> take a look at for example the following code part, where a private member is set from a >> different interface: >> >> --- snip --- >> This->driver_info = qcap_driver_init( This->pOutputPin, >> var.__VARIANT_NAME_1.__VARIANT_NAME_2.__VARIANT_NAME_3.ulVal ); >> if (This->driver_info) >> { >> pin = impl_from_IPin(This->pOutputPin); >> pin->driver_info = This->driver_info; // <--- >> --- snip --- > > I personally prefer to use public interface, usually it makes things more clear, and code doesn't depend on implementation changes. > > If in this particular case it's not possible then yes, we should store impl pointer instead of interface pointer. Okay, I'll resend an updated version later then. > > By the way, variant thing looks a little insane, assuming intention was to get V_UI4(&var), which is not necessary right on its own as qcap_driver_init() takes USHORT argument. > Yes, I also noticed it. Changes to this part should probably be in a separate patch though.

June 29, 2015

Re: [1/2] qcap: Distinguish interface and implementation pointer for VfwCapture output pin.

by Nikolay Sivov

On 29.06.2015 13:13, Sebastian Lackner wrote: > On 29.06.2015 09:09, Nikolay Sivov wrote: >> On 29.06.2015 9:08, Sebastian Lackner wrote: >>> - BasePin *pin; >>> + VfwPinImpl *pin; >>> >>> TRACE("destroying everything\n"); >>> if (This->init) >>> @@ -226,10 +236,10 @@ static ULONG WINAPI VfwCapture_Release(IBaseFilter * iface) >>> qcap_driver_stop(This->driver_info, &This->filter.state); >>> qcap_driver_destroy(This->driver_info); >>> } >>> - pin = (BasePin*) This->pOutputPin; >>> - if (pin->pConnectedTo != NULL) >>> + pin = impl_from_IPin(This->pOutputPin); >>> + if (pin->pin.pin.pConnectedTo != NULL) >>> { >>> - IPin_Disconnect(pin->pConnectedTo); >>> + IPin_Disconnect(pin->pin.pin.pConnectedTo); >> >> This is not better than it is now, 'pOutputPin' is IPin* so you should be using public methods. > > Thanks for the feedback. In this case pOutputPin is basically part of the same object, > not an arbitrary external interface. It is constructed with VfwPin_Construct -> > BaseOutputPin_Construct, and also holds a reference to the critical section of the parent > object for example, so there is no clear distinction between public/private interfaces > anyway. > > Most other code parts which use BaseOutputPin_Construct store the result in something like: > (IPin **)&This->store_impl_pointer_here where the variable already has the corresponding > implementation type. Should we change it here too? Using only the public interface is not possible, > take a look at for example the following code part, where a private member is set from a > different interface: > > --- snip --- > This->driver_info = qcap_driver_init( This->pOutputPin, > var.__VARIANT_NAME_1.__VARIANT_NAME_2.__VARIANT_NAME_3.ulVal ); > if (This->driver_info) > { > pin = impl_from_IPin(This->pOutputPin); > pin->driver_info = This->driver_info; // <--- > --- snip --- I personally prefer to use public interface, usually it makes things more clear, and code doesn't depend on implementation changes. If in this particular case it's not possible then yes, we should store impl pointer instead of interface pointer. By the way, variant thing looks a little insane, assuming intention was to get V_UI4(&var), which is not necessary right on its own as qcap_driver_init() takes USHORT argument. > > >> >>> if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IPin)) >>> - *ppv = This; >>> + *ppv = &This->pin.pin.IPin_iface; >> >> This could as well say 'iface'. >> >> > > Is there really a clear preference? I personally always preferred the long form so far, > to make it a bit more clear when many different interfaces are returned. > No, I don't think there is. In this case it would be shorter, but only because of strmbase nesting level. Both ways are better than 'This', so it's up to author I suppose.

June 29, 2015

Re: [1/2] qcap: Distinguish interface and implementation pointer for VfwCapture output pin.

by Sebastian Lackner

On 29.06.2015 09:09, Nikolay Sivov wrote: > On 29.06.2015 9:08, Sebastian Lackner wrote: >> - BasePin *pin; >> + VfwPinImpl *pin; >> >> TRACE("destroying everything\n"); >> if (This->init) >> @@ -226,10 +236,10 @@ static ULONG WINAPI VfwCapture_Release(IBaseFilter * iface) >> qcap_driver_stop(This->driver_info, &This->filter.state); >> qcap_driver_destroy(This->driver_info); >> } >> - pin = (BasePin*) This->pOutputPin; >> - if (pin->pConnectedTo != NULL) >> + pin = impl_from_IPin(This->pOutputPin); >> + if (pin->pin.pin.pConnectedTo != NULL) >> { >> - IPin_Disconnect(pin->pConnectedTo); >> + IPin_Disconnect(pin->pin.pin.pConnectedTo); > > This is not better than it is now, 'pOutputPin' is IPin* so you should be using public methods. Thanks for the feedback. In this case pOutputPin is basically part of the same object, not an arbitrary external interface. It is constructed with VfwPin_Construct -> BaseOutputPin_Construct, and also holds a reference to the critical section of the parent object for example, so there is no clear distinction between public/private interfaces anyway. Most other code parts which use BaseOutputPin_Construct store the result in something like: (IPin **)&This->store_impl_pointer_here where the variable already has the corresponding implementation type. Should we change it here too? Using only the public interface is not possible, take a look at for example the following code part, where a private member is set from a different interface: --- snip --- This->driver_info = qcap_driver_init( This->pOutputPin, var.__VARIANT_NAME_1.__VARIANT_NAME_2.__VARIANT_NAME_3.ulVal ); if (This->driver_info) { pin = impl_from_IPin(This->pOutputPin); pin->driver_info = This->driver_info; // <--- --- snip --- > >> if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IPin)) >> - *ppv = This; >> + *ppv = &This->pin.pin.IPin_iface; > > This could as well say 'iface'. > > Is there really a clear preference? I personally always preferred the long form so far, to make it a bit more clear when many different interfaces are returned.

June 29, 2015

Re: [PATCH 4/6]: msvcp110: Add tr2_sys__Stat implementation and test.

by Piotr Caban

On 06/27/15 19:50, YongHaoHu wrote: > +static file_type stat_set_error(int *err_code) > +{ > + file_type ret; > + *err_code = ERROR_SUCCESS; > + > + switch(GetLastError()) { > + case ERROR_FILE_NOT_FOUND: > + case ERROR_BAD_NETPATH: > + case ERROR_INVALID_NAME: > + case ERROR_BAD_PATHNAME: > + case ERROR_PATH_NOT_FOUND: > + ret = file_not_found; > + break; > + case ERROR_BAD_DEV_TYPE: > + ret = regular_file; > + break; > + default: > + ret = status_unknown; Shouldn't err_code be set to GetLastError in default case? You end up setting it to ERROR_SUCCESS in every case except if path is NULL. Why are you handling ERROR_BAD_DEV_TYPE error here? > + TRACE("(%s %p)\n", debugstr_a(path), err_code); > + DWORD attr; This will produce a compilation warning. Cheers, Piotr

June 29, 2015

Re: [PATCH 2/6]: msvcp110: Add tr2_sys__Rename implementation and test.

by Piotr Caban

On 06/27/15 19:50, YongHaoHu wrote: > + ok(GetFileInformationByHandle(h2, &info2), "GetFileInformationByHandle failed\n"); > + CloseHandle(h2); > + ok(info1.nFileIndexHigh == info2.nFileIndexHigh > + && info1.nFileIndexLow == info2.nFileIndexLow, > + "test_tr2_sys__Rename(): test %d expect two files equivalent\n", i+1); This test is not working when run from VirtualBox share. Could you please run the tests inside temp directroy? Thanks, Piotr

June 29, 2015