- Wine-Devel - list.winehq.org

dlls/winmm/wineoss/audio.c build failure
by Gerald Pfeifer July 24, 2004

July 24, 2004

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 July 24, 2004

July 24, 2004

"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 July 24, 2004

July 24, 2004

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 July 24, 2004

July 24, 2004

> 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 July 23, 2004

July 23, 2004

> 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 July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

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 July 23, 2004

July 23, 2004

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

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Mike Hearn July 23, 2004

July 23, 2004

CCing to wine-devel as the original reply will be forwarded soon too by Jeroen .. On Fri, 2004-07-23 at 17:58 +0200, Jeroen Janssen wrote: > I had a short look at the 'world of com' patch, and it looks like there > is something in there that implements the IRemUnknown stuff. Is there > any easy way to determine if/how this can be 'ported' to the current wine? The "world of dcom" patch used to apply to WineHQ but it may not these days. Mike did a recent merge of it a month or two ago, maybe he has the latest copy? As to actually merging it into CVS, I'm not sure that's a good idea anymore. There's a lot of duplication there and we understand the code Marcus wrote better than Oves. Marcus is still a part of the project, whereas Ove basically isn't anymore. I think some of it is usable, and some of it is not, but merging it isn't a simple "make it apply cleanly and submit" I'm afraid.

2 1

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Robert Shearman July 23, 2004

July 23, 2004

Jeroen Janssen wrote: > Robert Shearman wrote: > >> Jeroen Janssen wrote: >> >>> Hello, >>> >>> I'm mailing the both of you with a small (com) example attached. >>> >>> It is a client/server/proxystub example (with binaries), so you need to >>> /RegServer the server and regsvr32 the proxy. >>> >>> Now I first manually start the server in a seperate console and then I >>> manually start the client. >>> >>> I modified the client to look for input, so there are basically two >>> paths >>> in the client: >>> >>> * you press: 1 <enter>; the normal path, goes OK >>> hr = >>> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_ICalculate,(void**) >>> >>> &pICalculate); >>> >>> * you press: 2 (or something else) <enter>; the other path, FAILURE >>> hr = >>> CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_IUnknown,(void**) >>> >>> &pIUnknown); >>> hr = pIUnknown->QueryInterface(IID_ICalculate, (void **) &pICalculate); >>> >>> Now either there is something wrong with my sample, or there is >>> something >>> wrong in wine that causes this to fail. >>> >>> Can you verify that the client code path is ok (the very few above >>> mentioned lines that differentiate in scenario 1,2). If the client >>> code is >>> ok, then any idea what is actually causing the problem? >> >> >> >> Yes, I can see the problem. What happens with native OLE is that the >> IUnknown part of the object is handled by the proxy manager. What >> this basically means is that it is translated into IRemUnknown >> (remote unknown) calls that will do the appropriate thing. However, >> this is currently not implemented on Wine. >> I'm not sure we (Mike and I) will have time to properly implement >> this, but I could maybe write a quick hack for you sometime over the >> weekend. > > > Ok, thanks for this explanation (that explains why this is not working > yet on wine). > > I had a short look at the 'world of com' patch, and it looks like > there is something in there that implements the IRemUnknown stuff. Is > there any easy way to determine if/how this can be 'ported' to the > current wine? As Mike said, some of it is usable and some of it isn't. Try applying the patch, but YMMV - I ran the patch for a while and it seemed to cause more problems than it solved, particularly in IE. In particular, I don't think the IRemUnknown stuff will be merged as is, because I think the way it is implemented in the patch is not the way it is implemented in Windows (there is only one IRemUnkown interface per apartment) and we only want to write this code once! Rob

1 0