- Wine-Devel - list.winehq.org

Re: More destinations for wineoss's mixer
by peter＠piments.com March 6, 2005

March 6, 2005

On 05 Mar 2005 12:34:26 -0500, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > According to MSDN, DST_HEADPHONES can be the same as DST_SPEAKERS, > DST_LINE and DST_VOICEIN as DST_WAVEIN. > > Peter, does this one helps Dragon NS 7? > > Changelog: > Make wineoss's mixer know about DST_HEADPHONES, DST_LINE and > DST_VOICEIN. > Use proper constants instead of 0 and 1. > > Vincent Thanks , that got rid of the errors but did not make it work, sadly. I can get it to install reliably using Installshield. What I thought was blocking it was that there is a OK/Cancel dlg coming up _behind_ the splash screen. This is obviously a bug in that the dlg is modal but not visible when it comes up. The trick is to move the splash to one side before clicking Next. The prog now starts and works as much as it can without sound and a speach profile , ie not much but it can close cleanly. Attempting to set the mike volume is still the killer but there are now no messages, the set up dlg hangs and I have to close it using the X button on the frame. I can then exit NS. Progress none the less Thanks again. -- Using Opera e-mail on Gentoo Linux

1 0

Re: MultiByteToWideCharacter problem with CP 950 (Traditional Chinese)
by Andreas Mohr March 5, 2005

March 5, 2005

Hi, On Sun, Mar 06, 2005 at 04:49:13AM +0900, Mike McCormack wrote: > 1st problem: (pre-existing) No comments. > 2nd problem: (regression) > > There's another serious problem, which is a regression. Starting Office > 2000 (any language)with the Big5 code page as below, causes serious > trouble with my X server (X.org 6.7.0). The X cpu usage goes to 95%, > and the install hangs, more or less. > > LC_ALL=zh_TW.Big5 wine m:\setup > > The problem happens whether or not the Chinese truetype font is installed. This probably is the same issue that has prevented success for any attempt to use some relatively recent Wine versions on the notebook of my girlfriend (P3/450, Debian, Chinese simplified, non-Unicode setup: GB2312, XF86 4.3.x): whenever I started Wine, everything slowed to a crawl and I had veritable trouble trying to kill it (definitely points towards XF86 overload). I could offer to do some tests if need be. Haven't tried the new "non-official" Debian Wine packages, BTW. Andreas Mohr

1 0

Re: USER32: Error checking for sysparams tests
by Paul Vriens March 5, 2005

March 5, 2005

On Sat, 2005-03-05 at 06:42, jchevrier(a)nexicom.net wrote: > As discussed on wine-devel there are a handful of calls in the > SystemParametersInfo tests that don't check for returned errors and continue > on with testing a given parameter. This patch ensures that all initial calls > to SystemParametersInfoA in each parameter test have their returned errors > checked. To ease adding more error cases and reduce code duplication I have > consolidated error message handling into a single function. > > Changelog: > > * Consolidate error message handling > * Add error checking to all initial SystemParametersInfoA calls in each > parameter test to make sure that if a given parameter isn't supported or has > failed in some other way that we return and don't continue on with the test > * Remove a couple of TABS and align registry keys/values at the top of the > file Hi Justin, what about the attached one? Added/changed the following: - Always set LastError before calling test_error_msg - SPI_{GET,SET}ICONTITLEWRAP is supported on Win98, but was clouded by an error that was set after a previous call failed. Changelog: Justin Chevrier <jchevrier(a)nexicom.net> * Consolidate error message handling * Add error checking to all initial SystemParametersInfoA calls in each parameter test to make sure that if a given parameter isn't supported or has failed in some other way that we return and don't continue on with the test * SetLastError before calling test_error_msg * Remove a couple of TABS and align registry keys/values at the top of the file * SPI_{GET,SET}ICONTITLEWRAP is supported on Win98 Cheers, Paul.

2 1

Any resources about threading problems?
by Bill Medland March 5, 2005

March 5, 2005

Does anyone know any site or book or something with a decent discussion about the problems of the different threading models and their implementations? In the Developer's Guide in section 8.3 there are references to "the threading chapter". Is this a section that has not yet been written? As I understand it we (in the pthreads version) "override the native pthreads library". What does this mean? I am trying to research the issues associated with threading so that I understand the complications. The fact that Linux has two models and that Wine, FreeDCE and Samba (that I know of) seem to have found it necessary to bypass/hack/modify/override them indicates to me that there is something to understand. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 3

installshield and Wine
by wino＠piments.com March 5, 2005

March 5, 2005

What is the current state of play? It seems that InstallShield is pretty much and essential element in a working Wine env. But I tried to install Dragon NS 7 yesterday and it hung completely with a system wide modal in the middle of the screen. I had to kill the parent. There has been some regressions in Wine recently it seems , what would be the best wine version to install to get around this issue.? Thanks. -- Opera 7 mail on Linux

5 6

Dragon Naturally Speaking - working.
by wino＠piments.com March 5, 2005

March 5, 2005

Good news and what looks like a first. Dragon Naturally Speaking 4 working under Wine. ======================================= reqd riched32 and comdlg32 native from 98SE Gentoo Linux , 2.6.10-nitro4 kernel wine-20050111 Fresh Wine installation installed IE6 using sidenet Install Dragon from CD no major issues. copy missing dll's ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly. #wine gentrain.exe picks up user name , dictated training text . It saves the vocab/voix profiles the drops out with 3 repeat errors but the profile is safe #wine natspeak.exe Can now dictate in stand-alone mode as in windoze. I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread. Any suggestions on that? TIA :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

3 3

Re: [user/tests/sysparams.c] More correct *MOUSEHOVER* tests (Don't apply)
by Paul Vriens March 5, 2005

March 5, 2005

On Fri, 2005-03-04 at 21:39, Paul Vriens wrote: > Hi, > > current checks for only GetLastError()==ERROR_INVALID_SPI_VALUE) are > bogus, at least on Win98 as the LastError is not set. > > Changelog > LastError is not set on failure for *MOUSEHOVER* on Win98 > > Cheers, > > Paul. Hi, no need to apply this one. I shouldn't have checked for ERROR_CALL_NOT_IMPLEMENTED (maybe only at the very first test). Justin's patch seems to be on the right track. Cheers, Paul.

1 0

Re: USER32: Error checking for sysparams tests
by Paul Vriens March 5, 2005

March 5, 2005

On Sat, 2005-03-05 at 06:42, jchevrier(a)nexicom.net wrote: > As discussed on wine-devel there are a handful of calls in the > SystemParametersInfo tests that don't check for returned errors and continue > on with testing a given parameter. This patch ensures that all initial calls > to SystemParametersInfoA in each parameter test have their returned errors > checked. To ease adding more error cases and reduce code duplication I have > consolidated error message handling into a single function. > > Changelog: > > * Consolidate error message handling > * Add error checking to all initial SystemParametersInfoA calls in each > parameter test to make sure that if a given parameter isn't supported or has > failed in some other way that we return and don't continue on with the test > * Remove a couple of TABS and align registry keys/values at the top of the > file Hi Justin, could you have a look at the patch I send in for *MOUSEHOVER* stuff. Apparently Win98SE returns 0 without setting last error for the *MOUSEHOVER* ones. Could you incorporate this into your patch? Mine is a bit 'overcomplete' as ERROR_CALL_NOT_IMPLEMENTED will probably never be returned (only for SystemParametersInfoA itself). Shouldn't we also always do a SetLastError(0xdeadbeef) before every call to SystemParametersInfoA? Cheers, Paul.

1 0

Drive detection stuff
by Mike Hearn March 5, 2005

March 5, 2005

So, there are 4 obvious problems with our current drive management code: 1) We add links to the floppy drive. We should blacklist it, as it causes a big delay in the file open dialogs as we poll the drive which sits there spinning its motors naval-gazing. How many people still use floppy disks in 2005 anyway? I'm hoping the answer is "virtually none" 2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom 3) The artwork in the file pickers sucks ass. Sorry, it does. It's ugly as sin and for some reason the Desktop icon is an arrow, not a desk. This doesn't matter when you only have C: and Z: drives. It does matter when you have 2 CD drives, 2 Windows drives, a floppy and a few other drives. Fixing this is theoretically easy but for some reason it never gets done. If any of you non-coders are reading this and want to contribute then this would be a good way to start. Good artwork already exists, it's just a case of finding it, converting it to the right format and getting the new bitmaps into CVS. 4) We don't detect new drives as they are mounted into the system, eg if I start a Windows program and then realize that my work is actually on a USB key, if I plug that key in Nautilus and GTK+ (and probably KDE) apps will detect it and see it, but we won't. Not even if I restart the app! This is bad. Fixing this is not, in theory, super hard. When HAL detects a new hotplug device it modifies the fstab file and mounts. If we watch the /etc/fstab file for changes and rerun drive detection therefore we can make this all magically work. Problems are: - Who triggers the resync? The wineserver is the obvious choice as there is only 1 per wineprefix but we'd need to integrate FAM support for that - How do we broadcast to apps that the drive definitions changed so we can update the UI, flush any caches etc? thanks -mike

13 21

Setting null region for window mask kills wine 20050112
by Kuba Ober March 4, 2005

March 4, 2005

Hi, I was testing my Qt 3.3.4 application with wine, and it appears that setting a null widget mask via QWidget::setMask(QRegion()) puts wine into an endless loop. It continuously spews complaints that it ran out of gdi heap. I can reproduce it at home and send the actual error message if need be. I presume that this could be reproduced with the GPL qt-win32 port, but I didn't try. Cheers, Kuba Ober

1 0