January 2013 - Wine-devel - list.winehq.org

Re: include: flesh out d3d11.idl (try 4)
by Dmitry Timoshkov 22 Jan '13

22 Jan '13

Austin English <austinenglish(a)gmail.com> wrote: > try 4: only include enough to add a stub for D3D11CreateDevice, You could also try to make it work for compilers that don't suppport anonymous unions. -- Dmitry.

1 0

Re: macdrv: implement getting and setting the screen saver state, version 6
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 5:33 PM, C.W. Betts wrote: > Yet another fix. Looks good to me. Thanks for doing this and for putting up with me. Cheers, Ken

1 0

macdrv: implement getting and setting the screen saver state. if(Style)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, Ken Thomases wrote: >> + if(success != kIOReturnSuccess) >Another style nitpick: please put a space between "if" and the condition. > That applies to the "if(count2)" above, too. I find this over the top. Where is the rule? Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine -- uses exactly 0 space between if and (). So what is it that the Wine "project" can tell new contributors? The only rule I see is: "Look at the code surrounding the patch" and its corollary: "if you create a new module, you're the first and define the style others will have to follow." Regards, Jörg Höhle

3 2

Re: macdrv: implement getting and setting the screen saver state, version 5
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 12:22 PM, C.W. Betts wrote: > This version should fix the problems you mentioned Sorry about this – I should have thought about this last time – but I think you shouldn't fall through in the SPI_SETSCREENSAVEACTIVE case. It's asking for trouble in the future, if anybody adds another case to the switch statement. I think it would be better to just explicitly return FALSE and put in a comment explaining why (like you suggested for the X11 driver). Thanks for your persistence! -Ken

1 0

Re: usp10: add ShapeCharGlyphProp_Latin to properly handle invalid and zero width character properties for Latin
by Alexandre Julliard 22 Jan '13

22 Jan '13

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/shape.c | 33 +++++++++++++++++++++++++++------ > 1 files changed, 27 insertions(+), 6 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:1407: Test failed: uJustification incorrect usp10.c:1410: Test failed: uJustification incorrect usp10.c:1411: Test failed: fClusterStart incorrect usp10.c:1414: Test failed: fClusterStart incorrect usp10.c:1190: Test failed: 0: uJustification incorrect (0) usp10.c:1190: Test failed: 0: fClusterStart incorrect (0) usp10.c:1190: Test failed: 3: uJustification incorrect (0) usp10.c:1190: Test failed: 3: fClusterStart incorrect (0) make[1]: *** [usp10.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dbghelp: Implement rudimentary stack walk for ARM64
by Eric Pouech 22 Jan '13

22 Jan '13

> + if ((frame->AddrPC.Mode == AddrModeFlat) && > + (frame->AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ -- Eric Pouech

2 3

RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, please view the winmm:wave test results from Francois Gouget's machines fg-acer64-t32 fg-acer64-wow32 fg-acer64-t64 fg-acer64-wow64 http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_… Is their configuration the same except for 32/64bit? We see 3 types of results 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI 1x: 3 devices incl. ALSA "default", all tests successful 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCATED Is their configuration truly the same? Is that yet another aretefact of ALSA device enumeration? It could well be. Again, I argue in favor of removing the enumeration code. I want users to get repeatable results. I don't want Wine's winmm to map device 0 as ALSA "default" on one run and "HDMI-An" on another run. Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html Of course, the winecfg/GUI issue need be addressed. Regards, Jörg Höhle

4 7

Re: [PATCH 6/8] winhttp: Added schannel-based netconn_get_cipher_strength implementation
by Hans Leidekker 22 Jan '13

22 Jan '13

On Tue, 2013-01-22 at 16:49 +0100, Jacek Caban wrote: > @@ -1460,6 +1460,13 @@ int netconn_get_cipher_strength( netconn_t *conn ) > pSSL_CIPHER_get_bits( cipher, &bits ); > return bits; > #else > - return 0; > + SecPkgContext_ConnectionInfo conn_info; > + SECURITY_STATUS res; > + > + if (!conn->secure) return 0; > + res = QueryContextAttributesW(&conn->ssl_ctx, SECPKG_ATTR_REMOTE_CERT_CONTEXT, (void*)&conn_info); That should be SECPKG_ATTR_CONNECTION_INFO.

2 1

winmm/tests: Allow more margin in the test_asyncWAVE() playback check.
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Francois, thank you for helping remove timing-caused flakiness from the tests. I believe you forgot to test your patch in Wine(!). The test + ok(400 <= p2 && p2 <= 600, "%ums is not in the expected 400-600ms range\n", p2); should fail in every version of Wine. Ironically, the reason is mentioned in your patch: /* Give Wine's asynchronous thread time to start up. Furthermore, * it uses 3 buffers per second, so that the positions reported * will be 333ms, 667ms etc. at best. */ IIRC, the first non-null position reported by Wine is 667ms, because it successfully queues two 333ms buffers to waveOut. I suggest adding a todo_wine plus an additional ok(0<p2 && strcmp(buf,"2000")) that Wine won't fail. And I'd decrease the sleep to e.g. 200 and 100 <= p2 && p2 <= 300 All those times sum up, the winmm test run long enough already. MCIWave should use winmm:waveOutGetPosition while playing, however the MCI devices hardly have any decent thread-safety and the construct if(status == MODE_PLAYING) waveOutGetPosition(hWave, &pos) else pos = stopped_pos; is unsafe, as the player may have exited meanwhile and closed hWave. It's a compatibility bug since day one of mciwave in git history that the position increments 3 times per second only. Yet so far, no app seems to have been bothered. Regards, Jörg Höhle

2 2

Re: macdrv: implement getting and setting the screen saver state. if(Style)
by Christian Costa 22 Jan '13

22 Jan '13

Well, 'grep "if(" * -r | wc -l' and 'grep "if (" * -r | wc -l'. :) 2013/1/22 Bruno Jesus <00cpxxx(a)gmail.com>: > Out of curiosity can you explain the shell wizardry you used to get the > stats? > > Thanks, > Bruno > > > On Tue, Jan 22, 2013 at 10:52 AM, Christian Costa <titan.costa(a)gmail.com> > wrote: >> >> 2013/1/22 <Joerg-Cyril.Hoehle(a)t-systems.com>: >> > Hi, >> > >> > Ken Thomases wrote: >> >>> + if(success != kIOReturnSuccess) >> >>Another style nitpick: please put a space between "if" and the >> >> condition. >> >> That applies to the "if(count2)" above, too. >> > >> > I find this over the top. Where is the rule? >> > Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine >> > -- >> > uses exactly 0 space between if and (). >> > >> > So what is it that the Wine "project" can tell new contributors? >> > >> > The only rule I see is: "Look at the code surrounding the patch" and >> > its corollary: "if you create a new module, you're the first and define >> > the style others will have to follow." >> > >> >> Hi, >> >> Just some stats regard "if" before Dan beat me at it ;) : >> - without space => 39979 >> - with space => 144133 >> >> The space is better to make the distinction between C keyword and >> function name. Off course it's a personal taste. :) >> >> Bye, >> Christian >> >> > > > > -- > universe* god::bigbang (void); //and then it all began...

1 0