November 2002 - Wine-Devel - list.winehq.org

Re: dosconf move
by Alexandre Julliard Nov. 24, 2002

Nov. 24, 2002

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > Is there any reason why this patch has not been applied? This is essentially > the same as my dosconf try 3 patch but for your convinience I made a new diff > against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: wintab.dll: Copyright & trademark issues.
by Patrik Stridvall Nov. 23, 2002

Nov. 23, 2002

> As I mentioned in an e-mail a couple of days back, > I'm about to start implemening a version of wintab.dll. > First I want to ask about legal issues: > > 1. trademark issues. > > wintab is a trademark. > Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. > 2. API header files. > Please look at the licence for the API files, avaialable at the > following URL: > http://www.pointing.com/Wintab/WTKIT126.ZIP > Does this allow our use of the headers, in Wine? > Does it allow the use of fragments of the headers in Wine? >From the headers: < The text and information contained in this file may be freely used, < copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. > This is not too much of an issue, as I understand it's OK to re-write > compatible headers "In your own words". True. > 3. I am in the UK, how does this affect the copyright/trademark issues > above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. > Ok, some background about wintab: > wintab.dll is an "open industry standard" API > developed by a group of tablet manufacturers, and seems to > be currently maintained by the company LCS/Telegraphics. > Web page for wintab: http://www.pointing.com/WINTAB.HTM > LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets?

2 1

gcc 2.95.3 breakage
by Johan Gill Nov. 23, 2002

Nov. 23, 2002

It seems that latest CVS does not work well with gcc 2.95.3. collect2 segfaults when linking user, it seems. Gnarl -- /Johan Gill, johane(a)lysator.liu.se

1 1

[bug 718] Executing dos DPMI programs
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 2002

Does someone has success when executing DPMI programs ? Every program I try to execute at this time fails, going to the debugger, saying : Unhandled exception: privileged instruction in 32-bit code (0x00000000). In 32-bit mode. 0x00000000: int $0x31 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: [wine-users] Can't get Unreal to work in opengl mode
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 2002

Have exactly the same error when trying to run Max Pane. Tried with --debygmsg +seh, but didn't give any clue. Perhaps weshould file a bugreport on bugs.winehq.com or try wine-devel. Anyone who knows about seh at wine-devel, could you say what makes this happen ? > err:seh:EXC_DefaultHandling Exception frame is not in stack limits => > unable > to dispatch exception. > -------------------------------------------------------------------------- > > Here is how I got it: > > I started Wine from the command line; the resolution changed from > 1024x768 > to 64x480; then I got the Unreal menu; I then selected 'options' and > then > 'advanced options'; Unreal popped-up a window where I chose 'drivers' > then > 'opengl support'; after that I got back to the desktop ('err:seh...' > line). > > Hope it helps. > > N.B. I checked my config.log again; ./tools/wineinstall did > > $ ./configure -C --enable-opengl > > All the opengl items got a 'yes' answer, except this one: > > -------------------------------------------------------------------------- > configure:6918: checking for thread-safe OpenGL version > configure:6938: gcc -o conftest -g -O2 -I/usr/X11R6/include > conftest.c > -L/usr/X11R6/lib -lGL >&5 > /tmp/ccc9a5Qz.o: In function main': > /home/fab/test/wine/configure:6930: undefined reference to > pthread_getspecific' > collect2: ld returned 1 exit status > configure:6941: $? = 1 > configure: failed program was: > #line 6925 "configure" > #include "confdefs.h" > > int > main () > { > pthread_getspecific(); > ; > return 0; > } > configure:6959: result: no > -------------------------------------------------------------------------- > > See you. > > -- > Fabrice DELENTE > E-mail : fabrice.delente(a)free.fr > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Menu selection algorithm
by Jeff Smith Nov. 23, 2002

Nov. 23, 2002

Dmitry, I still have win95-osr2 loaded on a machine. Let me know what I need to run the test on that box and I would glad to do so if this would help out. -- Jeff S >From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > So, what's the problem - you ask? While my view of what should happen is > > obviously consistant with that of Wine's - i.e. - the locale should > > select which menu to use, Windows displays the English locale ONLY. The > > only way I could make it display the Hebrew one was by changing the > > language on the English one to something else (French). > >I revived my old test for FindResource and now I see what are you talking >about. >LoadStringA/W and FindResourceA/W under Win2000 do search for language >resource >in the following order: >1. Neutral language with neutral sublanguage >2. LANG_ENGLISH, SUBLANG_DEFAULT >3. LANG_ENGLISH, SUBLANG_NEUTRAL >4. Current locale lang id >5. Current locale lang id with neutral sublanguage >6. Return first in the list > >But that means that the whole our internationalization will not work, if >we will go that way. But the question I have is: had I made an error when >I did the test under Win95OSR2 or MS has changed algorithm since then? > >-- >Dmitry. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Menu selection algorithm
by Shachar Shemesh Nov. 23, 2002

Nov. 23, 2002

Hi list, Sorry if this is slightly off topic. I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one). So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one. I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however. I'm using "RegisterClass" to register a class with the menu identifier passed using "MAKEINTRESOURCE", and then just calling "CreateWindow" to create the window. Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all? Shachar

2 2

Re: [Bug 688] - make documentation produces only files as 'x6772.html'
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 2002

I can answer that 'make html' works beautifully and perfectly. Good job ! > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca > 2002-11-22 19:32 ------- > Sylvain, Tony, Dustin, could you confirm that it works correctly now? > Alexandre > just committed my patch. > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Page fault with isspace(*p)
by John K. Hohm Nov. 23, 2002

Nov. 23, 2002

I am rewriting the regsvr stuff in dlls/comcat to make it practical to extend to ole32 and all the other COM DLLs. I have a nice simple function to skip whitespace and return the next character: static int getc_skipws(char const **p) { while (isspace(*p)) ++*p; return **p; } This gets called with **p == '['. I get a page fault in the implementation of isspace(), where the macro is testing 0x20 against the value for '[' in the __ctype_b array. What gives?

1 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Dustin Navea Nov. 23, 2002

Nov. 23, 2002

On Fri, 2002-11-22 at 19:37, Vincent Béron wrote: > Hi guys, > > Alexandre just committed my patch concerning the documentation building > process. Could you verify it works for you? > > Thank you, > Vincent > ---- > > From: wine-bugs(a)winehq.com > To: vberon(a)mecano.gme.usherb.ca > Subject: [Bug 688] - make documentation produces only files as 'x6772.html' > Date: 08 Nov 2002 20:23:34 -0600 > > http://bugs.winehq.com/show_bug.cgi?id=688 > > > > > > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-11-08 20:23 ------- > Please advise on which of the 2 attachments is the best. > Personnaly, I'd rather go with the second, because with the first one it creates > a directory with images, but those are unused. > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://bugs.winehq.com/show_bug.cgi?id=688>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. Well, I am still working on updating my status, turns out that since I upgraded to Slackware 8.1 the default gcc wont build the jade package of sgmltools properly and so I need to upgrade to the latest slack-prepared build of gcc... Then I will try making it again... and see what happens..

1 0

Wine & Boehm garbage collector
by François-Denis Gonthier Nov. 23, 2002

Nov. 23, 2002

Hello Wine-Devel I have not filled a bug with this a some of you may already know a solution to this problem. I've a contributor to the Mono project (http://www.go-mono.com) working on the System.Windows.Forms namespace. It has been decided to use Wine to implement this assembly since the S.W.F is rather tightly bound to the Win32 API. But we are facing a nasty problem. Current Mono implementation is using Hans Boehm conservative garbage collector and Wine cannot seems to work happily with that garbage collector. The temporary solution for development is to use Mono without garbage collection. This solution however, should not even be considered when Mono and it's System.Windows.Forms implementation will go mainstream. I've joined a small test case so one can try. Wine just crash at the first call to GC_malloc. Any help or advice is appreciated. François-Denis Gonthier

4 6

where is the code that converts VARIANTS?
by Medland, Bill Nov. 23, 2002

Nov. 23, 2002

Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? Bill

2 1

closing handle fails
by steve.lustbader＠philips.com Nov. 22, 2002

Nov. 22, 2002

I open a handle to a com port with m_hPort = ::CreateFile(_T("COM1"),GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING,FILE_FLAG_OVERLAPPED, 0); Later, when I try to close the handle, the call to CloseHandle(m_hPort) gets stuck when CloseHandle calls NtClose. What trace can I provide here to help? -Steve

1 0

Re: wine/ windows/winproc.c windows/winpos.c windo ...
by Greg Turner Nov. 22, 2002

Nov. 22, 2002

On Friday 22 November 2002 03:22 pm, Alexandre Julliard wrote: > ChangeSet ID: 6371 > 1.154 1.155 +76 -93 wine/controls/menu.c gcc 3.2 isn't happy with this: make[2]: Entering directory `/var/src/wine/dlls/user' gcc -c -I. -I. -I../../include -I../../include -march=athlon -O1 -pipe -mmmx -m3dnow -gstabs -g3 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -o ../../controls/menu.o ../../controls/menu.c ../../controls/menu.c: In function `MENU_GetBitmapItemSize': ../../controls/menu.c:722: pointers are not permitted as case values ../../controls/menu.c:729: pointers are not permitted as case values ../../controls/menu.c:730: pointers are not permitted as case values ../../controls/menu.c:731: pointers are not permitted as case values ../../controls/menu.c:732: pointers are not permitted as case values ../../controls/menu.c:733: pointers are not permitted as case values ../../controls/menu.c:737: pointers are not permitted as case values ../../controls/menu.c:738: pointers are not permitted as case values ../../controls/menu.c:739: pointers are not permitted as case values ../../controls/menu.c:740: pointers are not permitted as case values ../../controls/menu.c:741: pointers are not permitted as case values ../../controls/menu.c: In function `MENU_DrawBitmapItem': ../../controls/menu.c:778: pointers are not permitted as case values ../../controls/menu.c:793: pointers are not permitted as case values ../../controls/menu.c:796: pointers are not permitted as case values ../../controls/menu.c:799: pointers are not permitted as case values ../../controls/menu.c:802: pointers are not permitted as case values ../../controls/menu.c:805: pointers are not permitted as case values ../../controls/menu.c:808: pointers are not permitted as case values ../../controls/menu.c:809: pointers are not permitted as case values ../../controls/menu.c:810: pointers are not permitted as case values ../../controls/menu.c:811: pointers are not permitted as case values ../../controls/menu.c:812: pointers are not permitted as case values make[2]: *** [../../controls/menu.o] Error 1 make[2]: Leaving directory `/var/src/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/var/src/wine/dlls' make: *** [dlls] Error 2 These are DECLARE_HANDLE'ed values. This seems to fix it: Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.155 diff -u -r1.155 menu.c --- controls/menu.c 22 Nov 2002 21:22:16 -0000 1.155 +++ controls/menu.c 22 Nov 2002 22:13:40 -0000 @@ -719,26 +719,26 @@ { switch(LOWORD(id)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (data) { bmp = (HBITMAP)data; break; } /* fall through */ - case HBMMENU_MBAR_RESTORE: - case HBMMENU_MBAR_MINIMIZE: - case HBMMENU_MBAR_MINIMIZE_D: - case HBMMENU_MBAR_CLOSE: - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE_D: size->cx = GetSystemMetrics( SM_CXSIZE ); size->cy = GetSystemMetrics( SM_CYSIZE ); return; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", id); return; @@ -775,7 +775,7 @@ switch(LOWORD(lpitem->text)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (lpitem->dwItemData) { bmp = (HBITMAP)lpitem->dwItemData; @@ -790,26 +790,26 @@ bm.bmWidth -= bmp_xoffset; } goto got_bitmap; - case HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_RESTORE: flags = DFCS_CAPTIONRESTORE; break; - case HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE: flags = DFCS_CAPTIONMIN; break; - case HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: flags = DFCS_CAPTIONMIN | DFCS_INACTIVE; break; - case HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE: flags = DFCS_CAPTIONCLOSE; break; - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_CLOSE_D: flags = DFCS_CAPTIONCLOSE | DFCS_INACTIVE; break; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", LOWORD(lpitem->text)); return; -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

wintab.dll: Copyright & trademark issues.
by Robert North Nov. 22, 2002

Nov. 22, 2002

As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? This is not too much of an issue, as I understand it's OK to re-write compatible headers "In your own words". 3. I am in the UK, how does this affect the copyright/trademark issues above? Ok, some background about wintab: wintab.dll is an "open industry standard" API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM I also found this organiation that LCS belongs to interesting: http://www.interop.org/ Many thanks -Rob.

1 0

Re: wine and asyncronous file i/o
by Martin Fuchs Nov. 22, 2002

Nov. 22, 2002

Thanks, Martin! > EOF conditions are nasty. Seems we got it wrong... Please try the > following patch (it should solve your problem). However I guess it needs > regression testing because it changes overlapped ReadFile() semantics > drastically. If this condition turns out to be right, we may actually be > able to get rid of the special treatment of sockets in > FILE_AsyncReadService(). Yes, the file read routine seems to work now. However the application doesn't run completely yet. But that's another problem, I think... -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

wm_mousehover bug fix.....
by Mike Hearn Nov. 22, 2002

Nov. 22, 2002

Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all...... input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y << 8) + (pos.x)); I didn't think it was worth sending to wine-patches as it's just a 1 line fix and I didn't do it against wine cvs, but the last tarball release. That solves all my mouse handling issues with the ASV, so I'm a happy person once more. If somebody could apply that patch that'd be fab. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

4 3

RFC: console & curses
by Eric Pouech Nov. 22, 2002

Nov. 22, 2002

I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave: console creation can be invoked from different contexts: 1/ the program calls AllocConsole 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo') 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess 4/ the program doesn't request anything on the other hand, wineconsole is now able to handle two types of backend for the user interface: A/ USER: the one already in place B/ Curses: the new one using (n)curses and a regular term for display (N2) C/ no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading... now the final question, how to choose between A, B and C. the proposal is to fix the choice with: 1 => A 2 => B 3 => A 4 => C why such a directive proposal ? 4 => C is rather natural and doesn't need further explanation (one day, we could envisage to support it no longer, but that's another story) 1 => A greatly facilitates the console creation (ncurses requires both terminal control and moreover to keep the process group leader running as long as all the children - hooked to the same terminal - are running). Very few programs use AllocConsole (and even use it). The only issue may be with winedbg which may allocate its own console on startup (N3) 2 => B we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla' 3 => A here again it's easier to deal with. if trying to run a curses backend, we should ensure that two different wineconsoles are not currently hooked to the same terminal If you have any comments, speak up now !! A+ N1: 3/ can be seen from various aspects as a specific case of 1/, but implementation could implement it as 2/) N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list N3: IMO what's missing is that winedbg should check if has inheried a real console. If so, it should detach from it and recreate a new one.

3 16

Re: Rosetta, wine, sound bug?
by Jeff Smith Nov. 22, 2002

Nov. 22, 2002

>From: Sylvain Petreolle <spetreolle(a)yahoo.fr> > > > bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe > > trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) > > trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8) > > trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); > > trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' > > trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Shouldn't happen. > > trace:winmm:MMDRV_Install wineoss.drv => No description I get similar errors with MMDRV_GetDescription32. I assumed they were happening because the actual file wineoss.drv does not exist. Further, I assumed that MMDRV_GetDescription32 tries to get the description from locating the relevant record in the actual file. Please note that I have not had a chance to verify any of this. I have just recently taken an interest in wine's sound libraries, and would be glad to help out where I can. -- Jeff S _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Rosetta, wine, winex bug?
by ladies_man＠earthlink.net Nov. 22, 2002

Nov. 22, 2002

I have a problem with wine, and everyone says that it is a bug, so I suppose that it would have some relevance here. Any help or solutions would be helpful. I have three programs, wine, winex, and Rosetta. When I combine winex with Rosetta sound works fine, but then the display is royally messed up. When I use wine with Rosetta, the sound fails but everything else works beautifully. Computer Information: Make: Dell Inspiron 3800 Laptop Processor: 700mhz Celeron Ram: 128mb Distribution: Gentoo Linux, stage 1, highly optimized and custom compiled. Video Card: ATI Rage Mobility Sound Card: ESS Maestro3 Devices: /dev/mixer /dev/dsp /dev/cdroms/cdrom0 Here is my Wine config file: [Drive C] "Path" = "${HOME}/.wine/fake_windows" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" ;;[Drive D] ;;"Path" = "/path/to/drive_d" ;;"Type" = "hd" ;;"Label" = "LABEL" ;;"Filesystem" = "win95" [Drive E] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "CD-Rom" "Filesystem" = "win95" "Device" = "/dev/cdroms/cdrom0" [Drive F] "Path" = "/tmp" "Type" = "hd" "Label" = "Tmp Drive" "Filesystem" = "win95" [Drive H] "Path" = "${HOME}" "Type" = "network" "Label" = "Home" "Filesystem" = "win95" [Drive Z] "Path" = "/" "Type" = "network" "Label" = "Root" "Filesystem" = "win95" [wine] "Windows" = "c:\\Windows" "System" = "c:\\Windows\\System" "Temp" = "f:\\" "Path" = "c:\\Windows;c:\\Windows\\System;f:\\;h:\\;z:\\" "Profile" = "c:\\Windows\\Profiles\\Administrator" "GraphicsDriver" = "x11drv" ; Wine doesn't pass directory symlinks to Windows programs by default. ; Enabling this may crash some programs that do recursive lookups of a whole ; subdir tree in case of a symlink pointing back to itself. ;"ShowDirSymlinks" = "1" "ShellLinker" = "wineshelllink" # <wineconf> [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31)" }, ;"Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" ; Be careful here, wrong DllOverrides settings have the potential ; to pretty much kill your setup. [DllOverrides] "rpcrt4" = "builtin, native" "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "ver" = "builtin, native" "version" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "lzexpand" = "builtin, native" "lz32" = "builtin, native" "comctl32" = "builtin, native" "commctrl" = "builtin, native" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "mpr" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "opengl32" = "builtin, native" "msvcrt" = "native, builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "msacm" = "builtin, native" "msacm32" = "builtin, native" "midimap.drv" = "builtin, native" ; you can specify applications too "notepad.exe" = "native, builtin" ; default for all other dlls "*" = "native, builtin" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;"ScreenDepth" = "16" ; Name of X11 display to use ;;"Display" = ":0.0" ; Allow the window manager to manage created windows "Managed" = "N" ; Use a desktop window of 640x480 for Wine "Desktop" = "640x480" ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; Use XVidMode extension if present "UseXVidMode" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" ; Use this if you have more than one port for video on your setup ; (Wine uses for now the first 'input image' it finds). ;; "XVideoPort" = "43" ; Run in synchronous mode (useful for debugging X11 problems) ;;"Synchronous" = "Y" [fonts] ;Read the Fonts topic in the Wine User Guide before adding aliases ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" ;; default TrueType fonts with russian koi8-r encoding ;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;; default cyrillic bitmap X fonts ;"Default" = "-cronyx-helvetica-" ;"DefaultFixed" = "fixed" ;"DefaultSerif" = "-cronyx-times-" ;"DefaultSansSerif" = "-cronyx-helvetica-" ; the TrueType font dirs you want to make accessible to wine [FontDirs] ;"dir1" = "/usr/X11R6/lib/X11/fonts/TrueType" ;"dir2" = "/usr/share/fonts/truetype" ;"dir3" = "/usr/X11R6/lib/X11/fonts/TT" ;"dir4" = "/usr/share/fonts/TT" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/ttyS2" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;"read" = "0x779,0x379,0x280-0x2a0" ;"write" = "0x779,0x379,0x280-0x2a0" [Debug] ;"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"RelayInclude" = "user32.CreateWindowA" ;"SnoopExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"SpyExclude" = "WM_SIZE;WM_TIMER;" [registry] ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; supported styles are 'Win31'(default), 'Win95', 'Win98' ;; this has *nothing* to do with the windows version Wine returns: ;; set the "Windows" value in the [Version] section if you want that. "WineLook" = "Win95" [Console] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" ; List of all directories directly contain .AFM files [afmdirs] "1" = "/usr/share/ghostscript/fonts" "2" = "/usr/share/a2ps/afm" "3" = "/usr/share/enscript" "4" = "/usr/X11R6/lib/X11/fonts/Type1" [WinMM] "Drivers" = "wineoss.drv" #"Drivers" = "winearts.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [dsound] ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. ;"HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Kazaa Lite [AppDefaults\\Kazaa.exe\\DllOverrides] "shdocvw" = "native" "shlwapi" = "native" "urlmon" = "native" # </wineconf> Here is the output from the wine command: bash-2.05a$ wine -debugmsg +warn,+winmm,+winoss,+err,+fixme .wine/fake_windows/Program\ Files/The\ Rosetta\ Stone/The\ Rosetta\ Stone/Rosetta.exe trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) trace:winmm:WINMM_CreateIData Created IData (0x403f10a8) trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv trace:winmm:MMDRV_Install wineoss.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 6 dev for (wineoss.drv:Aux) trace:winmm:MMDRV_InitPerType Setting min=0 max=6 (ttop=6) for (wineoss.drv:Aux)trace:winmm:MMDRV_InitPerType Aux:Trans[0] -> w ineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[1] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[2] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[3] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[4] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[5] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Mixer:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiIn) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiOut) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('wavemapper', 'msacm.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file msacm.drv trace:winmm:MMDRV_Install msacm.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('midimapper', 'midimap.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_GetDescription32 Can't find file midimap.drv trace:winmm:MMDRV_Install midimap.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=0) for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType MidiOut:Trans[-1] -> midimapper trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutGetDevCapsA (0 0x406b22c4 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b22c4 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b22c4 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutMessage ((nil), 2058, 1080763140, 0) trace:winmm:MMDRV_PhysicalFeatures (0x403f2594, 080a, 406b2304, 00000000) trace:winmm:MMDRV_Message (WaveOut 0 2058 0x00000000 0x406b2304 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=2058 usr=0x00000000 p1=0x406b2304 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x4043334c, 0, Out, 0x40433338, 43630D38, 404330B0, 00030080, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=22050, nAvgBytesPerSec=44100, nBlockAlign=2, wBitsPerSample=8, cbSize=0 trace:winmm:WAVE_Open cb=43630d38 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b21a0 0x406b2220 0x00030080 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b21a0 p1=0x406b2220 p2=0x00030080 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b21c8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b21c8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutGetDevCapsA (4294967294 0x406b1f2c 52)! trace:winmm:waveOutGetDevCapsA (0 0x406b2068 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b2068 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b2068 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open ((nil), 0, Out, 0x40430808, 00000000, 00000000, 00000001, 32); trace:winmm:WAVE_Open WAVE_FORMAT_QUERY requested ! trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fb4 0x406b2034 0x00000001 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fb4 p1=0x406b2034 p2=0x00000001 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=(nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fac 0x406b202c 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fac p1=0x406b202c p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 404307f8); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b1fd4 0x404307f8 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b1fd4 p1=0x404307f8 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1fd4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1fd4 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b2210 0x406b2290 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b2210 p1=0x406b2290 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 406b233c); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b2238 0x406b233c 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b2238 p1=0x406b233c p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b2238 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b2238 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1ec0 0x406b1f40 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1ec0 p1=0x406b1f40 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b22b8 0x406b2338 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b22b8 p1=0x406b2338 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x0 0x1 bash-2.05a$ Now I have no clue what the problem is, many people have been working on this and none of them can figure it out. Both winex 20020807 and the 2.2.1 version have used the oss.drv's and they work. If anyone can help solve this problem I would greatly appreciate it, and if it is a bug, I hope you can fix it quickly. -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:54:44 This message was sent by XFMail ---------------------------------- -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:59:39 This message was sent by XFMail ----------------------------------

4 7

winspool.drv again
by Dimitrie O. Paun Nov. 22, 2002

Nov. 22, 2002

Alexandre, The winspool.drv issue is a lot more serious than the in-tree execution. This one screws things up badly for the PuTTY build system. Should we modify winebuild to try to link with winspool.drv, and if that fails with winspool.dll when -lwinspool is given? (or the other way around, I don't know) I'd really appreciate help on this one, so I can send the patch out. -- Dimi.

4 4

Wine and IrDA via Virtual Com Port
by Ryan Reading Nov. 22, 2002

Nov. 22, 2002

Hi all, This is my first time on this list. I've been playing around with Wine with quite a bit of success, but I've ran into a problem when trying to get an old program that uses IR to work correctly. I've already post on comp.emulators.ms-windows.wine and they referred my problem here. Here is the info that I have... For the record, I am running Wine 20021031. The program is based on the commercial Greenleaf Comm++ libraries. It is designed to be utilized in Windows on top of a *virtual* Com port running IrDA. The software itself knows nothing of IrDA, it's the *virtual* Com port's responsibility to provide that. Apparently it uses IrCOMM and TinyTP, but I'm just learning exactly what that means. I setup Linux to run IrDA through /dev/ttyS0 (the physical IR serial device) on /dev/ircomm0 (the IrDA device). I set "Com4" = "/dev/ircomm0". in the wine config file. I run the software with "--debugmsg +comm,+file" and look at the output. The software gets to a point where it performs some basic Serial port setup (SetupComm(), GetCommState(), SetCommState(), etc) and then I get the following... <snip> trace:file:Writefile 192 0x420b1190 14 0x4230a200 0x430a1530 trace:file:Writefile Overlapped not specified or invalid event flag <-- this is the interesting line trace:ClearCommError handle 0xc0 cbInQue = 0 cbOutQue = 0 ... last line repeated until timeout </snip> ( big apologies for not having a larger dump ) The pointer to the OVERLAPPED structure in this function is not set to NULL, but the hEvent member of that struct is set to ZERO (0), which seems to be the problem. I don't know why that member variable is set to ZERO (0), but that obviously keeps me from actually writing anything to the IR port. So my question involves how to approach this problem. I actually modified the Wine code to "overlook" the bad hEvent variable in WriteFile(), ReadFile(), and GetOverlappedResult() just for kicks to see what would happen. When I do that, it actually sends stuff over the IR connection and processes more ( additional ReadFile[Ex](), WriteFile[Ex](), GetOverlappedResult() calls ), but obviously the handshaking doesn't complete correctly since I'm ignoring the error checking. Could my problem be in the way IrDA is setup ( i.e. what is the correct way to emulate a Windows *virtual* COM port running IrDA in Wine )?? Any advice or information on this problem would be really appreciated. Thanks. -- Ryan

2 1

Debugging mouse messages
by Mike Hearn Nov. 22, 2002

Nov. 22, 2002

Hi, After setting up my dual crossover/winehq (last tarball release) installation, I tried doing some traces on IE with the adobe svg plugin. I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) -> 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=00000000,lp=00000000) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). I'm also confused by the reference to WINPROC_CallProc32ATo32W, is this normal? Google says it's used as part of 32bit<->16bit thunking, but there is no 16bit code here as far as I'm aware. Any ideas? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

2 3

Re: Screenshots
by Brian Vincent Nov. 22, 2002

Nov. 22, 2002

I've been meaning to put something together for a few days here.. > shots to Brian isn't the best way to go about it as nobody knows who has > sent what. Have you actually got any yet Brian? First, take a look at: http://www.theshell.com/~vinn/ss Quite a few folks have sent stuff in. Now, after looking at so many screenshots and trying to evaluate them for content I've realized a few things.. 1) We're absolutely going to have to insist on 800x600 resolution. Thanks for all the ones so far, but really the only usable ones are the 800x600. (There are exceptions, such as Mike's Quicktime one that can be resized nicely.) 2) Screenshots of an application doing something are the way to go. For instance, the one Mike just sent me showing Adobe's SVG plug-in in IE is WAY cool. Unfortunately it's not usable because of the resolution. Even a pull-down menu being pulled down is enough. 3) Cluttered desktops suck. You don't need to have 3 terminal windows, Mozilla, and everything else in the background. For the most part I think the screenshots have followed that rule closely. Okay, here's the deal.. Thomas Wickline volunteered to do screenshots of these apps: Office 2000 and everything in it lotus notes Quicken Quick Books visio Carlos Lozano did shots for the "gold" list apps. I'm going to ask him for some more here in the future.. (unbeknowst to him) The following would be nice to see: any game the exact same screenshot Mike Hearn sent of IE/SVG except at 800x600 Adobe Photoshop Anything else is fair game. I'll put screenshots on that URL above, so check there before doing any. -brian

6 5

Interesting control samples
by Mehmet YASAR Nov. 22, 2002

Nov. 22, 2002

Hi, I just found http://www.codejock.com/, they seems to provide a Toolkit to enhance any app (giving Microsoft's new UI look), the most interesting for Wine is that you can download 40 basic samples of different controls. Few notes : - A quick test shows that Wine can't launch any exe. - No source code is included I thought it may be a good test case ... Here is the list of samples included in XTSetupSamples_1931.exe : AccelDemo.exe BrowseDialog.exe BrowseEdit.exe Button.exe CaptionBar.exe CheckListBox.exe ColorPicker.exe CommonControls.exe CoolMenu.exe DockingDemo.exe EditListBox.exe FlatCombo.exe FlatHeader.exe FlatTabCtrl.exe FlatTabView.exe GUI_Explorer.exe GUI_Outlook.exe GUI_VisualStudio.exe GUI_WinZip.exe HexEdit.exe HyperLink.exe ListCtrl.exe MaskEdit.exe MDITabWindows.exe MultiFrameDocking.exe OutlookBar.exe Pager.exe PrintPreview.exe SearchOptions.exe SplitterWindow.exe StatusBar.exe TabbedView.exe TabCtrlBar.exe TabCtrl.exe TipOfTheDay.exe TipWindow.exe TrayIconDemo.exe TrayIconDlg.exe TreeCtrl.exe WindowPos.exe Mehmet

1 0