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

Re: [PATCH] shell32: Fix SHFileOperation(FO_MOVE) for creating subdirectories.

by Zhenbo Li

Hi Matteo, Thanks for commenting on my patch 2015-08-27 0:45 GMT+08:00 Matteo Bruni <matteo.mystral(a)gmail.com>: > SHCreateDirectoryExW can probably legitimately fail so I don't think > an ERR is appropriate here. A WARN might be okay. While at it, please > add a space between 'if' and '('. > I think it could be more challenging than I expected to handle the errors. I'll look into it deeper. > Unrelated preexisting issue, those helper functions for > SHFileOperationW() like move_files() return a DWORD but the error code > is otherwise int. It shouldn't matter in practice but it would be nice > to fix that (in a separate patch). I agree with you. DWORD is unsigned, but SHFileOperationW returns a int value. I'll write a patch to fix it, PS. Thanks to Sebastian Lackner's comment on my patch: https://bugs.wine-staging.com/show_bug.cgi?id=541#c3 -- Have a nice day! Zhenbo Li

Aug. 31, 2015

Re: Can't compile wine-git: initializer element is not constant in d3d11

by Zhenbo Li

2015-08-31 6:47 GMT+08:00 Marcus Meissner <marcus(a)jet.franken.de>: > Please dont just build with -O0? Thanks, Marcus With -O1 instead of -O0, the code can be compiled. I hope that patch 114091 can be committed soon. -- Have a nice day! Zhenbo Li

Aug. 31, 2015

Re[2]: findstr: Minimal implementation

by Mikhail Bystryantsev

> Hi, Mikhail. > > Some comments: > > > +static void __cdecl printError(unsigned int id, ...) > > Why explicit __cdecl? > > > + WCHAR format[1024]; > > Here, and everywhere else - please use 4 spaces per indentation level > instead of a tab. > > > + if (!LoadStringW(GetModuleHandleW(NULL), id, format, sizeof(format) / sizeof(format[0]))) > > I think calling it as LoadStringW(NULL, ...) has same effect. > > > > +int find(WCHAR* patternW, WCHAR* filename) > > This should be static. > > > + WideCharToMultiByte(CP_OEMCP, 0, patternW, -1, pattern, patternLen, NULL, NULL); > > Why OEMCP and not ACP? > > > + // Latest char, include them to line > > Please avoid this C99/C++ comment style. > Hi, Nikolay. Thanks for feedback. > Why explicit __cdecl? Ok, I will remove it. I don't know why, but saw it in other source file. I decided that maybe there is some reason. > Here, and everywhere else - please use 4 spaces per indentation level > instead of a tab. Ok. I met different indentations styles, so decided that it does not matter. > I think calling it as LoadStringW(NULL, ...) has same effect. Ok. I just tried to use WinApi as it used in other sources and do not go into details. > This should be static. > Please avoid this C99/C++ comment style. Ok, my failures. > Why OEMCP and not ACP? My failure too. I will use GetConsoleCP() instead.

Aug. 30, 2015

Re: Can't compile wine-git: initializer element is not constant in d3d11

by Marcus Meissner

On Sat, Aug 29, 2015 at 10:19:53PM +0800, Bruno Jesus wrote: > On Sat, Aug 29, 2015 at 12:59 PM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > > Thanks for finding this issue. The attached diff should fix > > compilation for you. What compiler do you use? > > As André already told the patch does work, thanks. I could not test > earlier because only now I had time to use the computer. My compiler > is: > gcc-4.6 (Debian 4.6.4-4) 4.6.4 Please dont just build with -O0? Ciao, Marcus

Aug. 30, 2015

Re: [PATCH] dxgi/tests: Avoid c++ style comment.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-30 um 21:59 schrieb Józef Kucia: > - {FALSE, 0, 2 /* undefined */, DXGI_ERROR_INVALID_CALL, DXGI_ERROR_INVALID_CALL, 0}, //30 > + {FALSE, 0, 2 /* undefined */, DXGI_ERROR_INVALID_CALL, DXGI_ERROR_INVALID_CALL, 0}, /*30 */ better to remove those index comments entirely. While they may seem useful on first sight, it's easy for them to become misleading if lines are added / removed / commented out. I'll send my patch, then Henri can chose whatever he likes best. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV44HSAAoJEN0/YqbEcdMwqWMP/35BfDqJhe7KvM5poSHoIq+8 4KbFkdZkfDkRsLBXQsRlFDDME/VXE74rUA55iOA8rhHqfHt4cUEYrjLBxY8mJ2MK FaSb3Vcp+eUxOrXs/mrtIbUq1ZhrqOwFNHQH/1w+dspozxxg0k9WeK+5Tj1sU+Kx J8RycMNn049rqiJ2TGJq9FV+4w8cvrhJH/DO3I8xu+wSMK8SPeGx7QuYiQ2xO4Th IkBLkiOIOwfghn8ehqS4yzWv2333BlUZDAJruUiZ62ISWj1UqZTRMFA0Al4KT+v4 qO+pB/jym9YIqXUKwufi9z4Y0MYM8fADLeW2VLvrp+TiYz8ahp5Ed5UygizHXHRD aIaFu+RoECUoWb7l//RHBfhm3CyEuElP1IBXfLVeNm1WIt2q4EJhICkVBDcgVDaQ ygX4uxmfjW3Iswl/vHJxXM1BlD/ryycoPJ7/FzytFBzvUH/q6XX+45+NpmtfV5ZR wa6hk0UjFLdmMgwkP03W315Co4OuUVToQGX+M3vGqqQz2dMZ3tlz0NjGHAg4YUDV 9iUFYjIGtiZBnaz7CVVlsMbf+pVd65D2sxCeGodfDDYV/feek0yHykYY6GDGPzfb vhaL/38ejg24Z704ayk1St12RWX9iaXZkzPbCicWtC0avpYzjA2/WlH/X8TS/FFm lCJBPUM5GioDhUI9oqcp =PvBv -----END PGP SIGNATURE-----

Aug. 30, 2015

Re: krnl386.exe16: Avoid shift overflows in DMA_ioport_in.

by André Hentschel

Am 29.08.2015 um 22:51 schrieb Gerald Pfeifer: > Use 0xFFu isntead 0xFF to indicate we are looking at an unsigned > value/constant. > > Gerald > --- I think the change in gcc origins in the fact that there are different shift implementations which vary across cpu architecture. Personally I have ARM in mind which shifts different from x86, so I highly value your work on it.

Aug. 30, 2015

Re: findstr: Minimal implementation

by Nikolay Sivov

Hi, Mikhail. Some comments: > +static void __cdecl printError(unsigned int id, ...) Why explicit __cdecl? > + WCHAR format[1024]; Here, and everywhere else - please use 4 spaces per indentation level instead of a tab. > + if (!LoadStringW(GetModuleHandleW(NULL), id, format, sizeof(format) / sizeof(format[0]))) I think calling it as LoadStringW(NULL, ...) has same effect. > +int find(WCHAR* patternW, WCHAR* filename) This should be static. > + WideCharToMultiByte(CP_OEMCP, 0, patternW, -1, pattern, patternLen, NULL, NULL); Why OEMCP and not ACP? > + // Latest char, include them to line Please avoid this C99/C++ comment style.

Aug. 30, 2015

Re: Does wine send window messages without waiting apps to reenter userdll?

by Sebastian Lackner

Thanks for providing the testcase. It indeed looks like a wine bug. Would you mind to open a bug report on bugs.winehq.org with your testcase and explanation? Feel free to add me as CC. The following quick & dirty hack fixes the issue (but will very likely break other stuff): http://ix.io/kx0 Does it also help for your app? Regards, Sebastian On 28.08.2015 17:52, Javier Pimás wrote: > I wrote a small test which I attach here, very small program where you can > see if WndProc is called from WaitMessage. It fails, which I think shows > what I doubted is actually happening. Tested in the old 1.6.2 wine and also > in 1.7.50. > > Cheers! > > On Wed, Aug 26, 2015 at 11:29 AM, Sebastian Lackner <sebastian(a)fds-team.de> > wrote: > >> On 26.08.2015 16:04, Sebastian Lackner wrote: >>> If you are concerned that WaitMessage immediately dispatches the >> messages, >>> Wine doesn't do that. Processing of window messages is only done in the >>> context of GetMessage and PeekMessage, no matter if its a "queued" or >>> "non-queued" message. In fact Wine doesn't really make a difference >> between >>> the two, it just assigns specific internal message numbers for non-queued >>> messages. To identify those the the highest bit (0x80000000) is set. >> >> After reading the last part again I noticed that I wasn't really very >> precise, >> because I somehow already assumed that you are talking about non-queued >> messages >> caused by SetWindowPos and things like that. Those are implemented using >> internal >> messages in Wine, and might be affected by the "bugs" mentioned in the >> last mail. >> >> Besides that its of course also possible to send other non-queued messages >> directly with SendMessage and similar functions. But in this case the >> answer would >> be the same: WaitMessage does not dispatch them immediately, they are >> processed >> during a call to PeekMessage or GetMessage. >> >> Regards, >> Sebastian >> >> > > > > >

Aug. 30, 2015

Re: How X11 server generate XClientMessageEvent ?

by Changhui LIU

Dear Ken: I see, Thank you. The “WM_PROTOCOLS” is a window manager spec. ------------------ Regards, Changhui Liu ------------------ Original ------------------ From: "Ken Thomases"<ken(a)codeweavers.com>; Date: Fri, Aug 28, 2015 02:38 AM To: "Changhui LIU"<liuchanghui(a)linuxdeepin.com>; Cc: "Alexandre Julliard"<julliard(a)winehq.org>; "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: How X11 server generate XClientMessageEvent ? On Aug 27, 2015, at 10:05 AM, Changhui LIU <liuchanghui(a)linuxdeepin.com> wrote: > > I'm debugging a window set focus problem on Deepin Linux(www.deepin.org), > I found some hints in handle_wm_protocols function of winex11.drv. > But I feel very strange, I don't find where generate the XClientMessageEvent with event.data.l[0] = > x11drv_atom(WM_TAKE_FOCUS) when I git grep WM_TAKE_FOCUS in wine source directory. > > How X11 server generate XClientMessageEvent with event.type = x11drv_atom(WM_PROTOCOLS) > and event.data.l[0] = x11drv_atom(WM_TAKE_FOCUS) ? Wine does not generate such messages. In general, X clients are not supposed to. The window manager generates them and Wine responds. -Ken

Aug. 30, 2015

WS2_32: WSACleanup implementation, server-side, plus remove todos around passing tests. This also fixes bug 32910

by Bruno Jesus

On Saturday, August 29, 2015, Matt Durgavich <mattdurgavich(a)gmail.com <javascript:_e(%7B%7D,'cvml','mattdurgavich(a)gmail.com');>> wrote: > How do I read this test failure? I don’t see any real clues. That is not your fault, just ignore that error. Your subject is overly long too and I didn't catch it earlier but you are using 2 space indentation in Wsacleanup while the rest of the function uses 4 spaces, so please change that. A better subject would be : ws2_32: Implement WSACleanup The details about what bugs are fixed should go in the email body.

Aug. 30, 2015