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

Re: LockFile - any words of warning?

by Rein Klazes

On Thu, 1 Nov 2001 07:45:46 -0800, you wrote: > Thanks > "Rein Klazes" <rklazes(a)xs4all.nl> wrote in message > news:200110311858.f9VIwgms055574(a)smtpzilla2.xs4all.nl... > > On Wed, 31 Oct 2001 10:37:11 -0800, you wrote: > > > > > > > > > > Have a look at Corel's wine tree, where it is implemented. > > > > > > Please excuse my ignorance; how do I get at the Corel tree? > > > > Hmm, the instructions seem to have been moved off Corel's site and not > > reappeared at Xandra's yet. > > BTW what is Xandra all about? (e.g. what url?) Sorry it is Xandros, it seems they bought corel's linux business. I was forwarded to their site when I tried to locate the page where the instructions downloading corelwine used to be: http://linux.corel.com/opensource/ The original page is btw, still at http://opensource.corel.com Rein. -- Rein Klazes rklazes(a)xs4all.nl

Nov. 1, 2001

Re: change cdrom?

by eric pouech

> mount. Not a very pretty solution but it worked. > Do you guys know of a better solution? some fixes are floating around. try latest cvs, it may be fully fixed A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Nov. 1, 2001

Re: change cdrom?

by Per Wigren

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again! I found a solution: I'm lucky enough to have 2 "cdroms"... 1 dvd and 1 cdrw. The solution was to put cd2 in the other drive and mount it OVER the first mount. Not a very pretty solution but it worked. Do you guys know of a better solution? Personally I think that "wine d:setup.exe" would be better.. Regards Per Wigren BTW, sorry for posting this on the devel-list instead of user. I've lost my mailaccount that was subscribed to wine-users. Thursday 01 November 2001 18.24 skrev du: > Hi! > I have an annoying problem installing Grim Fandango. > It comes on 2 cds. If I mount the cd and run "wine setup.exe" it starts to > install until it asks for cd #2. But I can't unmount the CD to put in cd2 > because it's busy... > If I run "eject", it ejects but it still seems to be cached so it doesn't > recognize that I've changed cd! > Also: > # wine D:\\setup.exe > with the cdrom unmounted doesn't work either... :( > Any solution to this problem? > > Regards > Per Wigren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74Y//yjnjcyLO8HkRAiOoAJ9DFa739Gcbo7lqrczSVlROSQJk9wCfS3BM votIGfjMtJIk4akHfd6BrXI= =weMU -----END PGP SIGNATURE-----

Nov. 1, 2001

change cdrom?

by Per Wigren

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I have an annoying problem installing Grim Fandango. It comes on 2 cds. If I mount the cd and run "wine setup.exe" it starts to install until it asks for cd #2. But I can't unmount the CD to put in cd2 because it's busy... If I run "eject", it ejects but it still seems to be cached so it doesn't recognize that I've changed cd! Also: # wine D:\\setup.exe with the cdrom unmounted doesn't work either... :( Any solution to this problem? Regards Per Wigren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74YVNyjnjcyLO8HkRAuJmAKCbfxoGueuTnzVO4PZ2W1MQB7hIrgCgmhQt MembJfuT4wVuZyERmHMd+VM= =npbq -----END PGP SIGNATURE-----

Nov. 1, 2001

Re: LockFile - any words of warning?

by Bill Medland

Thanks "Rein Klazes" <rklazes(a)xs4all.nl> wrote in message news:200110311858.f9VIwgms055574(a)smtpzilla2.xs4all.nl... > On Wed, 31 Oct 2001 10:37:11 -0800, you wrote: > > > > > > > Have a look at Corel's wine tree, where it is implemented. > > > > Please excuse my ignorance; how do I get at the Corel tree? > > Hmm, the instructions seem to have been moved off Corel's site and not > reappeared at Xandra's yet. BTW what is Xandra all about? (e.g. what url?)

Nov. 1, 2001

Re: audio.c converted from WaitForSingleObject to poll

by eric pouech

> What I've done instead is reversed my poll patch and > added a patch to mmsystem.c which causes application > (and possibly some non-application) callbacks to be > called from a different thread so that > wodPlayer_Notify doesn't ever halt waiting for the > application to return (which may in turn be waiting on > wodReset,wodRestart, wodClose, wodPause etc). I'll > post this to wine-patches in just a moment. well, I think it's a bit overkill. furthermore, this won't let synchronize that the notification has been done before returning from the call. this stops waiting in notify, but doesn't synchronize at the end (except if you wrap every entry point in winmm/mmsys which might generate a notification with a synchro with this extra thread) I think we should not use a general event for the synchro in audio.c, but rather create a new event for each time we need to wait (wodReset...) and pass it to the WWO_MSG struct, hence removing the race condition. does the attached patch solves your issue ? > With the audio.c poll patch I posted, wodPlayer_Notify > doesn't update the total bytes played until after > sufficient time has elapsed for the dsp to have > finished playing it. The absence of more data to send > to the dsp may stop the polling loop before all sounds > have been played, meaning that the total bytes for a > the last sample written may not be updated until the > next wave is queued to be written to the dsp. > It appears that HL loops checking wodGetPosition until > the last sound has been played before writing the next > sound. This never happens with my poll patch because > of the issue in the previous para. Hence: no sound. > I verified this by doing another evil hack which just > notified and updated total bytes as soon as they were > written. The sound returned. ok (I didn't get it was with the poll patch applied) but OTOH, the poll patch can have nasty effects: 1/ let's assume an app uses only two wavehdr:s which cumuled size if smaller than the OSS play ring 2/ the app will send the two wavehdr:s and they will be queued and written to /dev/dsp 3/ if we use the modification to not have the busy wait, then no notification will be ever made (IIRC some Flash apps are doing this). They normally wait for notification to occur in order to resubmit the same wavehdr:s will different values so, I think the poll patch (even with some modifications) introduces some more evil parts than it fixes (and your deadlock issues don't come from the playback loop) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.44 diff -u -r1.44 audio.c --- dlls/winmm/wineoss/audio.c 2001/08/18 16:09:41 1.44 +++ dlls/winmm/wineoss/audio.c 2001/11/01 10:19:52 @@ -87,6 +87,7 @@ typedef struct { int msg; DWORD param; + HANDLE hEvent; } WWO_MSG; typedef struct { @@ -109,9 +110,9 @@ DWORD dwRemain; /* number of bytes to write to end the current fragment */ /* synchronization stuff */ + HANDLE hStartUpEvent; HANDLE hThread; DWORD dwThreadID; - HANDLE hEvent; #define WWO_RING_BUFFER_SIZE 30 WWO_MSG messages[WWO_RING_BUFFER_SIZE]; int msg_tosave; @@ -522,29 +523,40 @@ } -int wodPlayer_Message(WINE_WAVEOUT *wwo, int msg, DWORD param) +static int wodPlayer_Message(WINE_WAVEOUT *wwo, int msg, DWORD param, BOOL wait) { + HANDLE hEvent; + EnterCriticalSection(&wwo->msg_crst); if ((wwo->msg_tosave == wwo->msg_toget) /* buffer overflow ? */ - && (wwo->messages[wwo->msg_toget].msg)) + && (wwo->messages[wwo->msg_toget].msg)) { ERR("buffer overflow !?\n"); LeaveCriticalSection(&wwo->msg_crst); return 0; } + hEvent = wait ? CreateEventA(NULL, FALSE, FALSE, NULL) : INVALID_HANDLE_VALUE; + wwo->messages[wwo->msg_tosave].msg = msg; wwo->messages[wwo->msg_tosave].param = param; + wwo->messages[wwo->msg_tosave].hEvent = hEvent; + wwo->msg_tosave++; if (wwo->msg_tosave > WWO_RING_BUFFER_SIZE-1) wwo->msg_tosave = 0; LeaveCriticalSection(&wwo->msg_crst); /* signal a new message */ SetEvent(wwo->msg_event); + if (wait) + { + WaitForSingleObject(hEvent, INFINITE); + CloseHandle(hEvent); + } return 1; } -int wodPlayer_RetrieveMessage(WINE_WAVEOUT *wwo, int *msg, DWORD *param) +static int wodPlayer_RetrieveMessage(WINE_WAVEOUT *wwo, int *msg, DWORD *param, HANDLE *hEvent) { EnterCriticalSection(&wwo->msg_crst); @@ -557,6 +569,7 @@ *msg = wwo->messages[wwo->msg_toget].msg; wwo->messages[wwo->msg_toget].msg = 0; *param = wwo->messages[wwo->msg_toget].param; + *hEvent = wwo->messages[wwo->msg_toget].hEvent; wwo->msg_toget++; if (wwo->msg_toget > WWO_RING_BUFFER_SIZE-1) wwo->msg_toget = 0; @@ -642,6 +655,7 @@ DWORD param; DWORD tc; BOOL had_msg; + HANDLE ev; wwo->state = WINE_WS_STOPPED; @@ -652,7 +666,7 @@ wwo->dwPlayedTotal = 0; TRACE("imhere[0]\n"); - SetEvent(wwo->hEvent); + SetEvent(wwo->hStartUpEvent); for (;;) { /* wait for dwSleepTime or an event in thread's queue @@ -684,17 +698,17 @@ TRACE("imhere[2] (q=%p p=%p) tc = %08lx\n", wwo->lpQueuePtr, wwo->lpPlayPtr, GetTickCount()); had_msg = FALSE; - while (wodPlayer_RetrieveMessage(wwo, &msg, &param)) { + while (wodPlayer_RetrieveMessage(wwo, &msg, &param, &ev)) { had_msg = TRUE; switch (msg) { case WINE_WM_PAUSING: wodPlayer_Reset(wwo, uDevID, FALSE); wwo->state = WINE_WS_PAUSED; - SetEvent(wwo->hEvent); + SetEvent(ev); break; case WINE_WM_RESTARTING: wwo->state = WINE_WS_PLAYING; - SetEvent(wwo->hEvent); + SetEvent(ev); break; case WINE_WM_HEADER: lpWaveHdr = (LPWAVEHDR)param; @@ -711,14 +725,14 @@ break; case WINE_WM_RESETTING: wodPlayer_Reset(wwo, uDevID, TRUE); - SetEvent(wwo->hEvent); + SetEvent(ev); break; case WINE_WM_CLOSING: /* sanity check: this should not happen since the device must have been reset before */ if (wwo->lpQueuePtr || wwo->lpPlayPtr) ERR("out of sync\n"); wwo->hThread = 0; wwo->state = WINE_WS_CLOSED; - SetEvent(wwo->hEvent); + SetEvent(ev); ExitThread(0); /* shouldn't go here */ default: @@ -895,14 +909,15 @@ InitializeCriticalSection(&wwo->msg_crst); if (!(dwFlags & WAVE_DIRECTSOUND)) { - wwo->hEvent = CreateEventA(NULL, FALSE, FALSE, NULL); + wwo->hStartUpEvent = CreateEventA(NULL, FALSE, FALSE, NULL); wwo->hThread = CreateThread(NULL, 0, wodPlayer, (LPVOID)(DWORD)wDevID, 0, &(wwo->dwThreadID)); - WaitForSingleObject(wwo->hEvent, INFINITE); + WaitForSingleObject(wwo->hStartUpEvent, INFINITE); + CloseHandle(wwo->hStartUpEvent); } else { - wwo->hEvent = INVALID_HANDLE_VALUE; wwo->hThread = INVALID_HANDLE_VALUE; wwo->dwThreadID = 0; } + wwo->hStartUpEvent = INVALID_HANDLE_VALUE; TRACE("fd=%d fragmentSize=%ld\n", wwo->unixdev, wwo->dwFragmentSize); @@ -942,10 +957,8 @@ ret = WAVERR_STILLPLAYING; } else { TRACE("imhere[3-close]\n"); - if (wwo->hEvent != INVALID_HANDLE_VALUE) { - wodPlayer_Message(wwo, WINE_WM_CLOSING, 0); - WaitForSingleObject(wwo->hEvent, INFINITE); - CloseHandle(wwo->hEvent); + if (wwo->hThread != INVALID_HANDLE_VALUE) { + wodPlayer_Message(wwo, WINE_WM_CLOSING, 0, TRUE); } if (wwo->mapping) { munmap(wwo->mapping, wwo->maplen); @@ -988,7 +1001,7 @@ lpWaveHdr->lpNext = 0; TRACE("imhere[3-HEADER]\n"); - wodPlayer_Message(&WOutDev[wDevID], WINE_WM_HEADER, (DWORD)lpWaveHdr); + wodPlayer_Message(&WOutDev[wDevID], WINE_WM_HEADER, (DWORD)lpWaveHdr, FALSE); return MMSYSERR_NOERROR; } @@ -1047,8 +1060,7 @@ } TRACE("imhere[3-PAUSING]\n"); - wodPlayer_Message(&WOutDev[wDevID], WINE_WM_PAUSING, 0); - WaitForSingleObject(WOutDev[wDevID].hEvent, INFINITE); + wodPlayer_Message(&WOutDev[wDevID], WINE_WM_PAUSING, 0, TRUE); return MMSYSERR_NOERROR; } @@ -1067,8 +1079,7 @@ if (WOutDev[wDevID].state == WINE_WS_PAUSED) { TRACE("imhere[3-RESTARTING]\n"); - wodPlayer_Message(&WOutDev[wDevID], WINE_WM_RESTARTING, 0); - WaitForSingleObject(WOutDev[wDevID].hEvent, INFINITE); + wodPlayer_Message(&WOutDev[wDevID], WINE_WM_RESTARTING, 0, TRUE); } /* FIXME: is NotifyClient with WOM_DONE right ? (Comet Busters 1.3.3 needs this notification) */ @@ -1095,8 +1106,7 @@ } TRACE("imhere[3-RESET]\n"); - wodPlayer_Message(&WOutDev[wDevID], WINE_WM_RESETTING, 0); - WaitForSingleObject(WOutDev[wDevID].hEvent, INFINITE); + wodPlayer_Message(&WOutDev[wDevID], WINE_WM_RESETTING, 0, TRUE); return MMSYSERR_NOERROR; }

Nov. 1, 2001

mmsystem.c callback thread patch.

by Simon Britnell

The patch I wrote for mmsystem.c doesn't fix my problem with HomeWorld, so back to the drawing board on that one. The patch fixes a problem that I've only ever seen in HalfLife while I was messing with the innards of wodPlayer and assumes that wodPlayer_Notify can trigger a callback into the application. If that assumption is invalid, please ignore the patch and let me know so I can look into it further. Note that this also changes the semantics of the callbacks because wodPlayer is not halted waiting for the callback to complete, __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Nov. 1, 2001

Re: config.h reorg part 2: config.h includes

by François Gouget

François Gouget wrote: [...] > Changelog: > > François Gouget <fgouget(a)codeweavers.com> > > * console/xterm.c, [...] > windows/x11drv/clipboard.c > > Fix the #include order for config.h > Add #include "config.h" directives where needed > Fixes the FILE_OFFSET_BITS redefinition warnings on Solaris (part 2) There was a #include config.h missing in dlls/ddraw/mesa.c in the above patch. The attached patch fixes that. It complements part 2 (p20011031-config.diff) and must thus be applied before part 3 (p20011031-config2.diff) -- François Gouget fgouget(a)codeweavers.com Index: dlls/ddraw/mesa.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.3 diff -u -r1.3 mesa.c --- dlls/ddraw/mesa.c 2000/11/27 23:54:26 1.3 +++ dlls/ddraw/mesa.c 2001/11/01 07:51:07 @@ -3,6 +3,8 @@ This file contains all MESA common code */ +#include "config.h" + #include "windef.h" #include "wine/obj_base.h" #include "ddraw.h"

Nov. 1, 2001

Re: audio.c converted from WaitForSingleObject to poll

by Simon Britnell

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > well, from a pure semantic point of view, I think we > have to wait. I've shown (to myself) experimentally that just removing the waits breaks. What I've done instead is reversed my poll patch and added a patch to mmsystem.c which causes application (and possibly some non-application) callbacks to be called from a different thread so that wodPlayer_Notify doesn't ever halt waiting for the application to return (which may in turn be waiting on wodReset,wodRestart, wodClose, wodPause etc). I'll post this to wine-patches in just a moment. > for wodGetPosition, it currently returns the > position of > data which have been notified to the app (and which > has been actually played). > What's the exact issue on HL ? With the audio.c poll patch I posted, wodPlayer_Notify doesn't update the total bytes played until after sufficient time has elapsed for the dsp to have finished playing it. The absence of more data to send to the dsp may stop the polling loop before all sounds have been played, meaning that the total bytes for a the last sample written may not be updated until the next wave is queued to be written to the dsp. It appears that HL loops checking wodGetPosition until the last sound has been played before writing the next sound. This never happens with my poll patch because of the issue in the previous para. Hence: no sound. I verified this by doing another evil hack which just notified and updated total bytes as soon as they were written. The sound returned. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Nov. 1, 2001

Re: L"YES" is a NO NO!!!

by Francois Gouget

On Thu, 1 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > > Wine cannot use Unicode strings literals. When you write L"YES" this > > is a 32bit Unicode string, not a 16bit unicode string. This means that > > when you pass it to lstrcmpiW, which expects 16bit Unicode strings like > > all the APIs in Wine, what it sees is this: "Y\0E\0S\0\0\0". And this is > > obviously different from "YES". > > > > > > I guess it pays to check the warnings form time to time! > > Sure. Why not to change L'\0' to a simple 0 in your patch then? > > @@ -447,10 +451,10 @@ > switch (type) { > case REG_SZ: > data[9] = L'\0'; /* set end of string */ > ^^^^^^^^^^^^^^^ Because this is not so bad: L'\0' will give us a 32bit unicode character which is equivalent to an (unsigned)0. The C compiler will then automatically cast it into an (unsigned short), i.e. the WCHAR we wanted. No harm done. And no warning either. Besides a 0 or a '\0' is no more correct, it is still not a 16bit unicode character. It just goes through a slightly different (and shorter) series of automatic conversions. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Nov. 1, 2001