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

Re: dsound: Handle failing of IDsDriver_CreateSoundBuffer better

by Maarten Lankhorst

Vitaliy Margolen schreef: > And this really fixes the bug, doesn't just hide the error message? If > it fixed, then there should be no messages at all. I really do not > want to have people opening bugs because something crashes/sound > doesn't work, etc. It fixes it, there might be some caps difference from falling back, but should be harmless, if you really want to, that is easy to fix, too. Cheers, Maarten

Aug. 20, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Vitaliy Margolen

Maarten Lankhorst wrote: > Vitaliy Margolen schreef: >> That didn't work all that well: >> >> err:wave:DSDB_MapBuffer Please run winecfg, open "Audio" page and set >> "Hardware Acceleration" to "Emulation". >> wine: Unhandled page fault on read access to 0x00000030 at address >> 0x7edf2cf8 (thread 0011), starting debugger... >> >> This is with OSS and full acceleration. > Just sent-in patch to dsound fixes that, even then it is no reason not > to accept this patch as it would have happened already with the current > code. > Doesn't help: wine: Unhandled page fault on read access to 0x00000030 at address 0x7edfccf8 (thread 0011), starting debugger... Backtrace: =>1 0x7edfccf8 waveOutUnprepareHeader+0x38(hWaveOut=0x8000, lpWaveOutHdr=0x20, uSize=0x20) [/usr/local/src/wine.git-build/dlls/winmm/../../../wine.git/dlls/winmm/winmm.c:2289] in winmm (0x00349e28) Vitaliy.

Aug. 20, 2007

Re: dsound: Handle failing of IDsDriver_CreateSoundBuffer better

by Vitaliy Margolen

Maarten Lankhorst wrote: > There, now hush. :p > > Does 'Hardware Acceleration to Emulation' silently, without requiring of > the user to do something. > > > - ERR("Could not map sound device for direct access (%s)\n", strerror(errno)); > - ERR("Please run winecfg, open \"Audio\" page and set\n" > - "\"Hardware Acceleration\" to \"Emulation\".\n"); > + WARN("Could not map sound device for direct access (%s)\n", strerror(errno)); > return DSERR_GENERIC; And this really fixes the bug, doesn't just hide the error message? If it fixed, then there should be no messages at all. I really do not want to have people opening bugs because something crashes/sound doesn't work, etc. Vitaliy

Aug. 20, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Maarten Lankhorst

Vitaliy Margolen schreef: > That didn't work all that well: > > err:wave:DSDB_MapBuffer Please run winecfg, open "Audio" page and set > "Hardware Acceleration" to "Emulation". > wine: Unhandled page fault on read access to 0x00000030 at address > 0x7edf2cf8 (thread 0011), starting debugger... > > This is with OSS and full acceleration. Just sent-in patch to dsound fixes that, even then it is no reason not to accept this patch as it would have happened already with the current code. Cheers, Maarten

Aug. 19, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Vitaliy Margolen

Maarten Lankhorst wrote: > Hi Vitaliy, > > Vitaliy Margolen schreef: >> I would still suggest to wait for at least one more week before >> committing this patch. Also historically it was a bad idea to select >> multiple sund devices, as all of them require different settings. For >> example majority of users can't use full acceleration with OSS, >> because in almost all cases it's alsa->oss driver on non hw-mixing >> capable hardware/drivers. While "full" is recommended for ALSA to work >> properly. > To make directsound work in windows, I have committed a bunch of > patches, one of them should make it possible for OSS to work at 'Full' > and still fallback to emulation without crashing, feel free to test it. > > By default, no configuration should be needed any more, except to set > rate to 44100 and 16 bit, which is preferred above 22050/8 bit at any time. > That didn't work all that well: err:wave:DSDB_MapBuffer Please run winecfg, open "Audio" page and set "Hardware Acceleration" to "Emulation". wine: Unhandled page fault on read access to 0x00000030 at address 0x7edf2cf8 (thread 0011), starting debugger... This is with OSS and full acceleration.

Aug. 19, 2007

Re: [patch] Garbage code in text string display

by James Hawkins

On 8/19/07, Guan Xin <guanx.bac(a)gmail.com> wrote: > Q: Can you give a simple example of such a program (preferably downloadable)? > A: Yes. If you have Simplified Chinese environment, you can try: > http://update.cz88.net/soft/qqwry.rar > which is a freeware for IP address-to-geographical address > translation. Before patching WINE, most (though not all) labels > and all buttons show garbage code. None after. > > Q:Can you add a conformance test showing that your patch is correct? > A: I have tried editplus, acdsee, and gvim in en_US and > zh_CN.GBK locale/encodings. They all ran well. I also tried > the German version of winrar in de locale, no problem either. > I don't think we need to prove this patch is correct because > it is certainly wrong and introduced a bug. However, > `any sufficiently advanced bug becomes a feature'. > In the source code of Microsoft Windows NT/2k/XP, > or to be excact, in the file > "private/windows/shell/accesory/spechars/charmap.c" > they confessed there is a bug in GDI that > `assumes the font's default charset is always the > system default locale'. > > I know peeking into The source code is illegal, > but I've only done this some 24 hrs after I submitted > this patch. So this patch has nothing to do with > my undesirable deed. > No patches will be accepted from you for the Wine project because you've looked at Windows source code. -- James Hawkins

Aug. 19, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Maarten Lankhorst

Hi Vitaliy, Vitaliy Margolen schreef: > I would still suggest to wait for at least one more week before > committing this patch. Also historically it was a bad idea to select > multiple sund devices, as all of them require different settings. For > example majority of users can't use full acceleration with OSS, > because in almost all cases it's alsa->oss driver on non hw-mixing > capable hardware/drivers. While "full" is recommended for ALSA to work > properly. To make directsound work in windows, I have committed a bunch of patches, one of them should make it possible for OSS to work at 'Full' and still fallback to emulation without crashing, feel free to test it. By default, no configuration should be needed any more, except to set rate to 44100 and 16 bit, which is preferred above 22050/8 bit at any time. Cheers, Maarten

Aug. 19, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Vitaliy Margolen

Maarten Lankhorst wrote: > Vitaliy Margolen schreef: >> Isn't this a bit premature? ALSA still does not support proper sound >> capture, working mixer, and not stable enough on some configurations. > Mixer works properly, as you saw for yourself. Only thing that is > different is just that the alsa accelerated capture code is new and > might contain a few bugs. Apart from that everything is there and > working, unless you have some win3.11 apps that need aux. > > Cheers, > Maarten Yeah I sent an e-mail before finding out which mixer doesn't work. Of course MPU401 doesn't have one :-) I would still suggest to wait for at least one more week before committing this patch. Also historically it was a bad idea to select multiple sund devices, as all of them require different settings. For example majority of users can't use full acceleration with OSS, because in almost all cases it's alsa->oss driver on non hw-mixing capable hardware/drivers. While "full" is recommended for ALSA to work properly. Vitaliy.

Aug. 19, 2007

Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2

by Maarten Lankhorst

Vitaliy Margolen schreef: > Isn't this a bit premature? ALSA still does not support proper sound > capture, working mixer, and not stable enough on some configurations. Mixer works properly, as you saw for yourself. Only thing that is different is just that the alsa accelerated capture code is new and might contain a few bugs. Apart from that everything is there and working, unless you have some win3.11 apps that need aux. Cheers, Maarten

Aug. 19, 2007

Re: [patch] Garbage code in text string display

by Guan Xin

Q: Can you give a simple example of such a program (preferably downloadable)? A: Yes. If you have Simplified Chinese environment, you can try: http://update.cz88.net/soft/qqwry.rar which is a freeware for IP address-to-geographical address translation. Before patching WINE, most (though not all) labels and all buttons show garbage code. None after. Q:Can you add a conformance test showing that your patch is correct? A: I have tried editplus, acdsee, and gvim in en_US and zh_CN.GBK locale/encodings. They all ran well. I also tried the German version of winrar in de locale, no problem either. I don't think we need to prove this patch is correct because it is certainly wrong and introduced a bug. However, `any sufficiently advanced bug becomes a feature'. In the source code of Microsoft Windows NT/2k/XP, or to be excact, in the file "private/windows/shell/accesory/spechars/charmap.c" they confessed there is a bug in GDI that `assumes the font's default charset is always the system default locale'. I know peeking into The source code is illegal, but I've only done this some 24 hrs after I submitted this patch. So this patch has nothing to do with my undesirable deed. Xin On 8/19/07, Dan Kegel <dank(a)kegel.com> wrote: > Xin Guan wrote: > > This patch solves the problem that many MBCS programs display garbage code > > for text strings. Because most windows programmers do not handle charsets > > properly, we have to force DEFAULT_CHARSET in here. > > Can you give a simple example of such a program (preferably downloadable)? > > Can you add a conformance test showing that your patch is correct? > - Dan >

Aug. 19, 2007