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

Re: winetest can't parse subtest for msvcrt(d)

by Saulius Krasuckas

On Wed, 18 Aug 2004, Ferenc Wagner wrote: > Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > > I think that's due to some additional \r\n-s in the output > > of "msvcrt_test.exe.so". > > Actually, not quite. The problem is that msvcrt's output > functions aren't redirected by libc's filehandle operations, > so winetest doesn't get the output (it gets printed to the > screen instead). Oh.. :-/ > Yeah, it's annoying, but doesn't hurt the meant functionality of > winetest, which shouldn't be run under Wine for anything but testing > purposes. The native (Windows) run doesn't show this problem, since > there we use msvcrt functions exclusively. Still it would be nice to > fix, but the proper way would be to fix Wine, and that's not entirely > trivial as Alexandre commented. Can you provide a link to the post or maybe some keywords to find it using google? Thanks.

Aug. 18, 2004

Re: winetest can't parse subtest for msvcrt(d)

by Ferenc Wagner

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > On Wed, 18 Aug 2004, Ferenc Wagner wrote: >> Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: >>> I think that's due to some additional \r\n-s in the output >>> of "msvcrt_test.exe.so". >> >> Actually, not quite. The problem is that msvcrt's output >> functions aren't redirected by libc's filehandle operations, >> so winetest doesn't get the output (it gets printed to the >> screen instead). > > Oh.. :-/ > >> Yeah, it's annoying, but doesn't hurt the meant functionality of >> winetest, which shouldn't be run under Wine for anything but testing >> purposes. The native (Windows) run doesn't show this problem, since >> there we use msvcrt functions exclusively. Still it would be nice to >> fix, but the proper way would be to fix Wine, and that's not entirely >> trivial as Alexandre commented. > > Can you provide a link to the post or maybe some keywords to find it using > google? Thanks. Try this for example: http://search.gmane.org/search.php?query=redirect+winetest&email=&group=gma… If you can't help feeling like hacking on winetest, I can send you my todo list, too... :) Or maybe I should put it into the source so that innocent bycomers can see it... -- Cheers, Feri.

Aug. 18, 2004

Re: WineSetupTk...

by michael＠cherryblossom.homelinux.com

On Wed, Aug 18, 2004 at 09:20:17AM +0100, Mike Hearn wrote: > >I didn't realize that WineSetupTk was depreciated when I wrote. I just > >want to play StarCraft and Diablo and was finding the documentation a bit > >hard to follow. (I couldn't find my .wine.conf file and got stuck, that's > >why I thought I needed WineSetupTk.) I will poke at it a bit myself and if > >I can figure out how it works, maybe then I can make a suggestion or two > >for clearing up the documentation. (Who maintains the documentation, BTW?) I doubt there's a one maintainer - if there was, it'd be listed with the documentation in credits or something, but maybe u can submit the patches somehow... maybe try reading sf policies on submitting stuff to a project? > > OK, what specifically were you trying to configure. Our aim (obviously) > is that StarCraft and such should work out of the box with no > configuration needed. > It's worth noting that an installation process that works with release A might not work on release B because there are improvements in (or not in) release B that require a different or appendment to the process (than) in release A, regardless of which is older/newer.

Aug. 18, 2004

winetest can't parse subtest for msvcrt(d)

by Saulius Krasuckas

On linuxe I get this: [s2(a)katleriai s2]$ wine /usr/local/lib/wine/winetest.exe.so Usage: /tmp/wctW5ad4P/msvcrt_test.exe.so test_name Valid test names: cpp environ file headers heap scanf string time ..while Wine Test Shell pops up a message box with the error text: "Can't parse subtests output of msvcrt". I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so". Here goes my observation and comparision to the case of "mlang_test.exe.so" (which works smoothly with the winetest): [s2(a)katleriai tests]$ wine msvcrt_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 73 76 63 72 74 5f 74 65 0000020 73 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 0000040 61 6d 65 0d 0a 0000045 [s2(a)katleriai tests]$ wine mlang_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 6c 61 6e 67 5f 74 65 73 0000020 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 61 0000040 6d 65 0a 0000043 As the "Valid test names:" string is printed by calling fprintf(), I suppose some differences arise due to incorrect linkage or such: [s2(a)katleriai tests]$ nm msvcrt_test.exe.so | grep fprintf 0001e100 D fprintf 0001e180 D vfprintf [s2(a)katleriai tests]$ nm mlang_test.exe.so | grep fprintf U fprintf@@GLIBC_2.0 U vfprintf@@GLIBC_2.0 It seems we realy are using msvcrt version of the fprintf(), which works in true-M$-way and adds an additional \r here. Next goes last lines from the build process: [s2(a)katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole cpp.o environ.o file.o headers.o heap.o scanf.o string.o time.o testlist.o -o msvcrt_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lmsvcrt [s2(a)katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole mlang.o testlist.o -o mlang_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lole32 -lgdi32 -lkernel32 -lntdll -luuid Can we fix it? I have no idea on how to link it right with the GLIBC. Of course, I am not sure this is the core of the problem. It would be nice to have winetest running in linux without such two hits (one for the msvcrt and another one for the msvcrtd). Or is this just my linux box configuration flawed?

Aug. 18, 2004

Re: winetest can't parse subtest for msvcrt(d)

by Ferenc Wagner

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > I think that's due to some additional \r\n-s in the output > of "msvcrt_test.exe.so". Actually, not quite. The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead). Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented. -- Cheers, Feri.

Aug. 18, 2004

Re: "winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

On Wed, 18 Aug 2004, Saulius Krasuckas wrote: > On Wed, 18 Aug 2004, Ferenc Wagner wrote: > > as I can't see why buffer should be dynamic at all. Please > > check it in case I made another mistake: > > Ok then. In this case "my" part of the patch can be omitted: > ..as "buffer" doesn't need to be preserved anymore. =) Sorry for that nonsense. Maybe I got overheated today.

Aug. 18, 2004

Re: Backtrace Dumps

by Robert Shearman

Andreas Mohr wrote: >P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, >and when considering how many fatal architecture changes winedbg had >to go through, it's amazing that it still works pretty well. :-) > > Yes, without his work this patch would have been impossible. A lot of the debugger has now been moved into dbghelp so that it can be used by other things than just the debugger. Rob

Aug. 18, 2004

Re: "winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

On Wed, 18 Aug 2004, Ferenc Wagner wrote: > > We can use the "str" instead of the "buffer". I've tried > > such mod and it worked fine in my case: > > Yes, your patch is good. Still I recommend something more, > as I can't see why buffer should be dynamic at all. Please > check it in case I made another mistake: Ok then. In this case "my" part of the patch can be omitted: > @@ -209,17 +208,15 @@ > if (ret) { > buffer[total] = 0; > str = strstr (buffer, "\r\n\r\n"); > - if (str) buffer = str + 4; > + str = str ? str+4 : buffer; > report (R_ERROR, "Can't submit logfile '%s'. " > - "Server response: %s", name, buffer); > + "Server response: %s", name, str); > } ..as "buffer" doesn't need to be preserved anymore. =)

Aug. 18, 2004

Re: WineSetupTk...

by Ivan Leo Puoti

>Ivan, do we need to remove links to sourceforge since its no longer >available? Actually iy is, but it isn't listed on the download page. Like all files on sf, you can't remove a release, but you can hide it. >I would guess so.. So do you want to do it or me? I'll send in a patch. Ivan.

Aug. 18, 2004

Re: "winetest" throws an exception after the unsuccessful send operation

by Ferenc Wagner

> Is it OK to try to free the modified "buffer" ptr? I > thought we should preserve its value. Yes, you are right, that code is illegal. The wonderful thing is that it's more than half a year old, and went unnoticed this far! Probably because the WineHQ server never failed during that period. Amazing. I wonder what have happened to it now. > We can use the "str" instead of the "buffer". I've tried > such mod and it worked fine in my case: Yes, your patch is good. Still I recommend something more, as I can't see why buffer should be dynamic at all. Please check it in case I made another mistake: Index: programs/winetest/send.c =================================================================== RCS file: /home/wine/wine/programs/winetest/send.c,v retrieving revision 1.12 diff -u -r1.12 send.c --- programs/winetest/send.c 6 Jul 2004 21:03:22 -0000 1.12 +++ programs/winetest/send.c 18 Aug 2004 11:26:02 -0000 @@ -107,7 +107,7 @@ SOCKET s; FILE *f; #define BUFLEN 8192 - unsigned char *buffer; + unsigned char buffer[BUFLEN+1]; size_t bytes_read, total, filesize; char *str; int ret; @@ -127,7 +127,6 @@ "Upload File\r\n" "--" SEP "--\r\n"; - buffer = xmalloc (BUFLEN + 1); s = open_http ("test.winehq.org"); if (s == INVALID_SOCKET) return 1; @@ -209,17 +208,15 @@ if (ret) { buffer[total] = 0; str = strstr (buffer, "\r\n\r\n"); - if (str) buffer = str + 4; + str = str ? str+4 : buffer; report (R_ERROR, "Can't submit logfile '%s'. " - "Server response: %s", name, buffer); + "Server response: %s", name, str); } - free (buffer); return ret; abort2: fclose (f); abort1: close_http (s); - free (buffer); return 1; } Thanks for the good spotting, Feri.

Aug. 18, 2004

"winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

I am getting this after all the tests were performed, network transfer of the report file was over and after the http server has responded (with some error-message) in Wine: err:win:WIN_FindWndPtr window 0x10022 belongs to other process err:win:WIN_FindWndPtr window 0x10022 belongs to other process wine: Unhandled exception (thread 000b), starting debugger... fixme:console:SetConsoleCtrlHandler (0x4067a644,1) - no error checking or testing yet WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0xffe5024c in 32-bit code (0x40045cf2). In 32 bit mode. 0x40045cf2 pthread_mutex_lock in libpthread.so.0: movl 0xc(%edi),%eax Wine-dbg>bt Backtrace: =>1 0x40045cf2 pthread_mutex_lock+0x12 in libpthread.so.0 (0x40c0fe28) 2 0x42075bea free+0x9a in libc.so.6 (0x40c0fe48) 3 0x4065753a send_file+0x362(name=0x781e4a80) [send.c:217] in winetest (0x40c0fe78) 4 0x40656f2e .L256+0xde in winetest (0x40c0fe9c) 5 0x4065511c __wine_exe_main+0x11c in winetest (0x40c0ff2c) 6 0x403a101a start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x40c0fff4) 7 0x4002a8cd wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) And the error message in the message-box looks like this: Can't submit logfile '/tmp/rescVOMCP'. Server response: <!DOCTYPE HTML PUBLIC"... ... <title>500 Internal Server Error</title> ... <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> ... <address>Apache 2.0.40 Server at test.winehq.org Port 80</address> <body><html> Back to the code. Excerpts from the programs/winetest/send.c: > unsigned char *buffer; ... > buffer = xmalloc (BUFLEN + 1); ... > if (ret) { > buffer[total] = 0; > str = strstr (buffer, "\r\n\r\n"); > if (str) buffer = str + 4; > report (R_ERROR, "Can't submit logfile '%s'. " > "Server response: %s", name, buffer); > } > free (buffer); Is it OK to try to free the modified "buffer" ptr? I thought we should preserve its value. We can use the "str" instead of the "buffer". I've tried such mod and it worked fine in my case: --- wine/programs/winetest/send.c 6 Jul 2004 21:03:22 -0000 1.12 +++ wine/programs/winetest/send.c 18 Aug 2004 07:41:24 -0000 @@ -209,9 +209,9 @@ if (ret) { buffer[total] = 0; str = strstr (buffer, "\r\n\r\n"); - if (str) buffer = str + 4; + str = (str)?(str + 4):(buffer); report (R_ERROR, "Can't submit logfile '%s'. " - "Server response: %s", name, buffer); + "Server response: %s", name, str); } free (buffer); return ret; Should I submit it to the wine-patches or I am wrong with it?

Aug. 18, 2004

Re: Backtrace Dumps

by Andreas Mohr

Hi, On Wed, Aug 18, 2004 at 09:27:53AM +0100, Mike Hearn wrote: > My problem with this approach is that it relies on the exception > actually getting through to the debugger instead of being trapped by the > program code and swallowed. I guess we could install a vectored handler > to boot the debugger and such but now the code is a lot more complex and > confusing for newbies than just having some inline functions in the > headers. As if the SEH code wasn't already confusing enough! Indeed. I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ... That's why a "no frills" debugging mechanism is a good idea IMHO. Andreas Mohr P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)

Aug. 18, 2004

Re: iostream and msvcrt?

by Boaz Harrosh

Scott Snell wrote: >Is that simpler than fixing the MSVCRT headers? > It is not wine-MSVCRT headers fault, these are pure CRT declarations. It is gcc-c++ headers that are heavily dependent on gcc CRT very non-standard headers. So you better go with STLPort. >I have used STLport before >so the idea sounds feasable to me. I imagine I have to change the >gcc-linux.mak by: > >replacing the call to gcc with winegcc, >removing references to GLIBC, > > Better go with gcc-mingw.mak, as threading and OS is more Windows than Linux. See if they have a -nocygwin variant. >adding a path pointing to /include/wine/MSVCRT. > > > Yes exactly. You'll see that you end up with a complete xxx-wine set of makefiles and headers. >Anything else? > > > There are some 1-2 defines in the major ARCH headers that go the windows way. I remember I had to define a __WINE_GCC__ in makefile and in a couple of places where they have this heavy #ifdef this #elseif that - I had to add #ifdef __WINE_GCC__ to point the compiler the windows way. But I guess the compiler will show you soon enough where he took the wrong turn. I'll try to dig out that HD anyway Just so we can compare notes. But I'm sure you'll manage before I have time to do that. >regards, > >Scott. > > Free Life Boaz

Aug. 18, 2004

Re: Backtrace Dumps

by Mike Hearn

Me too! *jumps up and down* In Java you can say this: new Exception().printBackTrace(); or some equivalent to get a printout of where you are, and it's very convenient. I can see the reasoning behind keeping the code in the debugger then triggering it using a custom exception though, as that way we only have one piece of backtracing code. My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough! > Wine has always had massive problems with getting easily accessible > debugging/diag support (doing debugging stuff IS hard, no question here...). > Thus I think we generally want not less, but more support, as long as it > helps (and as long as it doesn't cause a maintenance headache > or ill-maintained subsystems due to too much "choice" in debugging options...). > Since I'd think that that backtrace code should be fairly small and > self-maintaining, I'd vote for including it.

Aug. 18, 2004

Re: More winecfg todos

by Saulius Krasuckas

On Wed, 18 Aug 2004, Izak Burger wrote: > How about the Debian way of adding stubs to a .d directory... > > wine.d with lots of small easily editable .reg files. I'm sure this is > a silly suggestion, but if you REALLY have a problem with a 5000 line > .reg file (I sure did when I had to configure squid.. uggh), nothing > prevents you from doing this yourself and having a update-wine.conf > script, Debian style (refering to their exim4 setup). I have never been using the Debian distro and have no experience with a .d directories. Is there any newbie intro to this stuff on the net? Thanks. > Mike Hearn wrote: > > Maybe we should fork the Wine/Config branch into a separate .reg file to > > appease those who want to edit it using a text editor. That would make > > the switch from config file -> registry less obvious. Not exactly the > > same of course, no comments for one, no defaults to show you what they > > are for another, but it might be an improvement?

Aug. 18, 2004

Re: WineSetupTk...

by Mike Hearn

> I didn't realize that WineSetupTk was depreciated when I wrote. I just want to > play StarCraft and Diablo and was finding the documentation a bit hard to > follow. (I couldn't find my .wine.conf file and got stuck, that's why I > thought I needed WineSetupTk.) I will poke at it a bit myself and if I can > figure out how it works, maybe then I can make a suggestion or two for > clearing up the documentation. (Who maintains the documentation, BTW?) OK, what specifically were you trying to configure. Our aim (obviously) is that StarCraft and such should work out of the box with no configuration needed.

Aug. 18, 2004

Re: More winecfg todos

by Mike Hearn

> I think yes, for me it would an improvement. The only bad thing here is > my lack of the ideas on how to implement such forking. We already do it for user.reg vs system.reg, though in this case it's separate registry "hives". I'm not sure if we can do it on the key level. I'm certainly not bothered by this, and I think when people realise they hardly ever have to configure Wine it'll all blow over, but if somebody else wants to do the patch be my guest ...

Aug. 18, 2004

Re: More winecfg todos

by Izak Burger

I'm not too sure it will work for wine, it was just a wild suggestion. Debian uses it to get arround the problem of modifying certain config files. For example, if you install the nvidia drivers, you have to modify /etc/modules.conf. The usual way is to employ some perl or some other magic to add the line to the file, but Debian adds a file to /etc/modutils, and then runs the update-modules. The idea is that every small file in /etc/modutils contains only the lines relevant to the package it was installed by, and the modules.conf file is generated from these small files (in this case, by simply concatenating them together). The debian exim4 package has a similar setup (it is optional, if you want one big file you can still have it), but because exim4's config file has different sections, they have a directory for each section, with small files that are concatenated to make up the sections, and then the sections are assembled together to make a config file. Once again, say I install an antivirus like clamav or a spam checker like spamassassin, these packages need only drop a small file with their config settings into the correct directory and run the script update-exim4.conf to make a new config file. Now since the registry is just text in wine, and according to the feature we are talking about (splitting the old config stuff into a seperate reg file) this could work, but the reason why I said it is silly is because this would make editing of the registry with regedit an absolute mess, because 1) you will be editing the autogenerated file (and not the orriginal stubs) and 2) even if you could trace the way back to the original stubs, it just complicates matters unnecessarily. To split, or not to split, that is the question :-) It was a silly suggestion, but it would be an option so split seperate parts of the registry into seperate files if it REALLY becomes too unmanagable. But if you've ever had to configure squid, with it's default config file of several hundred lines, I'm sure you'll find this not to be such a big issue. Sometimes I should just shut up, I'm sure one of the _real_ developers will be along shortly to tell me why :-) Cheers, Izak Saulius Krasuckas wrote: > On Wed, 18 Aug 2004, Izak Burger wrote: > >>How about the Debian way of adding stubs to a .d directory... >> >>wine.d with lots of small easily editable .reg files. I'm sure this is >>a silly suggestion, but if you REALLY have a problem with a 5000 line >>.reg file (I sure did when I had to configure squid.. uggh), nothing >>prevents you from doing this yourself and having a update-wine.conf >>script, Debian style (refering to their exim4 setup). > > > I have never been using the Debian distro and have no experience with a .d > directories. Is there any newbie intro to this stuff on the net? Thanks. > > > >>Mike Hearn wrote: >> >>>Maybe we should fork the Wine/Config branch into a separate .reg file to >>>appease those who want to edit it using a text editor. That would make >>>the switch from config file -> registry less obvious. Not exactly the >>>same of course, no comments for one, no defaults to show you what they >>>are for another, but it might be an improvement? > > > >

Aug. 18, 2004

Re: Backtrace Dumps

by Andreas Mohr

Hi, On Wed, Aug 18, 2004 at 12:22:50AM -0400, Dimitrie O. Paun wrote: > On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote: > > Robert Shearman <rob(a)codeweavers.com> writes: > > > > I think it's better to let the debugger take care of that. If you > > don't want a real breakpoint you could define a custom exception to > > tell winedbg to just dump the backtrace and continue. > > I am not 100% how the patch that Robert's proposing would work in > practice, but I can tell you (from working with Java for a long > time now) that having readily available backtraces is invaluable. > > I for one love backtraces, but on the other hand I don't much > care for debuggers. Having access to them without being forced > to go through the debuger would be much appreciated. Dito. Wine has always had massive problems with getting easily accessible debugging/diag support (doing debugging stuff IS hard, no question here...). Thus I think we generally want not less, but more support, as long as it helps (and as long as it doesn't cause a maintenance headache or ill-maintained subsystems due to too much "choice" in debugging options...). Since I'd think that that backtrace code should be fairly small and self-maintaining, I'd vote for including it. -- A shocking 80% of unsolicited SPAM mails are being sent by zombie Windows PCs!!! http://www.theregister.co.uk/2004/06/04/trojan_spam_study/ Conclusion: use security-wise much more proactive systems such as Linux instead! Or at least make sure to patch and upgrade all Windows PCs you encounter!

Aug. 18, 2004

Re: More winecfg todos

by Izak Burger

How about the Debian way of adding stubs to a .d directory... wine.d with lots of small easily editable .reg files. I'm sure this is a silly suggestion, but if you REALLY have a problem with a 5000 line .reg file (I sure did when I had to configure squid.. uggh), nothing prevents you from doing this yourself and having a update-wine.conf script, Debian style (refering to their exim4 setup). Mike Hearn wrote: > > Maybe we should fork the Wine/Config branch into a separate .reg file to > appease those who want to edit it using a text editor. That would make > the switch from config file -> registry less obvious. Not exactly the > same of course, no comments for one, no defaults to show you what they > are for another, but it might be an improvement?

Aug. 18, 2004

Re: Interesting bug

by Francois Gouget

On Tue, 17 Aug 2004, Mike Hearn wrote: [...] > So... > > Save for Web works with: > wine "c:\program files\adobe\Photoshop 7.0\Photoshop.exe" > > Save for Web WILL NOT work with: > wine "c:/program files/adobe/Photoshop 7.0/Photoshop.exe" [...] > I don't have Photoshop here, but perhaps we should ensure that argv[0] > and equivalents always use backslashes? Remember that forward slashes are valid path separators on Windows. So we should first check whether the same problem happens on Windows, either by starting it that way on the command line or, even better (because cmd.exe might hack the command line before passing it to the system), from a CreateProcess call. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilis\xE9 par les informaticiens en lieu et place d'"idiot".

Aug. 18, 2004

Re: Backtrace Dumps

by Dimitrie O. Paun

On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > I think it's better to let the debugger take care of that. If you > don't want a real breakpoint you could define a custom exception to > tell winedbg to just dump the backtrace and continue. I am not 100% how the patch that Robert's proposing would work in practice, but I can tell you (from working with Java for a long time now) that having readily available backtraces is invaluable. I for one love backtraces, but on the other hand I don't much care for debuggers. Having access to them without being forced to go through the debuger would be much appreciated. -- Dimi.

Aug. 18, 2004

Re: winealsa dsound capture message patch

by Robert Reif

Try this one. Index: dlls/winmm/winealsa/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v retrieving revision 1.50 diff -u -r1.50 audio.c --- dlls/winmm/winealsa/audio.c 12 Aug 2004 23:00:52 -0000 1.50 +++ dlls/winmm/winealsa/audio.c 18 Aug 2004 03:23:23 -0000 @@ -244,19 +244,25 @@ static DWORD wodDsGuid(UINT wDevID, LPGUID pGuid); /* These strings used only for tracing */ -#if 1 -static const char *wodPlayerCmdString[] = { - "WINE_WM_PAUSING", - "WINE_WM_RESTARTING", - "WINE_WM_RESETTING", - "WINE_WM_HEADER", - "WINE_WM_UPDATE", - "WINE_WM_BREAKLOOP", - "WINE_WM_CLOSING", - "WINE_WM_STARTING", - "WINE_WM_STOPPING", -}; -#endif +static const char * getCmdString(enum win_wm_message msg) +{ + static char unknown[32]; +#define MSG_TO_STR(x) case x: return #x + switch(msg) { + MSG_TO_STR(WINE_WM_PAUSING); + MSG_TO_STR(WINE_WM_RESTARTING); + MSG_TO_STR(WINE_WM_RESETTING); + MSG_TO_STR(WINE_WM_HEADER); + MSG_TO_STR(WINE_WM_UPDATE); + MSG_TO_STR(WINE_WM_BREAKLOOP); + MSG_TO_STR(WINE_WM_CLOSING); + MSG_TO_STR(WINE_WM_STARTING); + MSG_TO_STR(WINE_WM_STOPPING); + } +#undef MSG_TO_STR + sprintf(unknown, "UNKNOWN(0x%08x)", msg); + return unknown; +} static DWORD bytes_to_mmtime(LPMMTIME lpTime, DWORD position, PCMWAVEFORMAT* format) @@ -839,8 +845,11 @@ snd_pcm_hw_params_get_access_mask(hw_params, acmask); /* FIXME: NONITERLEAVED and COMPLEX are not supported right now */ - if ( snd_pcm_access_mask_test( acmask, SND_PCM_ACCESS_MMAP_INTERLEAVED ) ) + if ( snd_pcm_access_mask_test( acmask, SND_PCM_ACCESS_MMAP_INTERLEAVED ) ) { +#if 0 wwi->caps.dwSupport |= WAVECAPS_DIRECTSOUND; +#endif + } } TRACE("Configured with dwFmts=%08lx dwSupport=%08lx\n", @@ -933,7 +942,9 @@ return 0; } if (omr->msg_toget != omr->msg_tosave && omr->messages[omr->msg_toget].msg != WINE_WM_HEADER) - FIXME("two fast messages in the queue!!!!\n"); + FIXME("two fast messages in the queue!!!! toget = %d(%s), tosave=%d(%s)\n", + omr->msg_toget,getCmdString(omr->messages[omr->msg_toget].msg), + omr->msg_tosave,getCmdString(omr->messages[omr->msg_tosave].msg)); /* fast messages have to be added at the start of the queue */ omr->msg_toget = (omr->msg_toget + omr->ring_buffer_size - 1) % omr->ring_buffer_size; @@ -1342,7 +1353,7 @@ int err; while (ALSA_RetrieveRingMessage(&wwo->msgRing, &msg, &param, &ev)) { - TRACE("Received %s %lx\n", wodPlayerCmdString[msg - WM_USER - 1], param); + TRACE("Received %s %lx\n", getCmdString(msg), param); switch (msg) { case WINE_WM_PAUSING: @@ -2803,6 +2814,10 @@ widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); lpWaveHdr = lpNext; } + } else { + TRACE("read(%s, %p, %ld) failed (%s)\n", wwi->device, + lpWaveHdr->lpData + lpWaveHdr->dwBytesRecorded, + frames_per_period, strerror(errno)); } } else @@ -2814,6 +2829,12 @@ TRACE("bytesRead=%ld (local)\n", bytesRead); + if (bytesRead == (DWORD) -1) { + TRACE("read(%s, %p, %ld) failed (%s)\n", wwi->device, + buffer, frames_per_period, strerror(errno)); + continue; + } + /* copy data in client buffers */ while (bytesRead != (DWORD) -1 && bytesRead > 0) { @@ -2853,7 +2874,7 @@ LPWAVEHDR hdr; ALSA_RetrieveRingMessage(&wwi->msgRing, &msg, &param, &ev); hdr = ((LPWAVEHDR)param); - TRACE("msg = %s, hdr = %p, ev = %p\n", wodPlayerCmdString[msg - WM_USER - 1], hdr, ev); + TRACE("msg = %s, hdr = %p, ev = %p\n", getCmdString(msg), hdr, ev); hdr->lpNext = 0; if (lpWaveHdr == 0) { /* new head of queue */ @@ -2887,7 +2908,7 @@ while (ALSA_RetrieveRingMessage(&wwi->msgRing, &msg, &param, &ev)) { - TRACE("msg=%s param=0x%lx\n", wodPlayerCmdString[msg - WM_USER - 1], param); + TRACE("msg=%s param=0x%lx\n", getCmdString(msg), param); switch (msg) { case WINE_WM_PAUSING: wwi->state = WINE_WS_PAUSED; @@ -3399,6 +3420,40 @@ } /************************************************************************** + * widDsCreate [internal] + */ +static DWORD widDsCreate(UINT wDevID, PIDSCDRIVER* drv) +{ + TRACE("(%d,%p)\n",wDevID,drv); + + /* the HAL isn't much better than the HEL if we can't do mmap() */ + FIXME("DirectSoundCapture not implemented\n"); + MESSAGE("The (slower) DirectSound HEL mode will be used instead.\n"); + return MMSYSERR_NOTSUPPORTED; +} + +/************************************************************************** + * widDsDesc [internal] + */ +static DWORD widDsDesc(UINT wDevID, PDSDRIVERDESC desc) +{ + memcpy(desc, &(WInDev[wDevID].ds_desc), sizeof(DSDRIVERDESC)); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widDsGuid [internal] + */ +static DWORD widDsGuid(UINT wDevID, LPGUID pGuid) +{ + TRACE("(%d,%p)\n",wDevID,pGuid); + + memcpy(pGuid, &(WInDev[wDevID].ds_guid), sizeof(GUID)); + + return MMSYSERR_NOERROR; +} + +/************************************************************************** * widMessage (WINEALSA.@) */ DWORD WINAPI ALSA_widMessage(UINT wDevID, UINT wMsg, DWORD dwUser, @@ -3427,9 +3482,9 @@ case WIDM_STOP: return widStop (wDevID, (LPWAVEHDR)dwParam1, dwParam2); case DRV_QUERYDEVICEINTERFACESIZE: return widDevInterfaceSize (wDevID, (LPDWORD)dwParam1); case DRV_QUERYDEVICEINTERFACE: return widDevInterface (wDevID, (PWCHAR)dwParam1, dwParam2); - /*case DRV_QUERYDSOUNDIFACE: return widDsCreate (wDevID, (PIDSCDRIVER*)dwParam1); + case DRV_QUERYDSOUNDIFACE: return widDsCreate (wDevID, (PIDSCDRIVER*)dwParam1); case DRV_QUERYDSOUNDDESC: return widDsDesc (wDevID, (PDSDRIVERDESC)dwParam1); - case DRV_QUERYDSOUNDGUID: return widDsGuid (wDevID, (LPGUID)dwParam1);*/ + case DRV_QUERYDSOUNDGUID: return widDsGuid (wDevID, (LPGUID)dwParam1); default: FIXME("unknown message %d!\n", wMsg); }

Aug. 18, 2004

Re: Wine Status - User Interface

by michael＠cherryblossom.homelinux.com

On Mon, Aug 16, 2004 at 01:44:01PM -0500, James Hawkins wrote: > ---------- Forwarded message ---------- > From: James Hawkins <truiken(a)gmail.com> > Date: Mon, 16 Aug 2004 13:43:21 -0500 > Subject: Re: Wine Status - User Interface > To: twickline(a)sitestar.net > > Hey Tom, > > printdlg AFAIK is very close to being complete. The only things I can > think of that would need to be done concerning the print dialog is to > verify how windows handles the printer stats (Status, Type, Where, > Comment) when no printer is selected/installed. Another thing that > could be implemented is the printer help. I will have to test out the > print properties dialog when i set up my printer in a week. I dont > really know anything about Page Setup or Print Property Sheet, but I > will definitely look into it now. > I'm not sure this helps, but as a Windows user, I recall that Page Setup usually goes into things like: Page Size (i.e. A4/Letter/Legal, etc.), Page Margins, Orientations, among other things -- in most linux based systems, such as CUPS, that is set in either command line options or in the actual printer configuration, something which might be tricky. If I remember right, Print Properties (or a similar dialog) goes into printer/driver specific setup options, such as the print quality and such, and testing features - and is similar or the same as the software included with most printers, such as the HP Toolbox provided with some HP Inkjets. This may or may not vary from software to software, from windows version to windows version, or from printer to printer. [snip] Hope I helped any. -Michael Chang

Aug. 18, 2004

Re: Menu problem: top menu drawn ok, pulldowns miss text

by michael＠cherryblossom.homelinux.com

On Mon, Aug 16, 2004 at 07:02:48PM +0200, Tobias Burnus wrote: > Hello, > > I have a strange problem with the Cambridge Advanced Learner's > Dictionary. It, finally?, starts up but (besides other problems) there > is a glitch in the menu. The menu bar looks ok, the dropdown menus work, > but the items are empty. The (single?) submenu works again. > > See http://www.physik.fu-berlin.de/~tburnus/wine/cald2.png > > Has anyone an ad-hoc idea or knows which are the best debugging flags? > Even with the default setting I get hundreds of such lines: > fixme:ddraw:Main_DirectDrawClipper_SetClipList > (0x40410e80,0x4067ea8c,0),stub! > Thus I want to do a wise choise for the menus. If memory serves me right, stubs are incomplete pieces of code that need to be fixed/written/updated, hense the fixme notice -- maybe you want to look into trying to code this from a recent CVS and submitting a patch somehow? I'm new to wine-devel though, so I'm not sure. Maybe the others can help better? > (At the startup, it comes up with an open File menu and the menu item > "Menu 1" to "Menu 7" which closes after a few seconds by itself: > http://www.physik.fu-berlin.de/~tburnus/wine/cald3.png) > > Regards, > > Tobias > [snip] Hope I helped. -Michael

Aug. 18, 2004