February 2017 - Wine-Devel - list.winehq.org

Re: kernel32: Disable diagnostics when testing corner cases in test_heap().
by Erich E. Hoover Feb. 24, 2017

Feb. 24, 2017

On Sat, Feb 11, 2017 at 2:41 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > ... > With that dlls/kernel32/tests/heap.c triggers three warnings, all of > which are correct positives, but in fact do want to test those corner > cases: I'm not convinced that this statement is true. For example, while "~(SIZE_T)0 - 7" gives us 4294967288 (matching what is indicated by the warning), HeapReAlloc accepts a SIZE_T. So, this should support a maximum value of 4294967295 (not 2147483647). This says to me that gcc thinks SIZE_T is a signed value instead of an unsigned value, do you have any idea why this might be the case? Best, Erich

3 3

Re: wineinstall - Add support for parallel builds using 'nproc' to detect cpu count
by wylda＠volny.cz Feb. 24, 2017

Feb. 24, 2017

______________________________________________________________ > Od: Chris Morgan <chmorgan(a)gmail.com> > Komu: Austin English <austinenglish(a)gmail.com> > Datum: 24.02.2017 13:53 > Předmět: Re: wineinstall - Add support for parallel builds using 'nproc' to > > CC: <wine-devel(a)winehq.org> >On Fri, Feb 24, 2017 at 3:11 AM, Austin English <austinenglish(a)gmail.com> >wrote: > >> On Fri, Feb 24, 2017 at 2:05 AM, <wylda(a)volny.cz> wrote: >> > Hi, >> > i like/use "make -j 1" for log comparison. Can you leave NPROC=1 or >> allow override? >> > >> > W. >> > >> > >> >> Hi Wylda, >> >> Are you doing that with wineinstall? This doesn't affect normal >> ./configure && make, only ./tools/wineinstall. >> >> That said, allowing the user to set it via NPROC or similar would be a >> good idea IMO. >> >> -- >> -Austin >> GPG: 14FB D7EA A041 937B >> > > > >Is this what you had in mind? I wasn't sure how to document that you could >do: > >NPROC=50 ./tools/wineinstall > >to force 50 parallel processes. > > >commit 83321d6452706b5f8f93687ed4e0909aac47fd68 >Author: Chris Morgan <chmorgan(a)gmail.com> >Date: Tue Feb 21 17:03:30 2017 -0500 > > wineinstall - Add support for parallel builds using 'nproc' to detect >cpu count > > Parallel builds can greatly reduce the overall build time on modern >multi-core processors. > > Fall back to two parallel builds in the case where nproc is >unavailable, most modern > processors have at least two cores. > > Use the 'NPROC' value defined by the environment if it is not null. > >diff --git a/tools/wineinstall b/tools/wineinstall >index e8e22bf..a757343 100755 >--- a/tools/wineinstall >+++ b/tools/wineinstall >@@ -143,10 +143,22 @@ echo "in the meantime..." > echo > std_sleep > >+# determine ideal number of parallel processes if NPROC isn't set >+# in the environment >+if [ ! -n $NPROC ] >+then >+ if [ -x `which nproc 2>/dev/null` ] >+ then >+ NPROC=$(nproc --all) >+ else >+ NPROC=2 >+ fi >+fi >+ > # try to just make wine, if this fails 'make depend' and try to remake >-if ! { make; } >+if ! { make -j$NPROC; } > then >- if ! { make depend && make; } >+ if ! { make depend && make -j$NPROC; } > then > echo > echo "Compilation failed, aborting install." > > Hi, as Austin noted, i'm probably not affected by your changes ;) sorry for the noise. But as a user i like the possibility to pass values by command line. Thank you. W.

1 0

Re: [PATCH] mouse.c - Wrap XInput2 dependent functions with appropriate #ifdef
by Bruno Jesus Feb. 24, 2017

Feb. 24, 2017

On Thu, Feb 23, 2017 at 10:23 PM, Chris Morgan <chmorgan(a)gmail.com> wrote: > Fixes a compilation issue in mouse.c when XInput2 isn't available. Both patches you sent are missing a signed-off line. Please see https://wiki.winehq.org/Submitting_Patches#The_commit_message

1 0

Re: [PATCH] dpwsockx: Implementation of GetCaps callback
by Bruno Jesus Feb. 24, 2017

Feb. 24, 2017

On Fri, Feb 24, 2017 at 3:45 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Based on patch by Ismael Barros > > Changes > - Removed todo_wine from tests > - Adjusted the DPWS_GUARANTEED_MAXBUFFERSIZE and DPWS_MAXBUFFERSIZE > to be the correct values > - Remove unused defines. > - Remove Adjustment of dwMaxBufferSize by sizeof(DPSP_MSG_HEADER) > - Added check for structure size. Thanks for your work on this, very minor stuff follows. > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dplayx/dplay.c | 3 +++ > dlls/dplayx/tests/dplayx.c | 6 ++---- > dlls/dpwsockx/dpwsockx_dll.h | 10 ++++++++++ > dlls/dpwsockx/dpwsockx_main.c | 27 +++++++++++++++++++++++++-- > 4 files changed, 40 insertions(+), 6 deletions(-) > > diff --git a/dlls/dplayx/dplay.c b/dlls/dplayx/dplay.c > index f4d934f..b8d2f15 100644 > --- a/dlls/dplayx/dplay.c > +++ b/dlls/dplayx/dplay.c > @@ -2894,6 +2894,9 @@ static HRESULT WINAPI IDirectPlay4Impl_GetPlayerCaps( IDirectPlay4 *iface, DPID > if ( This->dp2->connectionInitialized == NO_PROVIDER ) > return DPERR_UNINITIALIZED; > > + if( caps->dwSize != sizeof(DPCAPS) ) > + return DPERR_INVALIDPARAMS; > + > /* Query the service provider */ > data.idPlayer = player; > data.dwFlags = flags; > diff --git a/dlls/dplayx/tests/dplayx.c b/dlls/dplayx/tests/dplayx.c > index de392aa..32e5e1f 100644 > --- a/dlls/dplayx/tests/dplayx.c > +++ b/dlls/dplayx/tests/dplayx.c > @@ -1088,7 +1088,7 @@ static void test_GetCaps(void) > > /* dpcaps not ininitialized */ > hr = IDirectPlayX_GetCaps( pDP, &dpcaps, 0 ); > - todo_wine checkHR( DPERR_INVALIDPARAMS, hr ); > + checkHR( DPERR_INVALIDPARAMS, hr ); > > dpcaps.dwSize = sizeof(DPCAPS); > > @@ -1098,9 +1098,7 @@ static void test_GetCaps(void) > { > > hr = IDirectPlayX_GetCaps( pDP, &dpcaps, dwFlags ); > - todo_wine checkHR( DP_OK, hr ); > - > - > + checkHR( DP_OK, hr ); > if ( hr == DP_OK ) > { Since now the test must always pass in wine it could be useful to add a win_skip to the else branch or invert the if and use continue. If the if was added only for wine the whole if could be removed then. > check( sizeof(DPCAPS), dpcaps.dwSize ); > diff --git a/dlls/dpwsockx/dpwsockx_dll.h b/dlls/dpwsockx/dpwsockx_dll.h > index 1a6ad6c..debcc11 100644 > --- a/dlls/dpwsockx/dpwsockx_dll.h > +++ b/dlls/dpwsockx/dpwsockx_dll.h > @@ -26,6 +26,16 @@ > #include "wine/dplaysp.h" > > > +#define DPWS_MAXQUEUESIZE 0 > +#define DPWS_HUNDREDBAUD 0 > +#define DPWS_LATENCY 500 > +#define DPWS_MAXLOCALPLAYERS 65536 > +#define DPWS_TIMEOUT 5000 > +#define DPWS_MAXBUFFERSIZE 65479 > +#define DPWS_MAXPLAYERS 65536 > +#define DPWS_GUARANTEED_MAXBUFFERSIZE 1048547 > +#define DPWS_GUARANTEED_MAXPLAYERS 64 > + There is an extra new line before the defines. > typedef struct tagDPWS_THREADDATA > { > BOOL is_running; > diff --git a/dlls/dpwsockx/dpwsockx_main.c b/dlls/dpwsockx/dpwsockx_main.c > index 548f37e..9606d73 100644 > --- a/dlls/dpwsockx/dpwsockx_main.c > +++ b/dlls/dpwsockx/dpwsockx_main.c > @@ -100,9 +100,32 @@ static HRESULT WINAPI DPWSCB_GetAddress( LPDPSP_GETADDRESSDATA data ) > > static HRESULT WINAPI DPWSCB_GetCaps( LPDPSP_GETCAPSDATA data ) > { > - FIXME( "(%d,%p,0x%08x,%p)\n", > + TRACE( "(%d,%p,0x%08x,%p)\n", > data->idPlayer, data->lpCaps, data->dwFlags, data->lpISP ); > - return DPERR_UNSUPPORTED; > + Is it worth to test a NULL data?

1 0

Re: ntdll: Fix some more spec file entries
by Alexandre Julliard Feb. 24, 2017

Feb. 24, 2017

André Hentschel <nerv(a)dawncrow.de> writes: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/ntdll.spec | 10 +++++----- > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 4 ++-- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 66618fc..e666b90 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -101,7 +101,7 @@ > # @ stub NtAccessCheckByTypeResultList > # @ stub NtAccessCheckByTypeResultListAndAuditAlarm > # @ stub NtAccessCheckByTypeResultListAndAuditAlarmByHandle > -@ stdcall NtAddAtom(ptr long ptr) > +@ stdcall NtAddAtom(wstr long ptr) Functions that take a string length don't always get null-terminated strings so you don't want to print them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] ddraw/tests: Test depth fill results in test_color_fill().
by Marvin Feb. 24, 2017

Feb. 24, 2017

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=28861 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:10191: Test failed: Got unexpected color 0x00ffffff.

1 0

Re: SECURITY ALERT -- Remotely exploitable wine <= 2.x bugs via unencrypted plaintext HTTP intermediation
by Michael Müller Feb. 23, 2017

Feb. 23, 2017

Hello Kristian, it is true that the download is done via HTTP, but there is a checksum verification using a hardcoded hash value after the download. See http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/appwiz.cpl/addons.c for more details. It could be discussed whether sha1 is still considered secure enough, but I think there is a reason why it was chosen. Wine is modular and can be built without a cryptographic library (gnutls / CommonCrypto) and then lacks support for TLS and most hash functions. SHA1 is built into Wine though. Using this method guarantees that the download will also work in a minimal Wine built. Regards, Michael Am 02.02.2017 um 15:00 schrieb Kristian Erik Hermansen: > Hello Wine Maintainers :) > > Wine v2.x, and likely all earlier version, contain remotely > exploitable flaws because binaries are downloaded via insecure > plaintext HTTP and appear to contain insufficient signature > verification. This can occur when prompted to download missing files > such as Wine Gecko. The connection occurs over HTTP and can be > intermediated to compromise the client machine with a malicious > payload. Please advise if you are not already aware of this, when a > fix is planned, and if you need any additional information. Thanks :) >

2 1

Re: [PATCH 2/7] wined3d: Fix handling of SM4+ integer registers.
by Henri Verbeet Feb. 23, 2017

Feb. 23, 2017

On 23 February 2017 at 15:00, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -2972,40 +3016,27 @@ static void shader_glsl_add_src_param_ext(const struct wined3d_shader_instructio > shader_glsl_get_register_name(&wined3d_src->reg, glsl_src->reg_name, &is_color, ins); > shader_glsl_get_swizzle(wined3d_src, is_color, mask, swizzle_str); > > - if (wined3d_src->reg.type == WINED3DSPR_IMMCONST > - || wined3d_src->reg.type == WINED3DSPR_PRIMID > - || wined3d_src->reg.type == WINED3DSPR_LOCALTHREADINDEX > - || wined3d_src->reg.type == WINED3DSPR_THREADID > - || wined3d_src->reg.type == WINED3DSPR_THREADGROUPID > - || wined3d_src->reg.type == WINED3DSPR_LOCALTHREADID) > + switch (wined3d_src->reg.type) > { > - shader_glsl_gen_modifier(wined3d_src->modifiers, glsl_src->reg_name, swizzle_str, glsl_src->param_str); > + case WINED3DSPR_IMMCONST: > + param_data_type = data_type; > + break; This matches the existing behaviour, and in that regard this is fine, and it probably won't matter in practice, but note that shader_glsl_get_register_name() uses "reg->data_type", which isn't necessarily the same as "data_type" here. I think the usage of sprintf() is more problematic. That too matches the existing code, but we should be using string_buffer_sprintf() for this kind of thing.

1 0

Re: [PATCH 3/3] shell32: Added SHGetPathFromIDListEx implementation.
by Marvin Feb. 23, 2017

Feb. 23, 2017

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=28846 Your paranoid android. === wvistau64 (32 bit shlfolder) === shlfolder.c:457: Test failed: 0: got 7480017f expected 7080017f shlfolder.c:457: Test failed: 1: got f480017f expected 7080017f shlfolder.c:457: Test failed: 2: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 3: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 4: got 44400177 expected 40400177 === wvistau64 (64 bit shlfolder) === shlfolder.c:457: Test failed: 0: got 7480017f expected 7080017f shlfolder.c:457: Test failed: 1: got f480017f expected 7080017f shlfolder.c:457: Test failed: 2: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 3: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 4: got 44400177 expected 40400177 === w1064 (64 bit shlfolder) === shlfolder.c:4950: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) shlfolder.c:4933: Test failed: MKDIR: expected notification type 8, got: 40000 shlfolder.c:4940: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4950: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 8)

2 1

Re: msvcrt: Fix _CxxThrowException spec file entry
by Piotr Caban Feb. 23, 2017

Feb. 23, 2017

Hi, On 02/22/17 21:28, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt20/msvcrt20.spec | 2 +- > dlls/msvcrt40/msvcrt40.spec | 2 +- > dlls/msvcrtd/msvcrtd.spec | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) Could you please also change the _CxxThrowException spec entry in other msvcrXX/ucrtbase/... dlls? Thanks, Piotr

1 0