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

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

11 Jan '12

Hi, you don't need a microphone, just a capture capable sound card, unlike testbot. Please download mmdevapi_test32|64.exe from testbot: http://testbot.winehq.org/JobDetails.pl?Key=16376 run: mmdevapi_test capture and post or send me the results -- not just the failures, the console output too including position/padding/flags. Don't be afraid of some test failures in lines 300-499. I'm still investigating underrun and start/stop/reset behaviour. Thank you for testing, Jörg Höhle

3 2

Re: mscoree: Implement DllGetClassObject
by Vincent Povirk 11 Jan '12

11 Jan '12

You can't just use a static class factory for all the classes. There's no need for GetIDispatchForObject when we already have GetIUnknownForObject (and all you use is QueryInterface). + res = RegGetValueA( key, NULL, "Class", RRF_RT_REG_SZ, NULL, classname, &dwBufLen); We should probably use a W function here and convert to utf8, rather than assume that's the default encoding.

2 2

Re: [PATCH 3/5] d3d9: Don't expose wined3d internal flags to the application.
by Alexandre Julliard 11 Jan '12

11 Jan '12

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/d3d9/buffer.c | 4 ++-- > dlls/d3d9/cubetexture.c | 2 +- > dlls/d3d9/surface.c | 2 +- > dlls/d3d9/texture.c | 2 +- > dlls/d3d9/volume.c | 2 +- > dlls/d3d9/volumetexture.c | 2 +- > 6 files changed, 7 insertions(+), 7 deletions(-) This is causing test failures: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so mesh.c && touch mesh.ok mesh.c:331: Test succeeded inside todo block: Test createmesh1, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmesh2, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmeshfvf, result 0, expected 0 mesh.c:2497: Tests skipped: D3DXCreateBox failed mesh.c:331: Test succeeded inside todo block: Test sphere (0, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 4, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (5, 6, 7), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (10, 11, 12), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (0, 0, 0, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 1, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 2, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 2, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (2, 3, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 4, 5, 11, 20), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 340282346638528859811704183484516925440.000000, 0.400000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 340282346638528859811704183484516925440.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.000000, 1.000000), result 0, expected 0 make: *** [mesh.ok] Error 21 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: httpapi: add method stub for HttpAddUrl()
by Nikolay Sivov 11 Jan '12

11 Jan '12

On 1/11/2012 13:41, Arash Cordi wrote: > + > +ULONG WINAPI HttpAddUrl( HANDLE handle, PCWSTR url, PVOID reserved ) > +{ > + FIXME( "(%p %p %p): stub!\n", handle, url, reserved); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + Please use %s format for 'url' so it will be visible in logs.

2 1

What other conferences do Wine people attend?
by Dan Kegel 11 Jan '12

11 Jan '12

In the wineconf thread, the question came up: What other conferences people do wine developers/users attend, if any? If you send me the names of the conference(s) you attended in the last two years, I'll summarize for the list.

5 4

Re: cryptui: Use the same capitalization for the same string
by Francois Gouget 11 Jan '12

11 Jan '12

On Tue, 10 Jan 2012, André Hentschel wrote: > So that the string needs only one translation in po files - GROUPBOX "Certification path", -1,6,10,245,165, BS_GROUPBOX + GROUPBOX "Certification Path", -1,6,10,245,165, BS_GROUPBOX Unfortunately this goes against the Windows User Experience Interaction Guidelines. Group box labels are supposed to use sentence-style capitalization: http://msdn.microsoft.com/en-us/library/aa511459.aspx But dialog box titles are supposed to use title-style capitalization, hence the case difference: http://msdn.microsoft.com/en-us/library/aa511268.aspx#titles Glossary: * Sentence-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#SentenceCaps * Title-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#TitleCaps -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

1 1

Re: [2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)
by Vitaliy Margolen 10 Jan '12

10 Jan '12

On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote: > From: Lucas Fialho Zawacki<lfzawacki(a)gmail.com> > > +static BOOL _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) I don't think this is such a good idea to mix ASCII and WCHAR parameters. > + static WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Why do you think it should be there in the first place? > + expanded_path = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*expanded_path_size); No error checking. > +static HRESULT _save_mapping_settings(IDirectInputDevice8W *iface, LPDIACTIONFORMATW lpdiaf, LPCWSTR lpszUsername) > +{ > + static WCHAR mapexists[] = {'M','a','p','E','x','i','s','t','s','\0'}; > + static WCHAR numactions[] = {'N','u','m','A','c','t','i','o','n','\0'}; Should be "static const WCHAR". > + IDirectInputDevice8_GetDeviceInfo(iface,&didev); No error checking. > + va_start(args, format); > + while (1) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, size); > + if (buffer == NULL) > + break; > + n = vsnprintfW(buffer, size, formatW, args); > + if (n == -1) > + size *= 2; > + else if (n>= size) > + size = n + 1; > + else > + break; > + HeapFree(GetProcessHeap(), 0, buffer); > + } > + va_end(args); You can't do this. It seems to be you have not tested it with initial buffer too small. You have to do va_start & va_end every time you pass "args" to another function. > + > + if (buffer == NULL) return NULL; > + ret = HeapReAlloc(GetProcessHeap(), 0, buffer, sizeof(WCHAR)*(strlenW(buffer)+1) ); > + if (ret == NULL) ret = buffer; Why reallocate? It's pointless. > +extern WCHAR* _get_mapping_path(const WCHAR *device, const WCHAR *username) DECLSPEC_HIDDEN; Would you please drop leading underscore from all of your function names? Vitaliy.

2 2

RFH: Applications that call stuff from DllMain
by Andrew Eikum 10 Jan '12

10 Jan '12

This mail is about bugs 28042[1] and 28677[2]. In short, what I'm trying to deal with is buggy applications that make calls to DSound and WinMM from within DllMain(), causing deadlocks. On almost any entry into DSound or WinMM's wave functions, the modules launch a thread to communicate with MMDevAPI. We create a new thread for two reasons. First, to CoInitialize() the thread, which we shouldn't do on a user thread. Second, the MMDevAPI docs say that the device objects should be created and destroyed from the same thread[3], which we can't guarantee if we create them on a user thread (I think dsound currently violates this, actually). Wine holds the loader critical section during calls to DllMain(). However, launching a new thread requires using the loader, and so we hit a deadlock. This is the problem reported by these bugs. While we might be able to perform some of these functions without launching a new thread, I'm not sure that that's a general solution, since we will have to launch a thread at some point. Analysis on Windows 7 shows that DirectSoundEnumerate() does not launch any additional threads, but mixerGetNumDevs() actually does launch a thread, yet the application still launches successfully. So, I'm asking for insights. Should I try hard to avoid launching threads unless absolutely necessary? Is this a known deficiency in the loader, and I should do nothing? Is there some other way to work around this? Thanks, Andrew [1] http://bugs.winehq.org/show_bug.cgi?id=28042 [2] http://bugs.winehq.org/show_bug.cgi?id=28677 [3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=VS.85%…

3 4

Re: winmm: GetCurrentPadding is superfluous while recording.
by Alexandre Julliard 10 Jan '12

10 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > now winmm recording does not depend on chunking by mmdevapi. > > + if(packet > 0) > + WARN("losing %u frames\n", packet); > That part is interesting. Another approach would have been to check whether > all of GetData could be stuffed into winmm buffers and use ReleaseBuffer(0) if not > (much more complicated in the presence of several buffers). > > As long as winmm supplies enough buffers in advance, that doesn't matter. > > With that in place, the "Fix AudioCaptureClient protocol" patches can be applied on > the winmm side. I have not checked the dsound code. > > I'm sorry winmm:ACMPullData was broken by my former notification patch. I'll have to fix that. > ACMPullData is also not very robust (return; after GetBuffer will prevent any subsequent GetBuffer > with OUT_OF_ORDER). It doesn't work here: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok [...] err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 etc. forever -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] wineoss.drv: Fix IAudioRenderClient::{Get,Release}Buffer protocol
by Joerg-Cyril.Hoehle＠t-systems.com 10 Jan '12

10 Jan '12

Andrew Eikum wrote: >I think the GetPosition and GetCurrentPadding failures are caused by >using GETOSPACE instead of GETODELAY in GetPosition(). Please write that patch too. It needs good testing to get the start/stop/underrun corner cases right. My hope is that Wine-1.4.0 will have 3 drivers of comparable if not equal quality. What I plan is to submit my render patch with almost all GetPosition tests lifted behind if(winetest_debug>1): render.c:1062: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. This one perhaps should move as well, although it indicates a problem. render.c:1166: Test failed: Position should have been further along... render.c:1227: Test failed: GetCurrentPadding returned 512, should be 0 No idea, please check. render.c:1228: Test failed: Position 142756 at end vs. 143268 submitted frames In shared mode, the end position must be the sum of released frames. In exclusive mode, I've seen some cards return a little less. Your RenderClient patch looks good. Regards, Jörg Höhle

2 1