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

Re: gdi32: Add an EnumFontFamilies test to see how it handles various font faces.

by Marvin

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=9230 Your paranoid android. === WNT4WSSP6 (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === W2KPROSP4 (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === WXPPROSP3 (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === W2K3R2SESP2 (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === WVISTAADM (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === W2K8SE (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated === W7PRO (32 bit font) === font.c:3495: Test failed: expected Arial Bold got Arial font.c:3545: Test failed: font Arial Bold should not be enumerated font.c:3495: Test failed: expected Arial Bold Italic got Arial font.c:3553: Test failed: font Arial Bold Italic should not be enumerated

Feb. 13, 2011

Re: wined3d: Remove an old hack around Mesa choking on protected memory from flush_to_framebuffer_drawpixels.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, go ahead and kill this hack Am 13.02.2011 um 00:46 schrieb Gerald Pfeifer: > This somehow got stuck from the original discussion we had a year ago. > > This is in response to Stefan's feedback > (http://www.winehq.org/pipermail/wine-devel/2010-May/083480.html) > for a previous version of this patch of mine > (http://www.winehq.org/pipermail/wine-patches/2010-May/088229.html) > > Either my original patch or this new one (or a variation thereof) > should be applied. Stefan, I hope it got you right? > > Gerald > > --- > dlls/wined3d/surface.c | 17 ----------------- > 1 files changed, 0 insertions(+), 17 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 4377f10..b7f4b1c 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -1960,23 +1960,6 @@ static void flush_to_framebuffer_drawpixels(IWineD3DSurfaceImpl *This, > glRasterPos3i(rect.left, rect.top, 1); > checkGLcall("glRasterPos3i"); > > - /* Some drivers(radeon dri, others?) don't like exceptions during > - * glDrawPixels. If the surface is a DIB section, it might be in GDIMode > - * after ReleaseDC. Reading it will cause an exception, which x11drv will > - * catch to put the dib section in InSync mode, which leads to a crash > - * and a blocked x server on my radeon card. > - * > - * The following lines read the dib section so it is put in InSync mode > - * before glDrawPixels is called and the crash is prevented. There won't > - * be any interfering gdi accesses, because UnlockRect is called from > - * ReleaseDC, and the app won't use the dc any more afterwards. > - */ > - if ((This->flags & SFLAG_DIBSECTION) && !(This->flags & SFLAG_PBO)) > - { > - volatile BYTE read; > - read = This->resource.allocatedMemory[0]; > - } > - > /* If not fullscreen, we need to skip a number of bytes to find the next row of data */ > glPixelStorei(GL_UNPACK_ROW_LENGTH, This->currentDesc.Width); > > -- > 1.7.2.2 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNV2TrAAoJEN0/YqbEcdMwb5EQAIhXIczJL8JYsElaRDXH0kmc k7knkDu35OE0Rp4wBlqt51BdO9V/bcUzJsNFU5OFmtFgDQsHabNZV/EYvp2mU62D PDqvbsSWPM1L+LeWw/atjZb4Q5nYg9MH01a2JsDct1YtpkN9CNxakxalWwF6HpSX r2sMFn38N5/awWqcOS5GQGn348Ak1igzdQGwcHSM/LK/LeuuNZE5r3OOgAgzxheq /GISFCQ8T0G+UJDcOpGptW7ZjHVeHY1CNFA+HbXcfPJYiUDsZZhnsjy1MehEy0gE hvrdikWkwnTiAKRjqjriXuz0M7ktZXpzfnjipuZC5MSPqzhncck4GE9JuAeRx8HF eDX/O+gLsJ+TBNfpxBKmLi/ZfFMa/x12yLk76UULDmzQ1kpSHs5UIkSptYUs3Bwg IfQAoMydXH6HMcXWD+la3N3O2MdVVvIVaKGz1GSqPPLA4EVz1UobDmXQBcJ0YTzf RO5dlu6HmbiuR8dD89CdH3eguOldLK0u4BcK/3wJjzgjquspLO24cnlK+/AfIUnw w+oXcPFULbyiok99kUmQ01DkvLasMj4GVFHRxjN69iPgL8Ofed7Yfp/eX0qRu5MK k6bZnx/XqgeuQaSeNzKXgAtQgRM0oPKsA4dgVcda8gHdZRVUxdFDjlF+0gB+8N5d KD0hY4wjYd/67FwtDhEP =B0mG -----END PGP SIGNATURE-----

Feb. 13, 2011

Re: comctl32/tests: Add two casts to avoid comparisons of different int types.

by Gerald Pfeifer

On Sun, 13 Feb 2011, Marvin wrote: > 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=9229 > > Your paranoid android. > > > === W7PROX64 (64 bit tab) === > tab.c:1330: Test failed: got 69cc80, expected dededede Hmm, looking at this my patch changes ok(*(ULONG_PTR*)g_drawitem.itemData == lparam, "got %lx, expected %lx\n", gdrawitem.itemData, lparam); to ok(*(ULONG_PTR*)g_drawitem.itemData == (ULONG)lparam, "got %lx, expected %lx\n", g_drawitem.itemData, lparam); That is, the only difference is the (ULONG) cast. Given the output above, my patch did not trigger this failure since based on the printing of the two values they are different. Gerald

Feb. 13, 2011

Re: comctl32/tests: Add two casts to avoid comparisons of different int types.

by Marvin

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=9229 Your paranoid android. === W7PROX64 (64 bit tab) === tab.c:1330: Test failed: got 69cc80, expected dededede

Feb. 13, 2011

Re: Fixed GetDIBits for top-down bitmaps.

by Marvin

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=9225 Your paranoid android. === WNT4WSSP6 (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W2KPROSP4 (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === WXPPROSP3 (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W2K3R2SESP2 (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === WVISTAADM (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W2K8SE (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W7PRO (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W7PROX64 (32 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline. === W7PROX64 (64 bit bitmap) === bitmap.c:3090: Test failed: Bottom-up -> bottom-up should have first scanline. bitmap.c:3096: Test failed: Bottom-up -> top-down should have first scanline.

Feb. 13, 2011

test_TCS_OWNERDRAWFIXED in dlls/comctl32/tests/tab ?

by Gerald Pfeifer

test_TCS_OWNERDRAWFIXED in dlls/comctl32/tests/tab has the following code: LPARAM lparam, lparam2; : lparam = 0; memset(&lparam, 0xde, 4); memset(&lparam2, 0xde, sizeof(LPARAM)-1); ok(g_drawitem.itemData == lparam || broken(g_drawitem.itemData == lparam2) /* win98 */, "got 0x%lx, expected 0x%lx\n", g_drawitem.itemData, lparam); I have two questions on this. First, why does the memset use the constant 4 and not sizeof(LPARAM)? Second, why initialize lparam with 0 when this is immediately followed by a memset covering it's fully size? Third, lparam2 is partially uninitialized and will have a couple of random bits from all I can tell since lparam2 is never initialized and the memset only covers a portion of it. I'm wondering, should lparam = 0 just read lparam2 = 0? Whatever may be the case, the current code does not look right. Gerald

Feb. 12, 2011

Re: .chm files for builtin programs?

by Saulius Krasuckas

* On Sat, 12 Feb 2011, Jacek Caban wrote: > * On 2/11/11 5:06 AM, Dan Kegel wrote: > > > > I think there's an open source .chm compiler at > > http://sourceforge.net/projects/chmc/ > > Haven't tried it yet. If that doesn't work, we can use Microsoft's hhc. > > The right way to add chm file is implementing .chm compiler as a plain UNIX > application chmc is such already. > and use it in build time to product .chm files. BTW, can't it be integrated into the make process so the .chm files get compiled right after the programs/ folder have been built? S.

Feb. 12, 2011

Re: winex11.drv: map_window should honor iconic state

by Alexandre Julliard

Alexander Lakhin <exclusion(a)gmail.com> writes: > I've checked XWMHints just before XMapWindow call and received the correct initial_state (IconicState) and flags (StateHint set) there. > But the window still displayed not in a minimized state. To isolate the issue I tried the following code snippet: > ... > XWMHints *wm_hints = XAllocWMHints(); > wm_hints->initial_state = IconicState; > wm_hints->flags = StateHint; > XSetWMHints( display, win, wm_hints ); > > XMapWindow( display, win ); > ... > And the window was not minimized again. After some research I found the following explanation to it: > http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00020.html No, this has nothing to do with it. While IconicState can mean different things for different window managers, it shouldn't make a difference whether it's set as initial state or changed after the fact. If initial state is set correctly then the bug is in your window manager. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

On Fri, Feb 11, 2011 at 5:16 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Freitag 11 Februar 2011, 22:39:05 schrieb David Laight: >> The 'usual' non-IEEE fp systems are vax (you probably can't put enough >> memory in a vax to run wine!) and some arm systems where the two 32bit >> words of a double aren't stored in the expected order! > I don't expect to find any non-IEEE system where wine runs in the near future, > or maybe in our lifetime. Its just that this function goes to great lengths to > make sure it doesn't rely on the actual encoding that it is annoying that we > have to give it up for detecting the sign of zeroes. > > If anything I'd say lets just make the actual sign depend on the bits: > > if(in == 0.0) > { > if( ((unsigned int) in) == 0x00000000) return 0x0000; > else return 0x8000; > } > That way if a crazy system crosses our way that happens to encode 42.0 as > 0x80000000 we'll get it right and just get the sign of zeroes wrong. However, > I'd be glad if we had a really foolproof function. > > ----------- > > For IEEE systems we could optimize the entire routine, protected by ifdefs: > 1) Pick apart the 32 bit float like we do in the 16->32 case > 2) Shift mantissa and exponent a bit to the right, taking care of rounding > 3) Put them together as 16 bit > 4) profit! > > No exp() and other stuff needed. > Ok guys, I get it. We are trying to have the function work on non-IEEE systems. How about the attached. It's basically if (in == 0.0f) return (sign ? 0x8000 : 0x0000); Seems to work: https://testbot.winehq.org/JobDetails.pl?Key=9224 What do you think? Misha

Feb. 12, 2011

Re: winex11.drv: map_window should honor iconic state

by Alexander Lakhin

> Alexander Lakhin<exclusion(a)gmail.com> writes: > >> + data->iconic = (new_style& WS_MINIMIZE) != 0; >> + >> if (!data->embedded) >> { >> update_net_wm_states( display, data ); >> sync_window_style( display, data ); >> wine_tsx11_lock(); >> XMapWindow( display, data->whole_window ); >> + if (data->iconic) >> + XIconifyWindow( display, data->whole_window, DefaultScreen(display) ); > This is handled by setting the initial window state in the wm hints. If > there's somewhere that the state isn't set correctly, that's what should > be fixed. > Hello, Alexandre. I've checked XWMHints just before XMapWindow call and received the correct initial_state (IconicState) and flags (StateHint set) there. But the window still displayed not in a minimized state. To isolate the issue I tried the following code snippet: ... XWMHints *wm_hints = XAllocWMHints(); wm_hints->initial_state = IconicState; wm_hints->flags = StateHint; XSetWMHints( display, win, wm_hints ); XMapWindow( display, win ); ... And the window was not minimized again. After some research I found the following explanation to it: http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00020.html So it seems that the only way to minimize a window is to call XIconifyWindow. Best regards, Alexander

Feb. 12, 2011

Re: .chm files for builtin programs?

by Jacek Caban

On 2/11/11 5:06 AM, Dan Kegel wrote: > Hi all, > The native dxdiag uses a .chm file for its help system, > so ours might as well, too. > I see there's a .chm file checked in to git (in dlls/itss/tests). > Any objection to checking a .chm file into programs/dxdiag, > along with its source files and script to build it? > > I think there's an open source .chm compiler at > http://sourceforge.net/projects/chmc/ > Haven't tried it yet. If that doesn't work, we can use Microsoft's hhc. The right way to add chm file is implementing .chm compiler as a plain UNIX application and use it in build time to product .chm files. It's a proposed GSoC for a few years now (even there was one failed attempt in implementing it). Jacek

Feb. 12, 2011

Please reject patch 71094 it is wrong.

by Alexander Kochetkov

71094 New Alexander Kochetkov [resend] gdi32: Text output of records EMR_EXTTEXTOUTA/W depend on field iGraphicsMode

Feb. 12, 2011

Re: [PATCH 2/2] msvcrt: Implement _strnicoll.

by Eryk Wieliczko

Please reject this set as it is obviously wrong. -- Eryk Wieliczko 2011/2/11 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > >> /********************************************************************* >> + * _strnicoll (MSVCRT.@) >> + */ >> +int CDECL MSVCRT__strnicoll(const char* str1, const char* str2, int digits) >> +{ >> + int res; >> + >> + res = strncmp(str1, str2, digits); >> + if (res > 0) >> + res = 1; >> + else if (res < 0) >> + res = -1; >> + >> + return res; >> +} > > The API name implies case insensitive comparison, please add the tests > for that. > > -- > Dmitry. > > >

Feb. 12, 2011

d3dx9_36 [resend]: Add a few tests for D3DXCreateBox

by David Adam

Hello, no feedback available for this patch? It was rejected silently. A+ David ---------- Forwarded message ---------- From: David Adam <david.adam.cnrs(a)gmail.com> Date: 2011/2/9 Subject: d3dx9_36 [resend]: Add a few tests for D3DXCreateBox To: wine-patches <wine-patches(a)winehq.org> Fixed following Stefan's advices. A+ David

Feb. 12, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by David Laight

On Fri, Feb 11, 2011 at 11:16:55PM +0100, Stefan D?singer wrote: > .... Its just that this function goes to great lengths to > make sure it doesn't rely on the actual encoding that it is annoying that we > have to give it up for detecting the sign of zeroes. In that case why not? int is_neq_z(double x) { union { char i[sizeof (double)]; double d; } ux, u0; int i; if (x != 0.0) return 0; u0.d = 0.0; ux.d = x; for (i = 0; i < sizeof (double); i++) { if (ux.i[i] != u0.i[i]) return 1; } return 0; } Which works provided that there are only 2 encoding patterns for zero. David -- David Laight: david(a)l8s.co.uk

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

Am Freitag 11 Februar 2011, 22:39:05 schrieb David Laight: > The 'usual' non-IEEE fp systems are vax (you probably can't put enough > memory in a vax to run wine!) and some arm systems where the two 32bit > words of a double aren't stored in the expected order! I don't expect to find any non-IEEE system where wine runs in the near future, or maybe in our lifetime. Its just that this function goes to great lengths to make sure it doesn't rely on the actual encoding that it is annoying that we have to give it up for detecting the sign of zeroes. If anything I'd say lets just make the actual sign depend on the bits: if(in == 0.0) { if( ((unsigned int) in) == 0x00000000) return 0x0000; else return 0x8000; } That way if a crazy system crosses our way that happens to encode 42.0 as 0x80000000 we'll get it right and just get the sign of zeroes wrong. However, I'd be glad if we had a really foolproof function. ----------- For IEEE systems we could optimize the entire routine, protected by ifdefs: 1) Pick apart the 32 bit float like we do in the 16->32 case 2) Shift mantissa and exponent a bit to the right, taking care of rounding 3) Put them together as 16 bit 4) profit! No exp() and other stuff needed.

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by David Laight

On Fri, Feb 11, 2011 at 10:20:10PM +0100, Stefan D?singer wrote: > Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev: > > > + if (*((unsigned int *)&in) == 0x00000000) return 0x0000; > > + if (*((unsigned int *)&in) == 0x80000000) return 0x8000; > Thinking about it, there's something about this line that is not so nice: It > relies on the actual encoding of the float, which may technically be platform > specific if there's a CPU that implements non-IEEE- 754 floats. The 'usual' non-IEEE fp systems are vax (you probably can't put enough memory in a vax to run wine!) and some arm systems where the two 32bit words of a double aren't stored in the expected order! Some embedded systems might not bother with denormalised encodings for values near zero. I don't know if anything uses an abolute offset to avoid that gap (the main difference between aLaw anf uLaw audio). It also requires that the compiler use stricter data aliasing rules than are required by the C standard. Using a union is ok (but you must write and read a union variable, not just cast to a union type. David -- David Laight: david(a)l8s.co.uk

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev: > + if (*((unsigned int *)&in) == 0x00000000) return 0x0000; > + if (*((unsigned int *)&in) == 0x80000000) return 0x8000; Thinking about it, there's something about this line that is not so nice: It relies on the actual encoding of the float, which may technically be platform specific if there's a CPU that implements non-IEEE- 754 floats. You could try something like this(pseudo code, I removed the *s) if(in == 0.0) { if(sign(1.0 / in) == positive) return 0x0000; else return 0x8000; } The idea is that 1.0 / 0.0 returns Inf and 1.0 / -0.0 -Inf. I may be mistaken about that though.

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

On Fri, Feb 11, 2011 at 3:58 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev: >> Stefan et al: >> >> Thank you. How about this guy? > >> + if (exp > 31) >> + { >> + /* too big */ >> + ret = 0x7fff; /* INF */ >> + } > That's not INF, that is NaN. Or, if you don't read it as a special value the > highest possible positive number in a float16 format that doesn't understand > NaNs or INFs > > Otherwise it looks OK > Thank you. Misha

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev: > Stefan et al: > > Thank you. How about this guy? > + if (exp > 31) > + { > + /* too big */ > + ret = 0x7fff; /* INF */ > + } That's not INF, that is NaN. Or, if you don't read it as a special value the highest possible positive number in a float16 format that doesn't understand NaNs or INFs Otherwise it looks OK

Feb. 11, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

On Wed, Feb 9, 2011 at 4:40 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Dienstag 08 Februar 2011, 22:45:52 schrieb Misha Koshelev: >> I don't have msvc. Please suggest how I can check this. Thank you. Yours >> Misha > According to http://www.johndcook.com/math_h.html it exists, but has a > different name. So we'd need some wrapper around it in libwine. Maybe one > exists already, I can't check right now. If not I recommend to stick to > isnan() and isinf() > Stefan et al: Thank you. How about this guy? I'm using isnan(), isinf(), and a hex comparison for +0.0f and -0.0f. Misha

Feb. 11, 2011

Re: [rfc] dsound: decrease sound latency

by Austin English

On Fri, Feb 11, 2011 at 01:43, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Hi all, > > Please test this and let me know if it's causing any problems in sound > playback, preferably with media applications and games, any feedback would > be appreciated. The patch won't fix existing problems, it should just > decrease the audio lag. As such I would prefer only to receive feedback on > issues INTRODUCED or FIXED by this patch. > > If it's causing issues, I want to know: > 1. Whether pulseaudio is running, and pulseaudio --version > 2. What distribution you're using > 3. (If you know it) the version of alsa's libraries, packages libasound2 and > libasound2-plugins in debian/ubuntu I sent this to wine-users, but just for the record, you can set the values in the registry, if compiling is inconvenient for some reason: [HKCU\\Software\\Wine\\DirectSound] "SndQueueMax"="4" "SndQueueMin"="4" -- -Austin

Feb. 11, 2011

Re: iphlpapi: Hint what to do when icmp does not work

by Charles Davis

On 2/11/11 11:31 AM, Janne Hakonen wrote: > Maybe this information could be added to http://wiki.winehq.org/FAQ > instead? Judging from wine-users, nobody bothers to read that, at least until someone tells them to. For that matter, nobody bothers to read the logs either. It's kinda sad, actually. Most users on wine-users expect someone else to read the logs for them and then magically fix everything. No, it's worse than that: all they usually see is that something bad happened, and then they post to wine-users and somebody has to *tell* them to post logs. (And there's probably a sticky on the forum telling them to do that!) And like I said, they don't even look at the log; they just copy from Terminal (or Konsole, or whatever xterm-like app they use) and paste into their email or forum post, and never even bother to see what the log actually says because it's all gibberish to them. So then the people who actually know what they're doing have to sift through the log for them, and they can't be too happy about that. On second thought, maybe it would be best if we put it into the FAQ. At least then the forum moderators can post a terse "look in the FAQ" response. Like I said earlier, we certainly shouldn't print this message unconditionally to the winediag channel. Also, for the future, I recommend bottom-posting instead of top-posting. Just a little style note. Chip

Feb. 11, 2011

Re: iphlpapi: Hint what to do when icmp does not work

by Janne Hakonen

Maybe this information could be added to http://wiki.winehq.org/FAQ instead? Janne -----Original Message----- From: Charles Davis Sent: Friday, February 11, 2011 8:17 PM To: wine-devel(a)winehq.org Subject: Re: iphlpapi: Hint what to do when icmp does not work On 2/11/11 11:12 AM, André Hentschel wrote: > Otherwise the user might try running wine as root or doesn't know that > this error can be easily fixed when needed. > --- > dlls/iphlpapi/icmp.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/iphlpapi/icmp.c b/dlls/iphlpapi/icmp.c > index d8ee101..41d1940 100644 > --- a/dlls/iphlpapi/icmp.c > +++ b/dlls/iphlpapi/icmp.c > @@ -155,6 +155,7 @@ HANDLE WINAPI IcmpCreateFile(VOID) > int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP); > if (sid < 0) { > ERR_(winediag)("Failed to use ICMP (network ping), this requires > special permissions.\n"); > + ERR_(winediag)("Try running \"sudo setcap cap_net_raw+epi > /usr/bin/wine-preloader\".\n"); That only works on systems that support POSIX capabilities (Linux, and maybe OpenBSD). Chip

Feb. 11, 2011

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

by Juan Lang

> It looks like introducing bigger patches is a kind of mission impossible. That's not a bad analogy. Your mission, Krzysztof, should you choose to accept it, to improve sound resampling in Wine :) --Juan

Feb. 11, 2011