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

Re: [v2 PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line

by Dmitry Timoshkov

Piotr Caban <piotr.caban(a)gmail.com> wrote: > > Once again: > > Where did you get an idea of such an implementation? Is this copied from > > some place or based on some other implementation? Why for instance simple > > 'return GetCommandLineA()' is not enough as an initial implementation? > > Probably I'm just stating obvious but the function skips executable name > from the command line. That's why returning what GetCommandLineA returns > is incorrect. >From what documentation/description is that obvious? That's not a common practice to send patches for not very obvious things without any tests. Why this implementation treats specially tabs and spaces but not other white space characters? Is that also obvious? How about the tests for quotes/embedded quotes? -- Dmitry.

July 27, 2016

Re: MPR patches

by Pierre Schweitzer

Thanks for your review. I did a complete resubmission according to your review (3 patches already sent + the missing one). Le 27/07/2016 à 14:31, Hugh McMaster a écrit : > > On Wednesday, 27 July 2016, Pierre Schweitzer wrote: >> Regarding 1. & 3. should I perform a resend with that changed, or should >> I change it in the next patch I submit? >> >> For 2., this is done on purpose. Real implementation will come in a >> later patch (already ready and tested here :-)). > > Personally, I'd submit your real implementation of WNetCancelConnection2W > as patch 1 of 2. Then submit your implementation patch using the WCHAR * style > as the second patch. > > But if you decide to keep to your original order, please change the style before sending. > > You should also rebase your patches on the latest git. Your current patch > has an offset of -87 lines. > > As for your security certificate, although it doesn't prevent the patch from applying, > it would be better removed, if possible. > > Le 27/07/2016 à 13:40, Hugh McMaster a écrit : >> On Wednesday, 27 July 2016 6:40 AM, Pierre Schweitzer wrote: >> >>> Is there any reason why the MPR patches are left abandoned? There are >>> others awaiting in my queue... >> >>> + PWSTR name = strdupAtoW(lpName); >>> + if (!name) >>> + return ERROR_NOT_CONNECTED; >> >> 1. New code should use the WCHAR * style. >> >> 2. All three functions call WNetCancelConnection2W, but that function is a stub: >> >> DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) >> { >> FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); >> >> return WN_SUCCESS; >> } >> >> 3. Your mail has a StartCom Secure Digital Certificate attached. This has been mangled, as can be seen at the bottom of your patch: http://source.winehq.org/patches/data/124723 > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

July 27, 2016

RE: MPR patches

by Hugh McMaster

On Wednesday, 27 July 2016, Pierre Schweitzer wrote: > Regarding 1. & 3. should I perform a resend with that changed, or should > I change it in the next patch I submit? > > For 2., this is done on purpose. Real implementation will come in a > later patch (already ready and tested here :-)). Personally, I'd submit your real implementation of WNetCancelConnection2W as patch 1 of 2. Then submit your implementation patch using the WCHAR * style as the second patch. But if you decide to keep to your original order, please change the style before sending. You should also rebase your patches on the latest git. Your current patch has an offset of -87 lines. As for your security certificate, although it doesn't prevent the patch from applying, it would be better removed, if possible. Le 27/07/2016 à 13:40, Hugh McMaster a écrit : > On Wednesday, 27 July 2016 6:40 AM, Pierre Schweitzer wrote: > >> Is there any reason why the MPR patches are left abandoned? There are >> others awaiting in my queue... > >> + PWSTR name = strdupAtoW(lpName); >> + if (!name) >> + return ERROR_NOT_CONNECTED; > > 1. New code should use the WCHAR * style. > > 2. All three functions call WNetCancelConnection2W, but that function is a stub: > > DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) > { > FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); > > return WN_SUCCESS; > } > > 3. Your mail has a StartCom Secure Digital Certificate attached. This has been mangled, as can be seen at the bottom of your patch: http://source.winehq.org/patches/data/124723

July 27, 2016

Re: MPR patches

by Pierre Schweitzer

Hi, Thanks for your feedback. Regarding 1. & 3. should I perform a resend with that changed, or should I change it in the next patch I submit? For 2., this is done on purpose. Real implementation will come in a later patch (already ready and tested here :-)). Le 27/07/2016 à 13:40, Hugh McMaster a écrit : > On Wednesday, 27 July 2016 6:40 AM, Pierre Schweitzer wrote: > >> Is there any reason why the MPR patches are left abandoned? There are >> others awaiting in my queue... > >> + PWSTR name = strdupAtoW(lpName); >> + if (!name) >> + return ERROR_NOT_CONNECTED; > > 1. New code should use the WCHAR * style. > > 2. All three functions call WNetCancelConnection2W, but that function is a stub: > > DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) > { > FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); > > return WN_SUCCESS; > } > > 3. Your mail has a StartCom Secure Digital Certificate attached. This has been mangled, as can be seen at the bottom of your patch: http://source.winehq.org/patches/data/124723 > > Hugh > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

July 27, 2016

Re: MPR patches

by Hugh McMaster

On Wednesday, 27 July 2016 6:40 AM, Pierre Schweitzer wrote: > Is there any reason why the MPR patches are left abandoned? There are > others awaiting in my queue... > + PWSTR name = strdupAtoW(lpName); > + if (!name) > + return ERROR_NOT_CONNECTED; 1. New code should use the WCHAR * style. 2. All three functions call WNetCancelConnection2W, but that function is a stub: DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) { FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); return WN_SUCCESS; } 3. Your mail has a StartCom Secure Digital Certificate attached. This has been mangled, as can be seen at the bottom of your patch: http://source.winehq.org/patches/data/124723 Hugh

July 27, 2016

Re: [v2 PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line

by Piotr Caban

On 07/26/16 04:32, Dmitry Timoshkov wrote: > Once again: > Where did you get an idea of such an implementation? Is this copied from > some place or based on some other implementation? Why for instance simple > 'return GetCommandLineA()' is not enough as an initial implementation? Probably I'm just stating obvious but the function skips executable name from the command line. That's why returning what GetCommandLineA returns is incorrect. Thanks, Piotr

July 27, 2016

Re: [PATCH] ucrtbase: Expose the fabsf function on arm

by Piotr Caban

Hi Martin, On 07/26/16 12:19, Martin Storsjo wrote: > It isn't available in the x86 or x64 versions of ucrtbase.dll > or api-ms-win-crt-math-l1-1-0.dll, but exists (and gets used by > MSVC 2015) on arm. > --- > dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec | 1 + > dlls/ucrtbase/ucrtbase.spec | 1 + > 2 files changed, 2 insertions(+) you forgot to sign-off your patch. Except of that it looks good for me. Thanks, Piotr

July 27, 2016

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

by Alexandre Julliard

John Sheu <sheu(a)google.com> writes: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/loader.c | 118 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 116 insertions(+), 2 deletions(-) Could you please rebase it against recent changes, and resend with a fixed sequence number so that it can run through the testbot? -- Alexandre Julliard julliard(a)winehq.org

July 27, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Bernhard Übelacker

Hello Francois, "DirectX Software Development Kit" offers in "DirectX Control Panel" to increase the "Debug Output Level". That way one can get another hint from dinput: DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string First I tried to build a dinput8.dll that just dumps the data it gets from dinput-mini.exe, but could not find any difference. So I did some tests with DIACTIONA.lptszActionName member. When the two last characters get replaced by \0 no fault is reported anymore. That way a succeeding exe and the failing differ (nearly) just in the two replaced bytes in lptszActionName. Therefore can we assume that it is not the compilers fault, instead it uncovered a hidden bug either in the test or dinput? Kind regards, Bernhard dinput.c: - { 4, DIMOUSE_YAXIS, 0, { "Y Axis" } } + { 4, DIMOUSE_YAXIS, 0, { "Y Ax\0\0" } } Am 17.07.2016 um 21:02 schrieb 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 27, 2016

MPR patches

by Pierre Schweitzer

Hi, Is there any reason why the MPR patches are left abandoned? There are others awaiting in my queue... Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

July 26, 2016