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

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

by Hao Peng

Hi, Nikolay Sivov Thanks for your review. I have tested so many times and I'm pretty sure that if user double click on the blank area of the list, we will always receive a CBN_CLICK message. So I have to use LB_ITEMFROMPOINT to know whether a use really clicked on a list item, Otherwise it's wacky that user click on the blank area and the edit window pops out. ------------------ Original ------------------ From: "Nikolay Sivov"<bunglehead(a)gmail.com>; Date: Mon, Jun 29, 2015 04:09 AM To: "wine-devel"<wine-devel(a)winehq.org>; Cc: "Hao Peng"<penghao(a)linuxdeepin.com>; Subject: Re: [PATCH]winecfg: Double click in dlls list to edit overides. (try4) 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 30, 2015

Re: winedbg: Add be_xpoint_FAIL=-1 to enum be_xpoint_type.

by Michael Stefaniuc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Gerald, On 06/30/2015 01:12 AM, Gerald Pfeifer wrote: > This replaces my original submission with a different approach. > > Recall this is about clang 3.4.1 complaining as follows: > > gdbproxy.c:2147:23: warning: comparison of constant -1 with > expression of type 'enum be_xpoint_type' is always false > > In my original submission I noted that "I see two ways to address > this: adding a dummy set to -1 to the enum, or casting the enum to > int before comparing against -1". > > Michael kindly provided feeback to go with the former approach. > This patch does that. (Thanks, Michael!) but can you please change the magic -1 to be_xpoint_FAIL too? > > Gerald --- programs/winedbg/be_cpu.h | 2 +- 1 file changed, 1 > insertion(+), 1 deletion(-) > > diff --git a/programs/winedbg/be_cpu.h b/programs/winedbg/be_cpu.h > index 889f638..c95ed7c 100644 --- a/programs/winedbg/be_cpu.h +++ > b/programs/winedbg/be_cpu.h @@ -20,7 +20,7 @@ > > enum be_cpu_addr {be_cpu_addr_pc, be_cpu_addr_stack, > be_cpu_addr_frame}; enum be_xpoint_type {be_xpoint_break, > be_xpoint_watch_exec, be_xpoint_watch_read, - > be_xpoint_watch_write}; + > be_xpoint_watch_write, be_xpoint_FAIL=-1}; I'd rather have be_xpoint_FAIL as first element in the enum. > struct backend_cpu { const DWORD machine; bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFVklO10ei8kcpE1VERAnKJAKCDf9tLHh2u4/mHPqdwjXTB/ol8MACcDQOx 1UIk4kBN8htbqwT0Wi3z5bo= =M6XR -----END PGP SIGNATURE-----

June 30, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > On 6/26/15 7:31 AM, Michael Stefaniuc wrote: >> Aric, >> >> On 06/26/2015 02:22 PM, Aric Stewart wrote: >>> These internal structures are shared between hid.dll and the forthcoming hidclass.sys >>> >>> Should I define them internally at this point and have a patch later that moves them to the global header? >> my crystal ball tells me that the answer will be to just have that >> internal header and copy it to hidclass.sys >> E.g. I have 8 copies of dmobject.[ch] atm > > I bet you are right here. There is a hidparse.sys that implements all > of those HidP_ functions. But I am pretty sure that you are not > suppose to be able to link a .sys file to a .dll file. Maybe not on Windows, but on Wine you could certainly call hid.dll from hidclass.sys, if that helps. -- Alexandre Julliard julliard(a)winehq.org

June 30, 2015

Re: new patch

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

June 30, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Aric Stewart

On 6/26/15 7:31 AM, Michael Stefaniuc wrote: > Aric, > > On 06/26/2015 02:22 PM, Aric Stewart wrote: >> These internal structures are shared between hid.dll and the forthcoming hidclass.sys >> >> Should I define them internally at this point and have a patch later that moves them to the global header? > my crystal ball tells me that the answer will be to just have that > internal header and copy it to hidclass.sys > E.g. I have 8 copies of dmobject.[ch] atm I bet you are right here. There is a hidparse.sys that implements all of those HidP_ functions. But I am pretty sure that you are not suppose to be able to link a .sys file to a .dll file. So I bet the functions are reimplemented and so the header is in both places. -aric

June 29, 2015

Re: [3/4] shell32: Release shell folders obtained via IFolderView_GetFolder.

by Matteo Bruni

2015-06-29 23:10 GMT+02:00 Thomas Faber <thomas.faber(a)reactos.org>: > As a consequence of the previous patch, Wine now leaks shell folder > references after calling GetFolder. This fixes the call sites to > release them. I think it would be better to merge this with the previous patch, to avoid the temporary regression.

June 29, 2015

Re: [4/4] shell32/tests: Remove a misleading test.

by Nikolay Sivov

Whole series looks good to me, thanks for working on this. On 30.06.2015 0:57, Thomas Faber wrote: > This removes the aforementioned test. Yes, this test was my doing. I guess I misinterpreted results, and static desktop impl hid the issue. By the way, regarding GetFolder(), msdn says that IShellItemArray is also supported, we probably can easily get away be using SHCreateShellItemArray; but that is a separate thing of course, that deserves its own patch and tests.

June 29, 2015

Re: d3dx9_36 [try 2]: Save multiplications and divisions to improve performance

by Matteo Bruni

2015-06-25 23:45 GMT+02:00 David Adam <david.adam.cnrs(a)gmail.com>: > Hi, > > I added a test with 65000 sides. All the test pass with a native d3dx9_36 > dll. You should have mentioned that the new test doesn't pass with the previous implementation, which is what makes this patch really convincing. So this patch is okay to me. Also notice that this in practice doesn't save any multiplication in the loop, at least with my version of GCC: the multiplication 2.0f * D3DX_PI was precalculated at compile time. A better patch title mentioning D3DXCreatePolygon would be nice. The tests generally have some room for improvement. As a followup it would be nice to try and improve them, maybe by replacing the comparison function with one which allows for a relative error and makes it possible to choose a potentially different error value for each test (to be able to lower those as much as possible). I would like to point you to some other place in Wine where the float comparison is done right but, on the spot, I only found relative_error + expect_color macros from d3dx9_36/tests/math.c which are really ugly. FWIW https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbe… seems to be a good read on the subject.

June 29, 2015

Re: d3dcompiler: Add D3DCompileFromFile, D3DCompile2 stubs

by Matteo Bruni

2015-06-27 8:41 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > These functions are only supported with d3dcompiler version 46 and above. > > Changelog: > d3dcompiler: Add D3DCompileFromFile, D3DCompile2 stubs > > > Best Regards > Alistair Leslie-Hughes I don't think you need to encompass the function definitions in an #if D3D_COMPILER_VERSION since they won't be exported anyway by the spec files for version < 46. Can you use a format like the one used in D3DCompile() for the tracing of function parameters in the FIXME?

June 29, 2015

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

by André Hentschel

Am 29.06.2015 um 14:16 schrieb 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. > Where would you see the best point for srand()? __wine_process_init()? Should i do it with a "once" variable? Or would you prefer something like in SystemFunction036 using /dev/urandom (suggested by Bruno)?

June 29, 2015