July 2004 - Wine-devel - list.winehq.org

Re: slightly OT: c expression evaluation order
by Diego 'Flameeyes' Pettenò 24 Jul '04

24 Jul '04

Michael Jung wrote: > I've always thought that the order in which subexpressions are evaluated > is not specified in the C language. Isn't there the danger of a NULL > pointer dereference given here? I don't think so. Order is expressed and is from left to right, so if you have two functions and do func1() && func2() if func1() will be evalutated as false, func2() will never be called. I saw code wrote without if statements and using directly the logic operators (also if I don't like this syntax) and also Gentoo's scripts (ebuilds and init.d) uses this syntax for some conditional statements. So it should be sure that there won't be a null pointer deference. Regards, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

1 0

slightly OT: c expression evaluation order
by Michael Jung 24 Jul '04

24 Jul '04

Hello, this is slightly of topic for this mailing list. However, it would be nice if someone could answer my question. I've seen that Alexandre changed the if statement expression in one of my patches from if (pszProvider ? *pszProvider == '\0' : 1) to if (!pszProvider || !*pszProvider) I've always thought that the order in which subexpressions are evaluated is not specified in the C language. Isn't there the danger of a NULL pointer dereference given here? Thanks, Michael

2 1

dlls/winmm/wineoss/audio.c build failure
by Gerald Pfeifer 24 Jul '04

24 Jul '04

The following change to dlls/winmm/wineoss/audio.c revision 1.135 date: 2004/07/19 20:08:06; author: julliard; state: Exp; lines: +1 -1 Francois Gouget <fgouget(a)codeweavers.com> Use round() instead of ceil() in wodGetPosition(TIME_SMPTE). Fixes the corresponding winmm conformance test. causes the following build failure on FreeBSD 4.9: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -shared ./wineoss.drv.spec audio.o midi.o midipatch.o mixer.o mmaux.o oss.o wineoss.drv.dbg.o -o wineoss.drv.so -L../../../dlls -lwinmm -luser32 -lkernel32 -L../../../libs/wine -lwine -ldxguid -luuid -L../../../libs/port -lwine_port audio.o: In function `wodGetPosition': /test/wine/dlls/winmm/wineoss/audio.c:2127: undefined reference to `round' collect2: ld returned 1 exit status winegcc: /sw/gcc-3.3.2/bin/gcc failed. gmake: *** [wineoss.drv.so] Error 2 Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 2

Re: wine/dlls/kernel locale.c
by Dmitry Timoshkov 24 Jul '04

24 Jul '04

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Log message: > Shachar Shemesh <wine-patches(a)shemesh.biz> > System default locale in Windows determines the ANSI encoding > (LC_CTYPE on Unix). I still think that this patch is wrong. On my english win2k with locale set to russian both GetSystemDefaultLCID and GetUserDefaultLCID return 0419. -- Dmitry.

1 0

Division by zero in snd_pcm_rate_sw_params()
by Francois Gouget 23 Jul '04

23 Jul '04

Hi, I am working on Wine and lately I have been tracking various sound related issues. One issue I noticed is a crash in Wine's winmm wave test when using the Alsa sound backend. More precisely: * if Wine's winmm wave test is the only application using the sound device, then it works * but if another application is already using the sound device (e.g. xmms), then Wine's winmm wave test crashes when trying to play the 96kHz test. The crash occurs when calling snd_pcm_sw_params(): EXIT_ON_ERROR( snd_pcm_sw_params(pcm, sw_params), MMSYSERR_ERROR, "unable to set sw params for playback"); See this URL for the exact source: http://source.winehq.org/source/dlls/winmm/winealsa/audio.c#L1602 Digging some more I found out that the division by zero happens in the snd_pcm_rate_sw_params() function pcm_rate.c. Here's why: * Wine sets xfer_align to 1: EXIT_ON_ERROR(snd_pcm_sw_params_set_xfer_align(pcm, sw_params, 1), MMSYSERR_ERROR, "unable to set xfer align"); * then it calls snd_pcm_sw_params() as shown above * eventually we get to snd_pcm_rate_sw_params() in src/pcm/pcm_rate.c. (http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/src/pcm/pcm_rate.c?rev=…) * There we call recalc(): recalc(pcm, &sparams->xfer_align); * when more than one application uses the soundcard, recalc() ends up doing: *val = muldiv_near(*val, slave->period_size, pcm->period_size); * however in my case slave->period_size is less than half of pcm->period_size so I end up with xfer_align == *val == 0. * then, a few lines later in snd_pcm_rate_sw_params() we do: if (sparams->start_threshold > (slave->buffer_size / sparams->xfer_align) * sparams->xfer_align) sparams->start_threshold = (slave->buffer_size / sparams->xfer_align) * sparams->xfer_align; And we crash with a division by zero because now sparams->xfer_align==0. (these lines were added in CVS revision 1.83 of this file) Simply resetting xfer_align to 1 is it is zero after the call to recalc() (see attached patch) fixes the problem for me (no crash and the test tone plays correctly). However I don't know if this is the right fix, hence the following questions: Does my patch look ok? What is the proper procedure to get it applied? Is there further information I can provide to resolve this issue? My configuration: * Up to date Debian testing * Alsa 1.0.5a * cat /proc/asound/cards 0 [V8235 ]: VIA8233 - VIA 8235 VIA 8235 at 0xbc00, irq 5 -- Francois Gouget fgouget(a)codeweavers.com --- pcm_rate.c.orig 2004-07-24 03:19:41.000000000 +0200 +++ pcm_rate.c 2004-07-24 03:20:41.000000000 +0200 @@ -630,6 +638,8 @@ recalc(pcm, &sparams->avail_min); rate->orig_avail_min = sparams->avail_min; recalc(pcm, &sparams->xfer_align); + if (sparams->xfer_align==0) + sparams->xfer_align=1; recalc(pcm, &sparams->start_threshold); if (sparams->start_threshold <= slave->buffer_size) { if (sparams->start_threshold > (slave->buffer_size / sparams->avail_min) * sparams->avail_min)

1 0

Re: make crosstest fails
by Ivan Leo Puoti 23 Jul '04

23 Jul '04

> Or can we actually use this instead? > http://prdownloads.sourceforge.net/wine/wine-w32api-20040505.zip?download You should be able to use them, or I don't see the point of having them. Note that updated versions exist http://prdownloads.sourceforge.net/wine/wine-w32api-20040615.zip?download http://prdownloads.sourceforge.net/wine/wine-w32api-20040716.zip?download Ivan.

1 0

Re: devenum
by Ivan Leo Puoti 23 Jul '04

23 Jul '04

> Why you do not leave the neutral resources in the main archive? That's how it's done in other files, anyway, I'll send another patch that leaves the neutral resources in the main file. Ivan.

1 0

Re: Install msiexec in the bin dir while make install.
by Alexandre Julliard 23 Jul '04

23 Jul '04

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Alexandre, what are the guidelines for installing winelib applications > in /foo/bin/? It should be restricted to apps that users will frequently run from the command-line on Windows so that they expect the same behavior on Wine, or else to apps prefixed with 'wine' as there isn't a risk of conflict in that case. I'm not sure msiexec qualifies; is it really something that end users are expected to use on Windows? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: French translation and other adjustments
by Francois Gouget 23 Jul '04

23 Jul '04

On Fri, 23 Jul 2004, Marcelo Duarte wrote: > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > French translation and other adjustments + IDS_RESTART_TITLE "Recommencer" + IDS_RESTART_PROMPT "Tu voulez simuler la remise du Windows?" + IDS_SHUTDOWN_TITLE "Débrancher" + IDS_SHUTDOWN_PROMPT "Tu voulez finir la session du Wine?" Urgh! Maybe you meant something like: + IDS_RESTART_TITLE "Recommencer" + IDS_RESTART_PROMPT "Voulez-vous simuler le redémarrage de Windows?" + IDS_SHUTDOWN_TITLE "Arrêter" + IDS_SHUTDOWN_PROMPT "Voulez-vous fermer la la session Wine?" Note: I not entirely sure about 'Arrêter'. Translation can be pretty tricky sometimes... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 1

Re: Add a WINEVER environment variable
by Andreas Mohr 23 Jul '04

23 Jul '04

Hi, I'm afraid I don't like the naming, since it's potentially confusing (plus, it somewhat goes against established rules, "WINE + function"). What about WINEWINVER instead? I for one like it much more. Also, this doesn't take into account that we're also able to set the DOS version. So what would that be called then? WINEVER, too? ;-) WINEWINVER and WINEDOSVER is a much better choice, IMHO. Greetings, Andreas

3 4