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

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