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

Vista/w2k8/w7 + ALSA users, please test mmdevapi capture
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '12

12 Jan '12

Hi, Thanks to all five users who sent me data. I've a new testbot job. Please download mmdevapi_test32|64.exe http://testbot.winehq.org/JobDetails.pl?Key=16386 you don't need a microphone, just a capture capable sound card, unlike testbot. there should be next to 0 failures in lines 200-410. Failures in 411-600 (function test_capture2) are not interesting. It would be good to repeat the test a few times to see whether there's a random failure. Also, please compare mmdevapi_test[64].exe capture with mmdevapi_test[64].exe capture > capture.log Redirecting to a file leads to vastly different results (in the render tests) because output to the MS-DOS shell is extremely slow and thus affects timing. On a 64bit machine, you may also compare the output of both executables. The behaviour is apparently not the same! On Unix with ALSA, you may try my latest patches from source.winehq.org/patches and see if it works for you. - Stop without snd_pcm_drop patch - Reset accounting patch - CaptureClient protocol patch I'm at 0 failures (ignoring test_capture2) and a few todo with dmix and 0-1 (random) with PulseAudio. Please post or send me the results -- not just the failures, the console output too including position/padding/flags. Thank you for testing, Jörg Höhle

3 2

Re: [PATCH 1/5] ddraw/tests: Add some clipper tests.
by Saulius Krasuckas 12 Jan '12

12 Jan '12

* On Wed, 4 Jan 2012, Henri Verbeet wrote: > --- > dlls/ddraw/tests/ddraw1.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw4.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 866 insertions(+), 0 deletions(-) It's http://source.winehq.org/git/wine.git/commitdiff/3997457574a0e3f1c2fa095e23… These tests fail on real machines (running XP and w7) with nVidia cards (FX5200 and GF 310M): http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/index_… http://test.winehq.org/data/a86b765a50cdf76e66c8993977f892d825f52ec0/index_… On XP + FX5200 the first three tests (dd1, dd2, dd4) generates crash with failing hr = 0x8876021c. The other cases just fail by some color matches. Plus, tests fail on one WTB machine running XP with russian localisation + "VMware SVGA II" v11.6.0.35 in yet different way: http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/xp_wtb… Other virtual XP machines do OK with similar setup. My humble guess -- that's just one broken setup out of many virtual machines. Henri, would you be as kind as to fix the tests:)? S.

2 2

Re: [2/2] msvcrt: Forward strftime() to wcsftime(). Take 2.
by Alexandre Julliard 12 Jan '12

12 Jan '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > + len = MultiByteToWideChar( CP_ACP, 0, format, -1, NULL, 0 ); > + if ((fmt = MSVCRT_malloc( len * sizeof(MSVCRT_wchar_t) ))) > + { > + MultiByteToWideChar( CP_ACP, 0, format, -1, fmt, len ); > + > + if ((len = MSVCRT_wcsftime( s, max, fmt, mstm ))) > + { > + len = WideCharToMultiByte( CP_ACP, 0, s, len, str, max, NULL, NULL ); > + if (len < max) str[len] = 0; > + } The overflow handling still looks suspicious. It probably needs some more test cases. -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: mscoree: Implement DllGetClassObject (try 2)
by Vincent Povirk 12 Jan '12

12 Jan '12

You're still using a single static class object, and I'm not convinced GetIDispatchForObject is a good idea. On Wed, Jan 11, 2012 at 5:02 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Use RegGetValueW for the class. > > Changelog: > mscoree: Implement DllGetClassObject > > > Best Regards > Alistair Leslie-Hughes > > > >

1 0

[PATCH 5/8] dsound: Make capture behave like native in regards to COM aggregation.
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '12

12 Jan '12

Hi, Michael Stefaniuc wrote: >static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer + if (pUnk) { + WARN("invalid parameter: pUnk != NULL\n"); + /* *lplpDSCaptureBuffer = NULL; Not done by native dsound */ + return DSERR_NOAGGREGATION; + } What's your rationale for doing so? Bug compatibility with native is fine, however not setting NULL is problematic before you've reached 100% compatibility, have you? What I mean is that if there's a situation where Wine's CreateCaptureBuffer returns some DSERR such as NOTIMPL where native does not, then that's an unexpected situation for the app which it may not be well prepared to handle, as it is untestable on native. Now not zeroing output pointers may make it even harder for the app to remain in sane state. Then blame the app or Wine for a crash? If OTOH you know that the Wine module *always* returns the exact same values as native, then I've no objection in not zeroing output pointers when native does neither. Yet you'll have to consider that native may do so in the future, witness a growing number of MSDN documents covering later APIs that specifically mention zeroing pointers in case of failure. IIRC, AJ removed from my mmdevapi tests one snippet that showed that native's GetService does not zero an output pointer even though MSDN says so -- Wine zeroes. Yet perhaps I got confused, messed up with patches and submitted the one that did not contain that test so maybe AJ never had a chance to see it. I'll have to check that. Regards, Jörg Höhle

3 3

Re: jscript: Don't use break in funally block on pre-IE8 jscript
by Marvin 12 Jan '12

12 Jan '12

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=16400 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

Interesting - performance issues in Natural Selection 2 dedicated server
by Scott Ritchie 12 Jan '12

12 Jan '12

The game is still in beta development, but I just learned something odd - there are no Linux server binaries (yet), and a lot of admins are running the dedicated server using Wine. Wine works, but is actually performing fairly poorly here. I find this really interesting, as the dedicated server isn't graphical in any way. Would profiling here be worthy of pursuing? Are there known areas of bad performance other than graphics? Thanks, Scott Ritchie

2 1

Re: [PATCH] mshtml: Add interface for nsIWebBrowserChrome2 and 3
by Jacek Caban 12 Jan '12

12 Jan '12

Hi Detlef, Why do you add them? nsiface.idl should contain only interfaces that we use. Otherwise it's just adding me more work on each Gecko merge. Jacek

1 0

d3dx9: Implement D3DXCreatePolygon
by David Adam 11 Jan '12

11 Jan '12

Hello are there still problems with the patches: http://source.winehq.org/patches/data/82408 and http://source.winehq.org/patches/data/82409 ? Thanks in advance A+ David

1 0

MacOS recording audio - chunking 4096 frames
by Joerg-Cyril.Hoehle＠t-systems.com 11 Jan '12

11 Jan '12

Hi, looking at mmdevapi/tests/capture logs, I found 2 issues 1. the 5 buffers initially sent are all returned with 0 bytes So I added a loop to return empty buffers to the audio input queue, such that GetBuffer returns data when GetCurrentPadding shows it. But why were these buffers returned at all? Why initially submit the buffers if they are always returned empty? 2. Using a ~500ms mmdevapi duration, Wine gave MacOS CoreAudio 5 buffers of ~4399 frames each. However, MacOS solely returned 4096 frames. Is anybody aware of such chunking? I'd like to know about such chunking, because IMHO the correct way to handle it would be to advertise mmdevapi's a matching default recording period -- obviously not 10ms. I believe the current mmdevapi code did not expect that behaviour and therefore does not manage to fill as much frames as GetBufferSize would allow into a buffer. I haven't checked smaller buffers. I'd like to avoid bombarding CoreAudio with 10ms buffer requests of 480 frames each just because native mmdevapi advertises a 10ms period. Thank you for your help, Jörg Höhle

2 1