August 2009 - Wine-Devel - list.winehq.org

Re: progress of sound update -- REVISED
by Susan Cragin Aug. 28, 2009

Aug. 28, 2009

Yesterday's Ubuntu updates produced a rash of pulseaudio changes, and suddenly alsa works with wine, without stumbling. Today's secret to making it work: In System/Preferences/Startup applications, uncheck pulseaudio sudo apt-get install esound -------- Why do you need to install esound? I don't know. I've taken it for granted that some kind of mixer is needed. Perhaps because I don't use the default sound card, the on-board card. Maybe I don't need esound at all. Or maybe if I could permanently make my Creative X-fi card the default. Right now, to do that, I have to revert back to the alsa-utils from Jaunty and use asoundconf set-default-card. (The newest alsa-utils does not include this handy tool.) -------- sudo nano /etc/pulse/client.conf autospawn = no Then every time your computer starts, run killall pulseaudio in terminal first. (Because the Startup Applications menu doesn't really work.) -------- Painful bug in Ubuntu. Yet another reason why I stay away from it at all costs :) What do you use? -------- I trained and ran Dragon NaturallySpeaking without a problem. Excellent news! Yeah. I read somewhere that Ubuntu has made pulseaudio removable partly because of this very program, which of course is a great assistance to people with mild RSI, who can use a keyboard for some things, but tire easily when entering large amounts of text.

2 1

Re: netapi32/tests: Add acceptable error codes for Win7
by André Hentschel Aug. 28, 2009

Aug. 28, 2009

adding "|| RPC_S_SERVER_UNAVAILABLE" is surely not what you wanted, i think you mean "|| rc == RPC_S_SERVER_UNAVAILABLE" -- Best Regards, André Hentschel

2 1

Re: progress of sound update -- REVISED
by Susan Cragin Aug. 28, 2009

Aug. 28, 2009

Change -- The program I test with is Dragon NaturallySpeaking. Yesterday's Ubuntu updates produced a rash of pulseaudio changes, and suddenly alsa works with wine, without stumbling. Today's secret to making it work: In System/Preferences/Startup applications, uncheck pulseaudio sudo apt-get install esound sudo nano /etc/pulse/client.conf autospawn = no Then every time your computer starts, run killall pulseaudio in terminal first. (Because the Startup Applications menu doesn't really work.) I trained and ran Dragon NaturallySpeaking without a problem. I also tried oss yesterday, and that seemed to be working again, too. I usually follow the above directions but do not install esound or kill pulseaudio and then run the wine app with padsp. If anyone has any different experiences with today's karmic updates, I would be interested to hear about them. Susan

2 1

progress of sound update
by Susan Cragin Aug. 28, 2009

Aug. 28, 2009

Yesterday's Ubuntu updates produced a rash of pulseaudio changes, and suddenly alsa works with wine, without stumbling. Today's secret to making it work: In System/Preferences/Startup applications, uncheck pulseaudio sudo apt-get install esound sudo nano /etc/pulse/client.conf autospawn = no Then every time your computer starts, run killall pulseaudio in terminal first. (Because the Startup Applications menu doesn't really work.) I trained and ran pulseaudio without a problem. I also tried oss yesterday, and that seemed to be working again, too. I usually follow the above directions but do not install esound or kill pulseaudio and then run the wine app with padsp. If anyone has any different experiences with today's karmic updates, I would be interested to hear about them. Susan

1 0

Re: Weekly cppcheck run against Aug 27 Git Tree
by chris ahrendt Aug. 28, 2009

Aug. 28, 2009

James McKenzie wrote: > chris ahrendt wrote: > >> ----- Original Message ---- >> From: Ben Klein <shacklein(a)gmail.com> >> To: chris ahrendt <celticht32(a)yahoo.com> >> Cc: wine-devel(a)winehq.org >> Sent: Thursday, August 27, 2009 10:06:56 PM >> Subject: Re: Weekly cppcheck run against Aug 27 Git Tree >> >> 2009/8/28 chris ahrendt <celticht32(a)yahoo.com>: >> >> >>> Mike Kaplinskiy wrote: >>> >>> >>>> On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: >>>> >>>> >>>> >>>>> This is the result of running cppcheck 1.35 with the --all parm against >>>>> the august 27th Git tree: >>>>> >>>>> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of >>>>> bounds >>>>> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of >>>>> bounds >>>>> >>>>> >>>>> >>>> False positive, apparently the numbers are hardcoded as: >>>> 72 char msg[128]; >>>> 88 msg[10 + 3 * 16] = ' '; // = 58<127 >>>> 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127 >>>> >>>> >>> Mike While yes the hard coded one above is a false positive... I would >>> argue its still a bug that probably needs to get fixed... >>> >>> >> >> >>> I don't follow this logic. How is it a bug (in Wine) exactly? >>> >>> >> I thought one of the programming standards was the fact you don't hard code values IE 10+3*16... >> it should probably be : >> >> msg_blank = 10+3*16; // These go into header files >> msg_length = 128; // This goes into header file >> >> char msg[msg_length]; >> memset(msg, 0, sizeof(msg)); >> memset(msg, ' ', msg_blank); // or it could even be msg[msg_blank] = ' '; if only position 58 needs to be a ' ' , but I prefer the first method. >> >> does pretty much the same thing except for one point. >> Whatever is in the local stack at the point of assigning the msg buffer will be still there unless you initialise it to null. >> >> >> > I like your logic, but why not just do this: > > msg_blank= 58; > msg_yada_yada=75; > msg_length=128; > > This sets all of the variables using plain values and then they can be > updated as necessary. > > James McKenzie > > > > > same thing =D Chris

1 0

Re: Weekly cppcheck run against Aug 27 Git Tree
by chris ahrendt Aug. 28, 2009

Aug. 28, 2009

Mike Kaplinskiy wrote: > On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> This is the result of running cppcheck 1.35 with the --all parm against >> the august 27th Git tree: >> >> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of >> bounds >> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of >> bounds >> > > False positive, apparently the numbers are hardcoded as: > 72 char msg[128]; > 88 msg[10 + 3 * 16] = ' '; // = 58<127 > 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127 > > >> [../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null >> pointer dereference: rgfInOut >> > > It doesn't like the ternary operator? These lines are TRACE lines with > one of the args being ``rgfInOut ? *rgfInOut : 0''. False positive. > > >> [../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of >> character ({). Can't process file. >> [../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer >> overrun >> > > 739 char defaultpcmname[256]; > 745 sprintf(defaultpcmname, "default"); > > Something is wrong with cppcheck... False positive. > > >> [../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error) >> Buffer overrun >> [../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error) >> Buffer overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer >> overrun >> > > Not checking those - i don't even pretend to understand how modern > graphics works. > > >> [../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun >> > > So...it picks > 1455 char name[32]; > 1458 sprintf(name, "/dev/mixer"); > > as an error, but not: > > 1460 sprintf(name, "/dev/mixer%d", i); > > False positive. > > >> [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer >> dereference: dmW >> > > This one is actually a bug, the null check is below this line. All the > callers check for nulls, though. > > >> [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer >> dereference: hWndCreated >> > > Also a bug, and a very real one. Coincidentally, the null check on the > next line is also wrong (should be if (!*hWndCreated) ) > > >> [../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun >> > > More of sprintf with just a string nonsense. False positive. > > >> [../wine-git/server/file.c:235]: (possible error) Buffer overrun >> > > Also sprintf nonsense, but slightly more dangerous. The buffer is > declared with [16] and the string is of length 14+1, so a few more > bytes wouldn't hurt. :) > >> Chris >> >> > > If someone could send patches for the few bugs that would be nice. > > Chris - cppcheck is clearly crazy about sprintf's and ternary > operators. You might want to report that. > > Mike. > > > Sending the report now. chris

1 0

submitted AppDB links to bugzilla not working anymore?
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 27, 2009

Aug. 27, 2009

Hi, Several recent link proposals between AppDB and Buzilla acknowledged by "The bug link you submitted between Bug NNN and XYZ has been accepted." have nevertheless produced no visible bug # in AppDB nor "Show Apps affected" in Bugzilla. E.g. Bug #19773 among others. Did some recent changes to the server break that functionality? BTW, a few month ago, I was pleased to see that some links were automatically(?) created when the bug subject had the format app-name: blabla That was a useful idea! Regards, Jörg Höhle

3 3

RE: [2/2] shell32: Remove todo_wine from some tests [try 2]
by First Store Aug. 27, 2009

Aug. 27, 2009

My domain never subscribed to this, please quit sending me these. -----Original Message----- From: wine-patches-bounces(a)winehq.org [mailto:wine-patches-bounces(a)winehq.org] On Behalf Of Vladimir Pankratov Sent: Thursday, August 27, 2009 10:22 AM To: wine-patches(a)winehq.org Subject: [2/2] shell32: Remove todo_wine from some tests [try 2] Hello all. Also resend this patch. Removed todo_wine from some tests. changed files: dlls/shel32/tests/shfileop.c Thanks.

1 0

Re: [2/2] shell32: Remove todo_wine from some tests [try 2]
by Juan Lang Aug. 27, 2009

Aug. 27, 2009

Hi Vladimir, you can't do this in two separate patches like this. After the first patch is applied, the tests fail, and that's not allowed. You should combine the fix and removing todo_wine into a single patch. Thanks, --Juan

1 0

[RFC] Adding an OpenAL DLL thunk
by Chris Robinson Aug. 27, 2009

Aug. 27, 2009

Attached is a set of patches that adds an openal32.dll thunk, allowing an app using OpenAL to use the system's lib instead of Creative's software driver. The advantages of using the system lib include: * It avoids the unnecessary step through DirectSound, instead going right to ALSA, OSS, or whichever is supported by the system implementation. This also allows for a DSound->OpenAL wrapper, since OpenAL won't create a circular dependency by using DSound. * It can provide more options and features, including surround sound (where Creative's software driver only does stereo), depending on the implementation. * It integrates better with the system, as Wine apps will use the same OpenAL configuration used by native apps. If necessary, the Windows DLL can still be used by adding an openal32 override with installing the Windows redistributable. However, more recent versions of the Unix/Linux OpenAL have been much better compatibility-wise than the old 0.0.8 version, as it is actually a fork of the LGPL Windows version. This patch set does not support OSX's OpenAL, but it should be simple enough to add for anyone familiar with handling frameworks in configure.ac. An incomplete list of games that use OpenAL, for testing, can be found here: http://connect.creativelabs.com/openal/OpenAL%20Wiki/Games.aspx Comments and questions are welcome.

5 9