March 2011 - Wine-Devel - list.winehq.org

Re: [02/10] msi/tests: Get rid of workarounds for win9x test failures.
by Marvin March 30, 2011

March 30, 2011

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 http://testbot.winehq.org/JobDetails.pl?Key=10212 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Rico Schüller March 30, 2011

March 30, 2011

Forwarding to the list. Am 28.03.2011 20:47, schrieb David Laight: >> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > > David > My example wasn't very well chosen. So conversation (casts) between the different types is necessary. It was meant the way to reuse some of the code. Because I think ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetFloatArray could share a lot of code. This will probably be the same for ID3DXConstantTable_SetBoolArray. Cheers Rico

1 0

Re: [01/10] msi: Ignore invalid upgrade codes in the PublishProduct action.
by Marvin March 30, 2011

March 30, 2011

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 http://testbot.winehq.org/JobDetails.pl?Key=10211 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6052: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Travis Athougies March 30, 2011

March 30, 2011

>> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > Exactly. Which is why I am not ever casting int pointers to float pointers as Rico suggested. Instead I'm looping through the array and casting each int to a float, which should invoke the machinery necessary to convert from the bit representation of an int to that of a float. > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > If I'm casting ints to floats (and not int pointers to float pointers) I don't see how this could be an issue. Travis -- Travis Athougies

1 0

[RFC] dinput: Length can actually be 0.
by Vincent Pelletier March 30, 2011

March 30, 2011

(Sorry for sending to wine-patches initially, it was intended for wnie-devel.) This fixes force feedback devices slamming for 10ms at full strength, as attack is an absolute value, not a factor of effect level. Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure which combination) cause the effect to be not played (possibly played with 0- level) on devices using the Linux iforce driver. This is the reason of the comment in the code. But to other drivers, such as hid-ff, this code causes the device to jump as full strength, which was reported (to me directly) for example when playing "Live for Speed"[1] with a steering wheel having strong force feedback (Logitech G27). My question: Is it acceptable to risk some regression for iforce driver (until bug is identified) to fix other devices ? I guess iforce devices also suffer from the too-strong attack/fade effect. [1] http://www.lfs.net (demo available, I didn't try it) --- dlls/dinput/effect_linuxinput.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c index fbc5994..0154f49 100644 --- a/dlls/dinput/effect_linuxinput.c +++ b/dlls/dinput/effect_linuxinput.c @@ -606,13 +606,12 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( else env = NULL; if (peff->lpEnvelope == NULL) { - /* if this type had an envelope, reset it - * note that length can never be zero, so we set it to something minuscule */ + /* if this type had an envelope, reset it */ if (env) { - env->attack_length = 0x10; - env->attack_level = 0x7FFF; - env->fade_length = 0x10; - env->fade_level = 0x7FFF; + env->attack_length = 0; + env->attack_level = 0; + env->fade_length = 0; + env->fade_level = 0; } } else { /* did we get passed an envelope for a type that doesn't even have one? */ -- 1.7.4.1

2 1

today's git failed to build for me
by Susan Cragin March 30, 2011

March 30, 2011

I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

3 2

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.
by David Adam March 29, 2011

March 29, 2011

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

1 0

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.
by Roderick Colenbrander March 29, 2011

March 29, 2011

I'm not sure if the only value error wglMakeCurrent should return is INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid context? The return value may be similar, but don't remember for sure. Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.
by Roderick Colenbrander March 29, 2011

March 29, 2011

The fact that a pixel format is not set on the physDev doesn't necessarily mean it is invalid, it just means SetPixelFormat wasn't called on it. Though slightly earlier in wglMakeCurrent we already catch that situation when compare the pixel format of the context and the hdc. Is there not something better for which we could check? Is the drawable of the physDev perhaps something to check for? (I have no idea in what state the physDev is after a destroy window; should we be able to enter x11drv at all? perhaps this should be handled inside the gdi32 code, just a thought) Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: wldap32: Accept a NULL value in ldap_set_option.
by Marvin March 29, 2011

March 29, 2011

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 http://testbot.winehq.org/JobDetails.pl?Key=10187 Your paranoid android. === WNT4WSSP6 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059 === W2KPROSP4 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059

1 0