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

Interesting Winelib report
by Jeremy White March 8, 2007

March 8, 2007

Hi Folks, John Gilmore alerted me to an attempted use of Winelib by the Cairo folks: http://lists.freedesktop.org/archives/cairo/2007-February/009707.html I've chatted privately with Behdad, who doesn't have a ton of time, but would be willing to poke a bit further if he had some help. I know that from time to time, people like to pick up this sort of project as a fun one, and I thought I'd see if I could spark someone into doing so with Cairo. Cheers, Jeremy

1 0

-Wcast-qual result
by Mike Schaadt March 8, 2007

March 8, 2007

I submited a patch today that modified unicode.h that disables warnings(which allows for -Wcast-qual to actually give relevant results) I don't know if it will be accepted or not(it has the potential of being problematic if modifying unicode.h that would normally result in a warning, but this patch would cause it to be suppresed), but I figured I would at least share the results I found. after configuring with cast-qual, I stored the warnings that resulted(which I've included as an attachment for those that are interested.). There were no warnings in the make depend, and make generated 545 warnings(all from .c files). The included file does not contain the sub directory for what file generates the warning. If anyone knows how to pull that data, let me know and I'll redo it and extract that information as well. I plan on start looking through these and working on fixing some here soon, but I thought I would share what I found with this group in general.

1 0

Re: wine-devel Digest, Vol 20, Issue 30
by Alessandro Pignotti March 8, 2007

March 8, 2007

> Date: Thu, 8 Mar 2007 08:22:59 +0100 > From: Kai Blin <kai.blin(a)gmail.com> > > > /* FIXME: Should we be storing these dwFlags or the creation ones? */ > > - lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName, dwFlags, > > + /* I think we should pass creation flags, so we can distinguish > > sysplayers and not count them in the current + player total */ > > + lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName, > > dwCreateFlags, hEvent, bAnsi ); > > Every time someone uses "I think" in the code, usually this calls for a > test case. This one should be rather straightforward to test. It's not possible to write a conformance test because i'm using a flag internal to wine's implementation of directplay, It's possible to safely change "I think we should" with "we have to". I've used "i think" more as an answer to the previous FIXME comment we have inherited from the author of the code. Regards Alessandro Pignotti > > Cheers, > Kai > > -- > Kai Blin, <kai Dot blin At gmail Dot com> > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin/ > -- > Will code for cotton. -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

2 1

Serial port problem - again
by Aleš Rom March 8, 2007

March 8, 2007

Hello. I'm new to this list. First I must say that I apologise for posting this mail again here. I hope you wine gurus can see what is going wrong here. If I run this app <http://appdb.winehq.org/appview.php?iAppId=4165> with WINEDEBUG=+relay , I can transfer data from my device to PC, but not all of it. It stops somewhere in the middle of the transfer. Without +relay option, device is not even accesible. It just say: [romcek(a)core2 ~]$ WINEDEBUG=+trace,+comm wine /home/romcek/.wine/drive_c/Program\ Files/SMA/Sunny\ Data\ Control/SDC.exe err:systray:delete_icon invalid tray icon ID specified: 0d fixme:tapi:lineInitialize (0x832f88, 0x11c0000, 0x11c2dfc, "TAPICOMM", 0x832f8c): stub. fixme:tapi:lineGetDevCapsA ((nil), 00000000, 00010003, 00000000, 0xf7eaf8): stub. fixme:tapi:lineGetDevCapsA ((nil), 00000000, 00010003, 00000000, 0xf7eb2c): stub. fixme:ras:RasEnumEntriesA ((nil),(null),0xf7fc80,0x34f5d8,0xf7ec38),stub! fixme:ras:RasEnumDevicesA ((nil),0x34f60c,0x34f608),stub! fixme:ras:RasEnumDevicesA (0x777fe0,0x34f60c,0x34f608),stub! trace:comm:GetCommState handle 0x144, ptr 0x34f9b8 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x34f988 4 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x34f98d 3 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x34f970 16 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_CHARS (nil) 0 0x34f982 6 0x34f914 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=1 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:io_control 0x144 IOCTL_SERIAL_SET_BAUD_RATE 0x34f988 4 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_LINE_CONTROL 0x34f98d 3 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_HANDFLOW 0x34f970 16 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_CHARS 0x34f982 6 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_QUEUE_SIZE 0x34f98c 8 (nil) 0 0x34f930 fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 last line is repeating and then nothing hapens. It looks like delay issue to me, but I'm not a programmer. Can someone help, plese. Thanks, Ales

1 0

[winealsa] Mind buffer loops when pausing
by Chris Bandy March 8, 2007

March 8, 2007

This patch should fix the incorrect handling of WaveHdr loops when pausing. Like the non-loop case written before, this sums the buffer lengths between dwPlayedTotal and dwWrittenTotal to calculate the new dwPartialOffset. Instead of blindly moving from one buffer to the next, however, this traverses the list using BeginWaveHdr and PlayPtrNext. This has added benefit of correctly initializing all pointers and counters for playback. It looks correct on paper, but I don't seem to have any applications that even attempt to pause. Can anyone suggest an application to test this with? All feedback welcome. Note: this branch in the function is a 'software' pause. To test you may need to override the check for ALSA's hardware pause at line 418 (snd_pcm_hw_params_can_pause) -- Chris diff --git a/dlls/winealsa.drv/waveout.c b/dlls/winealsa.drv/waveout.c index 6a8a435..4ac50c6 100644 --- a/dlls/winealsa.drv/waveout.c +++ b/dlls/winealsa.drv/waveout.c @@ -319,9 +319,9 @@ static DWORD wodPlayer_NotifyCompletions(WINE_WAVEDEV* wwo, BOOL force) * * wodPlayer helper. Resets current output stream. */ -static void wodPlayer_Reset(WINE_WAVEDEV* wwo, BOOL reset) +static void wodPlayer_Reset(WINE_WAVEDEV* wwo, BOOL reset) { - int err; + int err; TRACE("(%p)\n", wwo); /* flush all possible output */ @@ -329,7 +329,7 @@ static void wodPlayer_Reset(WINE_WAVEDEV* wwo, BOOL reset) wodUpdatePlayedTotal(wwo, NULL); /* updates current notify list */ - wodPlayer_NotifyCompletions(wwo, FALSE); + wodPlayer_NotifyCompletions(wwo, reset); if ( (err = snd_pcm_drop(wwo->pcm)) < 0) { FIXME("flush: %s\n", snd_strerror(err)); @@ -345,9 +345,6 @@ static void wodPlayer_Reset(WINE_WAVEDEV* wwo, BOOL reset) DWORD param; HANDLE ev; - /* remove any buffer */ - wodPlayer_NotifyCompletions(wwo, TRUE); - wwo->lpPlayPtr = wwo->lpQueuePtr = wwo->lpLoopPtr = NULL; wwo->state = WINE_WS_STOPPED; wwo->dwPlayedTotal = wwo->dwWrittenTotal = 0; @@ -368,32 +365,34 @@ static void wodPlayer_Reset(WINE_WAVEDEV* wwo, BOOL reset) ((LPWAVEHDR)param)->dwFlags &= ~WHDR_INQUEUE; ((LPWAVEHDR)param)->dwFlags |= WHDR_DONE; - wodNotifyClient(wwo, WOM_DONE, param, 0); + wodNotifyClient(wwo, WOM_DONE, param, 0); } ALSA_ResetRingMessage(&wwo->msgRing); LeaveCriticalSection(&wwo->msgRing.msg_crst); } else { - if (wwo->lpLoopPtr) { - /* complicated case, not handled yet (could imply modifying the loop counter */ - FIXME("Pausing while in loop isn't correctly handled yet, except strange results\n"); - wwo->lpPlayPtr = wwo->lpLoopPtr; - wwo->dwPartialOffset = 0; - wwo->dwWrittenTotal = wwo->dwPlayedTotal; /* this is wrong !!! */ - } else { - LPWAVEHDR ptr; - DWORD sz = wwo->dwPartialOffset; + DWORD diff = wwo->dwWrittenTotal - wwo->dwPlayedTotal; + DWORD sz; + + /* no pointers or counters need to change */ + if (diff <= wwo->dwPartialOffset) + wwo->dwPartialOffset -= diff; + else { + wwo->lpLoopPtr = NULL; + wodPlayer_BeginWaveHdr(wwo, wwo->lpQueuePtr); - /* reset all the data as if we had written only up to lpPlayedTotal bytes */ - /* compute the max size playable from lpQueuePtr */ - for (ptr = wwo->lpQueuePtr; ptr != wwo->lpPlayPtr; ptr = ptr->lpNext) { - sz += ptr->dwBufferLength; + diff -= wwo->dwPartialOffset; + sz = wwo->lpPlayPtr->dwBufferLength; + + while (sz < diff) { + wodPlayer_PlayPtrNext(wwo); + sz += wwo->lpPlayPtr->dwBufferLength; } - /* because the reset lpPlayPtr will be lpQueuePtr */ - if (wwo->dwWrittenTotal > wwo->dwPlayedTotal + sz) ERR("grin\n"); - wwo->dwPartialOffset = sz - (wwo->dwWrittenTotal - wwo->dwPlayedTotal); - wwo->dwWrittenTotal = wwo->dwPlayedTotal; - wwo->lpPlayPtr = wwo->lpQueuePtr; + + wwo->dwPartialOffset = sz - diff; + wodPlayer_BeginWaveHdr(wwo, wwo->lpQueuePtr); } + + wwo->dwWrittenTotal = wwo->dwPlayedTotal; wwo->state = WINE_WS_PAUSED; } }

2 1

Writing a winelib plugin
by Shachar Shemesh March 8, 2007

March 8, 2007

Hi all, It used to not be possible to write a plugin, to be loaded from a standard Linux ELF program, that will be itself a winelib shared object. All sorts of issues regarding running wineserver and memory layout initializations were problematic. I'm wondering whether there is any news on that front. Is it still not practically possible to do this? Many thanks, Shachar

1 0

Re: Alexandre Julliard : wine_common_ver: Set company name to Microsoft, some apps check for that.
by Paul Chitescu March 8, 2007

March 8, 2007

Hi! Ummm, isn't this legally dangerous? Stamping a piece of code with Microsoft's name can be interpreted as counterfeiting. Maybe a better choice would be to add a configure option --with-company-name and let the users set it to... whatever... Paul Chitescu

4 3

Re: [RESEND] [PATCH] DirectPlay should keep track of the current number of players
by Kai Blin March 8, 2007

March 8, 2007

On Wednesday 07 March 2007 10:52, Alessandro Pignotti wrote: > + /* I think we have to add a player to the total number of players only if it's not a player created for system > + purpose like the name server. This way it seems we get a correct player number */ > + if( ~dwFlags & DPLAYI_PLAYER_SYSPLAYER ) > + This->dp2->lpSessionDesc->dwCurrentPlayers++; > + [...] > /* FIXME: Should we be storing these dwFlags or the creation ones? */ > - lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName, dwFlags, > + /* I think we should pass creation flags, so we can distinguish sysplayers and not count them in the current > + player total */ > + lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName, > dwCreateFlags, hEvent, bAnsi ); Every time someone uses "I think" in the code, usually this calls for a test case. This one should be rather straightforward to test. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

RS232 latency, redirection possible?
by [IDC]Dragon March 7, 2007

March 7, 2007

Hi, I have 2 questions about the serial port handling under Wine: 1) I see a very annoying latency in an application which talks to a controller over RS232. Under Windows, the traffic is "fluent", under Wine each command has a turnaround time of almost a second. Since there are many commands, this gets useless. I sthere anything known, some settings I can try? 2) Is it possible to map the e.g. COM1 port traffic to another device, or is it firmly assigned to matching RS232 interfaces of the Linux box? Ideally, I'd like to have the Windows app talk to an XPort device (remote RS232) connected over network. A program called "socat" (http://www.dest-unreach.org/socat) can be used to create a device and tunnel the traffic over a TCP port. I'd like to map that device to a windows-emulated COM port. Maybe this even eliminates problem 1). I hope I was able to explain especially 2) and kindly wait for answers, thanks! Jörg -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

3 4

wininet: Don't discard the extra info part of a URL in InternetOpenUrl.
by Ron Yorston March 7, 2007

March 7, 2007

A fix to winnet/internet.c turned up in 0.9.32 that's supposed to ensure that the "extra info" part of a URL is correctly included. I think there's a problem with the patch. On line 2865 space is allocated for the extra info: if (!(path_extra = HeapAlloc(GetProcessHeap(), 0, size))) Shouldn't this be in units of sizeof(WCHAR)? That is, if (!(path_extra = HeapAlloc(GetProcessHeap(), 0, size*sizeof(WCHAR)))) Ron

2 1