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

Re: Using winebuild explicitly

by Dimitrie O. Paun

On January 5, 2004 05:40 pm, Ralf Juengling wrote: > Maybe, this assumption is simply wrong and gcc doesn't look up > dynamic libraries that way (at least its man page doesn't say so). > The reason that only I have this problem and noone else might be > due to my wine setup: I configured with "--prefix=/local" so the > libs cannot be found in any of the standard places (/usr/lib > or /usr/local/lib). Yes, this is the problem! For some reason I've read /local as /usr/local/lib, and I was confused why it wasn't working :) So, you have two options: 1. Specify -L/local/lib on the command line or 2. Just use std prefix (/usr/local/lib). -- Dimi.

Jan. 6, 2004

Re: winearts patch

by Jeremy Shaw

Hello, > (4d) Removed wodPlayer_DSPWait() > > I just calculate the wait value once in wodOpen() and store it in > wwo->dwSleepTime. > > Won't this value change as arts becomes filled with data or plays data out? No. The only function that calls wodPlayer_DSPWait() is the FeedDSP() -- and it only calls DSPWait() if availInQ == 0 (ie. the arts buffer is full and can't handle more data). Looking at the old calculation in DSPWait(), you will see that arts_stream_get() will always return 0 (since the buffer will always be full when DSPWait() is called). The rest of the terms will also remain the same every call since they are only changed it wodOpen(). Hence, it makes since to do the calculation in wodOpen() once and be done with it. int waitvalue = (wwo->dwBufferSize - arts_stream_get(wwo->play_stream, ARTS_P_BUFFER_SPACE)) / ((wwo->format.wf.nSamplesPerSec * wwo->format.wBitsPerSample * wwo->format.wf.nChannels) /1000); It you look at the waitvalue calculation further, you will start to wonder what it is trying to calculate anyway? If you do the calculation with units: f (bytes) = (wwo->dwBufferSize - arts_stream_get(wwo->play_stream,ARTS_P_BUFFER_SPACE)) s (samples/sec) = wwo->format.wf.nSamplesPerSecond n (bits/sample) = wwo->format.wf.wBitsPerSample c = wwo->format.wf.nChannels. waitvalue = f bytes / (( s (samples/sec) * n (bits/sample) * c ) * (1 sec / 1000 ms)) you get: waitvalue = ((1000 * f) / (s * n * c)) ((bytes * ms) / bits) notice that the units are (bytes * ms) / bits, not ms. It turns out that it is calculating the amount of time it will take to play 1/8 of the data in the buffer -- although I don't think this is what the intention was. I changed the sleep time to be the number of milliseconds to play one packet, times the number of packets you want to wait for before writing again: wwo->dwSleepTime = ((1 << (wwo->packetSettings & 0xFFFF)) * 1000 * BUFFER_REFILL_THRESHOLD) / wwo->format.wf.nAvgBytesPerSec; The way arts works, you are always going to see the amount of free space in the arts buffers as an integer multiple of the packet size. So I think it makes the most sense to for the sleep time to be some multiple of the amount of time it takes to play a single packet. As with the old calculation, the new calculation is only dependant on things that will not be changing while the stream is playing. So I think it is safe to calculation the sleep time in wodOpen() and store it in a structure rather than call DSPWait() all the time. > ARTS_P_PACKET_SETTINGS > Can you go over these changes a bit more? Maybe Tom can add some information > to the documentation based on what you have to say about the change. Internally arts uses packets to move the data around. When you call arts_writes(), you write to a single buffer, but internally, this is divided up into packets. Lets say that your buffer size is 16k. If arts divides this up into two 8k buffers, then you will only be able to write data in 8k chunks at a time. This can be problematic because you might spend two much time feeding the dsp instead of doing other important tasks. So instead you might prefer to have 16 packets that hold 1k each. Your overall buffer size is the same, but now you can feed the dsp is smaller chunks allowing your application to be more responsive. This is important if you are trying to achieve low-latency real-time operation (something arts is not that great at in the first place) -- which is exactly what is needed for something like the xten sipphone client. With the changes to the code, you can now not only change the buffer size, but also have finer grain control over how the buffer gets divided up. I should note that this control is limited to compile time, not runtime. I did a lot of experimentation, and I believe the current settings achieve the best balance/performance. Jeremy Shaw.

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Alexandre Julliard

<chmorgan(a)charter.net> writes: > Registering the dlls? Is this the same as loading them? No, it's running regsvr32 on them, which calls the DllRegisterServer entry point. > How would we know which dll was responsible for creating which > registry entries? Is it that clear which one should do it? Usually it's clear yes. > Would the code called during registration check to see if the > default keys existed and if it didn't install the default values? Normally it just sets the keys, no need to check anything. That code already exists in many cases, check the various regsvr.c files. > Would the inf file be mostly keys we've added for workarounds with > apps like installshield installers? Yes, it would be everyything that cannot be done by registering the dlls (which shouldn't be too much hopefully). -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2004

Re: Any experts on IsDialogMessage

by Dmitry Timoshkov

"Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > BTW can you tell me what incorrect behaviour you are aware of; I'll see if I > can fix it while I am working in this area. Attached is an one year old test app which gave very different results under win2k and Wine. I didn't run it for a while, but I don't think that something has changed in that area in Wine. -- Dmitry.

Jan. 6, 2004

Re: [Bug 1903] using dead_diaeresis i.e. e + ¨ hangs wine

by Vik

Hi, > XLib threading seems to just cause pain all over. Is this the same as > the XIM deadlock reported a few weeks ago? Just confirmed with cvs head. This indeed seems to be causing the deadlock on XIM as well. commented this line out and it looks a lot better. I was "carpet bombing" daily cvs builds up to december 1st. I guess I had 4 more days to go until I discovered what was causing this. ;-) Cheers Vik On Monday 05 January 2004 06:04, Mike Hearn wrote: > XLib threading seems to just cause pain all over. Is this the same as > the XIM deadlock reported a few weeks ago? > > On Sun, 2004-01-04 at 19:07, grant williamson wrote: > > Hi, > > not sure if anyone else has experienced this. > > since patch http://cvs.winehq.com/patch.py?id=10332 was added to cvs > > (20031205), if I type a dead_diaeresis - "(IB((B" followed by a letter, > > which would normally produce a "(IC+(B" or a "(IC<(B" it simply makes wine hang. > > > > removing this patch(I removed it on latest cvs) and the problem goes > > away, can someone find out why this causes an issue? -- ------------ Vikram Kumar vik(a)zone81.com

Jan. 6, 2004

Re: Windows dll replacement with Linux library

by Dan Timis

On Saturday, January 3, 2004, at 01:07 AM, Dimitrie O. Paun wrote: >> I'm new to this so please bear with me. >> >> First I edited the Makefile and replaced gcc with winegcc. When I run >> "make" I get this error when it tries to link: >> >> could not open .def file for kernel32 >> Error: /usr/bin/winebuild failed. >> Error: /usr/bin/winewrap failed. > > Can you please send me the command that generates this? Just to make > sure that we're on the same page, use winegcc (for now) just for > building > the test application, not the DLL. > >> Then, I ran ./configure --help and it says that you can use the "CC" >> var to specify the compiler. I started from scratch, set "export >> CC=winegcc", then ran configure again. The output looks like this: >> >> checking whether make sets {$MAKE}... yes >> checking for gcc... winegcc >> checking for C compiler default output... configure: error: C compiler >> cannot create executables > > This is very odd. winegcc should be configure friendly (it does work > for > wxWindows BTW). Hey, what version of Wine are you using? I do hope it's > the latest CVS... I am using an older version 20030618. It's hard to change, other people depend on this particular version and I would have to upgrade several machines. I could try on one machine, but... A colleague who dealt with similar problems in the past helped me. He added this to Makefile.in # generate a .def "import library" file from the spec file $(usbutils_dll_DEF): $(usbutils_dll_SPEC_SRCS) Makefile.in $(WINEBUILD) --def $(usbutils_dll_SPEC_SRCS) > $(usbutils_dll_DEF) Both the .dll.so and the .def go in /usr/lib/wine/wine. Earlier I noticed that there was no .def file. That was our clue. For the test we added the library to the list of wine dlls in Makefile.in. It's working. I'm still a little confused, but I understand much more than a week ago. Thanks. Dan Timis Muse Research, Inc.

Jan. 6, 2004

Re: winearts patch

by Chris Morgan

Just looking it over it seems fine. Eric Pouech is a better person to review something like this, he's had quite a bit more experence in this area. A couple of things: (4b) wodPlayer_FeedDSP() In the while loop, I could not figure out the purpose of 'availInQ > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the SPACE_THRESHOLD check could probably be left in, I am not sure what the purpose was in the first place. I think is to prevents us from feeding very small amounts of data. I'm not sure it is necessary for arts but I believe oss/alsa have issues with chunks of data below a certain size. Perhaps it improves performance if we aren't always trying to stuff a handful of bytes in. (4d) Removed wodPlayer_DSPWait() I just calculate the wait value once in wodOpen() and store it in wwo->dwSleepTime. Won't this value change as arts becomes filled with data or plays data out? ARTS_P_PACKET_SETTINGS Can you go over these changes a bit more? Maybe Tom can add some information to the documentation based on what you have to say about the change. Thanks, Chris

Jan. 6, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Kevin Koltzau

You can duplicate a pipe handle with DuplicateHandle, make it inheritable and share it between processes similar to many other handles On Sunday 04 January 2004 03:33 pm, Juan Lang wrote: > --- Alexandre Julliard <julliard(a)winehq.com> wrote: > > You have to do inter-process synchronization, pipe > > handles can be > > shared between processes. I don't see how you can do > > that without > > putting everything into the wine server, which is > > the same as putting > > it into the kernel except with a large performance > > hit (and not only > > for named pipes, but for all file I/O, since it will > > prevent many > > optimizations). But feel free to prove me wrong; I > > haven't studied the > > protocol in detail so maybe I'm missing something. > > I don't think pipe handles can be shared in the same > way as other handles. From MSDN's CreateFile > reference: > > "The opening process can duplicate the handle as many > times as required but, once opened, the named pipe > instance cannot be opened by another client. " > > I haven't experimented with handle duplication enough > to know what this really means, though, so I may be > all wet. We'll see.. > > --Juan > > __________________________________ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree

Jan. 6, 2004

winearts patch

by Jeremy Shaw

Hello, This message is largely for Chris Morgan's review, but I thought I should open it to any interested parties. I have added wave-in support for arts. I also fixed some bugs in the waveout code, and made some "improvements". This code seems to work really well for me. If no one sees any problems I will submit the patch to the patches mailing list. Here is a brief description of the changes I made: (1) In ARTS_CloseDevice() (now named ARTS_CloseWaveOutDevice()) and wodPlayer_NotifyWait() I added 'wwo->sound_buffer = 0' after the HeapFree(). Without it, HeapFree() was being called twice on the same buffer, and would crash the second time. (2) ARTS_AddRingMessage() Added the same fix I submitted earlier for wineoss in regards to ring buffer resizing. (3) wodPlayer_WriteMaxFrags() DWORD *bytes, points to the number of bytes the winearts driver thinks it should be able to write. However, arts sometimes lies, and says it has (for example) 512 bytes available, but when you call arts_write() it returns zero bytes written. In that case, I update *bytes to point to 0, otherwise wodPlayer_WriteMaxFrags() will keep being called in vain. (4a) wodPlayer_FeedDSP() The old code had the following checks: /* input queue empty and output buffer with no space */ if (!wwo->lpPlayPtr && availInQ) { TRACE("Run out of wavehdr:s... flushing\n"); wwo->dwPlayedTotal = wwo->dwWrittenTotal; return INFINITE; } if(!availInQ) { TRACE("no more room, no need to try to feed\n"); return wodPlayer_DSPWait(wwo); } I could not understand the purpose of the '&& availInQ' in the first check. It seems that if we are out of wavehdrs, then it does not matter if there is space in the availInQ or not, because we don't have anything to write. So I removed the && availInQ part. Looking at it now, I realize that maybe I need to add 'if (!availInQ)' before 'wwo->dwPlayedTotal = wwo->dwWrittenTotal'? (4b) wodPlayer_FeedDSP() In the while loop, I could not figure out the purpose of 'availInQ > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the SPACE_THRESHOLD check could probably be left in, I am not sure what the purpose was in the first place. (4c) wodPlayer_FeedDSP() the while loop in wodPlayer_FeedDSP() can terminate for two reasons: + availInQ == 0 + ran out of waveHdrs to write. In the first case, wodPlayer_FeedDSP() should return the number of milliseconds before the buffer needs more data (which it currently does). In the second case, it should return INFINTE, since it can't feed anymore data until it gets some more wave headers. I added a bit of code to handle the second case. Notice also, that DSPWait() will only be called when the availInQ == 0. This means that DSPWait() is always calculating the same value which leads us to 4d. (4d) Removed wodPlayer_DSPWait() I just calculate the wait value once in wodOpen() and store it in wwo->dwSleepTime. (5) wodOpen () In wodOpen I changed the code from setting the ARTS_P_BUFFER_SIZE, to setting the ARTS_P_PACKET_SETTINGS. This allows for finer control which I needed in order to achieve lower latency. The rest of the changes are for adding wave in support. Jeremy Shaw. --- orig/dlls/winmm/winearts/winearts.drv.spec +++ mod/dlls/winmm/winearts/winearts.drv.spec @@ -1,2 +1,3 @@ @ stdcall DriverProc(long long long long long) ARTS_DriverProc @ stdcall wodMessage(long long long long long) ARTS_wodMessage +@ stdcall widMessage(long long long long long) ARTS_widMessage --- orig/dlls/winmm/winearts/audio.c +++ mod/dlls/winmm/winearts/audio.c @@ -32,8 +32,7 @@ * FIXME: * pause in waveOut does not work correctly in loop mode * - * TODO: - * implement wave-in support with artsc + * does something need to be done in for WaveIn DirectSound? */ /*#define EMULATE_SB16*/ @@ -65,10 +64,32 @@ #include <artsc.h> -#define BUFFER_SIZE 16 * 1024 -#define SPACE_THRESHOLD 5 * 1024 +/* The following four #defines allow you to fine-tune the packet + * settings in arts for better low-latency support. You must also + * adjust the latency in the KDE arts control panel. I recommend 4 + * fragments, 1024 bytes. + * + * The following is from the ARTS documentation and explains what CCCC + * and SSSS mean: + * + * @li ARTS_P_PACKET_SETTINGS (rw) This is a way to configure packet + * size & packet count at the same time. The format is 0xCCCCSSSS, + * where 2^SSSS is the packet size, and CCCC is the packet count. Note + * that when writing this, you don't necessarily get the settings you + * requested. + */ +#define WAVEOUT_PACKET_CCCC 0x000C +#define WAVEOUT_PACKET_SSSS 0x0008 +#define WAVEIN_PACKET_CCCC 0x000C +#define WAVEIN_PACKET_SSSS 0x0008 + +#define BUFFER_REFILL_THRESHOLD 4 + +#define WAVEOUT_PACKET_SETTINGS ((WAVEOUT_PACKET_CCCC << 16) | (WAVEOUT_PACKET_SSSS)) +#define WAVEIN_PACKET_SETTINGS ((WAVEIN_PACKET_CCCC << 16) | (WAVEIN_PACKET_SSSS)) #define MAX_WAVEOUTDRV (10) +#define MAX_WAVEINDRV (10) /* state diagram for waveOut writing: * @@ -96,7 +117,7 @@ /* events to be send to device */ enum win_wm_message { WINE_WM_PAUSING = WM_USER + 1, WINE_WM_RESTARTING, WINE_WM_RESETTING, WINE_WM_HEADER, - WINE_WM_UPDATE, WINE_WM_BREAKLOOP, WINE_WM_CLOSING + WINE_WM_UPDATE, WINE_WM_BREAKLOOP, WINE_WM_CLOSING, WINE_WM_STARTING, WINE_WM_STOPPING }; typedef struct { @@ -126,9 +147,12 @@ PCMWAVEFORMAT format; WAVEOUTCAPSA caps; + DWORD dwSleepTime; /* Num of milliseconds to sleep between filling the dsp buffers */ + /* arts information */ arts_stream_t play_stream; /* the stream structure we get from arts when opening a stream for playing */ DWORD dwBufferSize; /* size of whole buffer in bytes */ + int packetSettings; char* sound_buffer; long buffer_size; @@ -154,7 +178,29 @@ ARTS_MSG_RING msgRing; } WINE_WAVEOUT; +typedef struct { + volatile int state; /* one of the WINE_WS_ manifest constants */ + WAVEOPENDESC waveDesc; + WORD wFlags; + PCMWAVEFORMAT format; + WAVEINCAPSA caps; + + /* arts information */ + arts_stream_t record_stream; /* the stream structure we get from arts when opening a stream for recording */ + int packetSettings; + + LPWAVEHDR lpQueuePtr; + DWORD dwRecordedTotal; + + /* synchronization stuff */ + HANDLE hStartUpEvent; + HANDLE hThread; + DWORD dwThreadID; + ARTS_MSG_RING msgRing; +} WINE_WAVEIN; + static WINE_WAVEOUT WOutDev [MAX_WAVEOUTDRV]; +static WINE_WAVEIN WInDev [MAX_WAVEINDRV]; static DWORD wodDsCreate(UINT wDevID, PIDSDRIVER* drv); static DWORD wodDsDesc(UINT wDevID, PDSDRIVERDESC desc); @@ -169,6 +215,8 @@ "WINE_WM_UPDATE", "WINE_WM_BREAKLOOP", "WINE_WM_CLOSING", + "WINE_WM_STARTING", + "WINE_WM_STOPPING", }; /*======================================================================* @@ -229,22 +277,35 @@ } /****************************************************************** - * ARTS_CloseDevice + * ARTS_CloseWaveOutDevice * */ -void ARTS_CloseDevice(WINE_WAVEOUT* wwo) +void ARTS_CloseWaveOutDevice(WINE_WAVEOUT* wwo) { arts_close_stream(wwo->play_stream); /* close the arts stream */ wwo->play_stream = (arts_stream_t*)-1; /* free up the buffer we use for volume and reset the size */ if(wwo->sound_buffer) + { HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + wwo->sound_buffer = 0; + } wwo->buffer_size = 0; } /****************************************************************** + * ARTS_CloseWaveInDevice + * + */ +void ARTS_CloseWaveInDevice(WINE_WAVEIN* wwi) +{ + arts_close_stream(wwi->record_stream); /* close the arts stream */ + wwi->record_stream = (arts_stream_t*)-1; +} + +/****************************************************************** * ARTS_Init */ static int ARTS_Init(void) @@ -264,7 +325,15 @@ { if(WOutDev[iDevice].play_stream != (arts_stream_t*)-1) { - ARTS_CloseDevice(&WOutDev[iDevice]); + ARTS_CloseWaveOutDevice(&WOutDev[iDevice]); + } + } + + for(iDevice = 0; iDevice < MAX_WAVEINDRV; iDevice++) + { + if(WInDev[iDevice].record_stream != (arts_stream_t*)-1) + { + ARTS_CloseWaveInDevice(&WInDev[iDevice]); } } @@ -331,7 +400,44 @@ WOutDev[i].caps.dwFormats |= WAVE_FORMAT_1S16; } + for (i = 0; i < MAX_WAVEINDRV; ++i) + { + WInDev[i].record_stream = (arts_stream_t*)-1; + memset(&WInDev[i].caps, 0, sizeof(WInDev[i].caps)); /* zero out + caps values */ + /* FIXME: some programs compare this string against the content of the registry + * for MM drivers. The names have to match in order for the program to work + * (e.g. MS win9x mplayer.exe) + */ +#ifdef EMULATE_SB16 + WInDev[i].caps.wMid = 0x0002; + WInDev[i].caps.wPid = 0x0104; + strcpy(WInDev[i].caps.szPname, "SB16 Wave In"); +#else + WInDev[i].caps.wMid = 0x00FF; + WInDev[i].caps.wPid = 0x0001; + strcpy(WInDev[i].caps.szPname,"CS4236/37/38"); +#endif + WInDev[i].caps.vDriverVersion = 0x0100; + WInDev[i].caps.dwFormats = 0x00000000; + + WInDev[i].caps.wChannels = 2; + + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4S16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_4M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_2S16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1M08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1S08; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1M16; + WInDev[i].caps.dwFormats |= WAVE_FORMAT_1S16; + WInDev[i].caps.wReserved1 = 0; + } return 0; } @@ -376,9 +482,22 @@ EnterCriticalSection(&mr->msg_crst); if ((mr->msg_toget == ((mr->msg_tosave + 1) % mr->ring_buffer_size))) { + int old_ring_buffer_size = mr->ring_buffer_size; mr->ring_buffer_size += ARTS_RING_BUFFER_INCREMENT; TRACE("mr->ring_buffer_size=%d\n",mr->ring_buffer_size); mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); + /* Now we need to rearrange the ring buffer so that the new + buffers just allocated are in between mr->msg_tosave and + mr->msg_toget. + */ + if (mr->msg_tosave < mr->msg_toget) + { + memmove(&(mr->messages[mr->msg_toget + ARTS_RING_BUFFER_INCREMENT]), + &(mr->messages[mr->msg_toget]), + sizeof(RING_MSG)*(old_ring_buffer_size - mr->msg_toget) + ); + mr->msg_toget += ARTS_RING_BUFFER_INCREMENT; + } } if (wait) { @@ -554,25 +673,6 @@ } /************************************************************************** - * wodPlayer_DSPWait [internal] - * Returns the number of milliseconds to wait for the DSP buffer to clear. - * This is based on the number of fragments we want to be clear before - * writing and the number of free fragments we already have. - */ -static DWORD wodPlayer_DSPWait(const WINE_WAVEOUT *wwo) -{ - int waitvalue = (wwo->dwBufferSize - arts_stream_get(wwo->play_stream, - ARTS_P_BUFFER_SPACE)) / ((wwo->format.wf.nSamplesPerSec * - wwo->format.wBitsPerSample * wwo->format.wf.nChannels) - /1000); - - TRACE("wait value of %d\n", waitvalue); - - /* return the time left to play the buffer */ - return waitvalue; -} - -/************************************************************************** * wodPlayer_NotifyWait [internal] * Returns the number of milliseconds to wait before attempting to notify * completion of the specified wavehdr. @@ -618,7 +718,10 @@ if(wwo->buffer_size < toWrite) { if(wwo->sound_buffer) - HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + { + HeapFree(GetProcessHeap(), 0, wwo->sound_buffer); + wwo->sound_buffer = 0; + } } /* if we don't have a buffer then get one */ @@ -664,7 +767,11 @@ TRACE("written = %d\n", written); - if (written <= 0) return written; /* if we wrote nothing just return */ + if (written <= 0) + { + *bytes = 0; /* apparently arts is actually full */ + return written; /* if we wrote nothing just return */ + } if (written >= dwLength) wodPlayer_PlayPtrNext(wwo); /* If we wrote all current wavehdr, skip to the next one */ @@ -690,6 +797,23 @@ { LPWAVEHDR lpWaveHdr; + if (wwo->lpQueuePtr) { + TRACE("lpWaveHdr=(%p), lpPlayPtr=(%p), lpLoopPtr=(%p), reserved=(%ld), dwWrittenTotal=(%ld), force=(%d)\n", + wwo->lpQueuePtr, + wwo->lpPlayPtr, + wwo->lpLoopPtr, + wwo->lpQueuePtr->reserved, + wwo->dwWrittenTotal, + force); + } else { + TRACE("lpWaveHdr=(%p), lpPlayPtr=(%p), lpLoopPtr=(%p), dwWrittenTotal=(%ld), force=(%d)\n", + wwo->lpQueuePtr, + wwo->lpPlayPtr, + wwo->lpLoopPtr, + wwo->dwWrittenTotal, + force); + } + /* Start from lpQueuePtr and keep notifying until: * - we hit an unwritten wavehdr * - we hit the beginning of a running loop @@ -699,7 +823,7 @@ (force || (lpWaveHdr != wwo->lpPlayPtr && lpWaveHdr != wwo->lpLoopPtr && - lpWaveHdr->reserved <= wwo->dwPlayedTotal))) { + lpWaveHdr->reserved <= wwo->dwWrittenTotal))) { wwo->lpQueuePtr = lpWaveHdr->lpNext; @@ -854,8 +978,8 @@ availInQ = arts_stream_get(wwo->play_stream, ARTS_P_BUFFER_SPACE); TRACE("availInQ = %ld\n", availInQ); - /* input queue empty and output buffer with no space */ - if (!wwo->lpPlayPtr && availInQ) { + /* input queue empty */ + if (!wwo->lpPlayPtr) { TRACE("Run out of wavehdr:s... flushing\n"); wwo->dwPlayedTotal = wwo->dwWrittenTotal; return INFINITE; @@ -865,7 +989,7 @@ if(!availInQ) { TRACE("no more room, no need to try to feed\n"); - return wodPlayer_DSPWait(wwo); + return wwo->dwSleepTime; } /* Feed from partial wavehdr */ @@ -878,16 +1002,26 @@ /* Feed wavehdrs until we run out of wavehdrs or DSP space */ if (!wwo->dwPartialOffset) { - while(wwo->lpPlayPtr && availInQ > SPACE_THRESHOLD) - { - TRACE("feeding waveheaders until we run out of space\n"); - /* note the value that dwPlayedTotal will return when this wave finishes playing */ - wwo->lpPlayPtr->reserved = wwo->dwWrittenTotal + wwo->lpPlayPtr->dwBufferLength; - wodPlayer_WriteMaxFrags(wwo, &availInQ); - } + while(wwo->lpPlayPtr && availInQ) + { + TRACE("feeding waveheaders until we run out of space\n"); + /* note the value that dwPlayedTotal will return when this wave finishes playing */ + wwo->lpPlayPtr->reserved = wwo->dwWrittenTotal + wwo->lpPlayPtr->dwBufferLength; + TRACE("reserved=(%ld) dwWrittenTotal=(%ld) dwBufferLength=(%ld)\n", + wwo->lpPlayPtr->reserved, + wwo->dwWrittenTotal, + wwo->lpPlayPtr->dwBufferLength + ); + wodPlayer_WriteMaxFrags(wwo, &availInQ); + } } - return wodPlayer_DSPWait(wwo); + if (!wwo->lpPlayPtr) { + TRACE("Ran out of wavehdrs\n"); + return INFINITE; + } + + return wwo->dwSleepTime; } @@ -1010,14 +1144,19 @@ if(!wwo->play_stream) return MMSYSERR_ALLOCATED; - /* Try to set buffer size from constant and store the value that it - was set to for future use */ - wwo->dwBufferSize = arts_stream_set(wwo->play_stream, - ARTS_P_BUFFER_SIZE, BUFFER_SIZE); - TRACE("Tried to set BUFFER_SIZE of %d, wwo->dwBufferSize is actually %ld\n", BUFFER_SIZE, wwo->dwBufferSize); + /* Try to set the packet settings from constant and store the value that it + was actually set to for future use */ + wwo->packetSettings = arts_stream_set(wwo->play_stream, ARTS_P_PACKET_SETTINGS, WAVEOUT_PACKET_SETTINGS); + TRACE("Tried to set ARTS_P_PACKET_SETTINGS to (%x), actually set to (%x)\n", WAVEOUT_PACKET_SETTINGS, wwo->packetSettings); + + wwo->dwBufferSize = arts_stream_get(wwo->play_stream, ARTS_P_BUFFER_SIZE); + TRACE("Buffer size is now (%ld)\n",wwo->dwBufferSize); + wwo->dwPlayedTotal = 0; wwo->dwWrittenTotal = 0; + wwo->dwSleepTime = ((1 << (wwo->packetSettings & 0xFFFF)) * 1000 * BUFFER_REFILL_THRESHOLD) / wwo->format.wf.nAvgBytesPerSec; + /* Initialize volume to full level */ wwo->volume_left = 100; wwo->volume_right = 100; @@ -1076,7 +1215,7 @@ ARTS_DestroyRingMessage(&wwo->msgRing); - ARTS_CloseDevice(wwo); /* close the stream and clean things up */ + ARTS_CloseWaveOutDevice(wwo); /* close the stream and clean things up */ ret = wodNotifyClient(wwo, WOM_CLOSE, 0L, 0L); } @@ -1399,6 +1538,499 @@ } /*======================================================================* + * Low level WAVE IN implementation * + *======================================================================*/ + +/************************************************************************** + * widGetNumDevs [internal] + */ +static DWORD widGetNumDevs(void) +{ + TRACE("%d \n",MAX_WAVEINDRV); + return MAX_WAVEINDRV; +} + +/************************************************************************** + * widNotifyClient [internal] + */ +static DWORD widNotifyClient(WINE_WAVEIN* wwi, WORD wMsg, DWORD dwParam1, DWORD dwParam2) +{ + TRACE("wMsg = 0x%04x dwParm1 = %04lX dwParam2 = %04lX\n", wMsg, dwParam1, dwParam2); + + switch (wMsg) { + case WIM_OPEN: + case WIM_CLOSE: + case WIM_DATA: + if (wwi->wFlags != DCB_NULL && + !DriverCallback(wwi->waveDesc.dwCallback, wwi->wFlags, + (HDRVR)wwi->waveDesc.hWave, wMsg, + wwi->waveDesc.dwInstance, dwParam1, dwParam2)) { + WARN("can't notify client !\n"); + return MMSYSERR_ERROR; + } + break; + default: + FIXME("Unknown callback message %u\n", wMsg); + return MMSYSERR_INVALPARAM; + } + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widGetDevCaps [internal] + */ +static DWORD widGetDevCaps(WORD wDevID, LPWAVEINCAPSA lpCaps, DWORD dwSize) +{ + TRACE("(%u, %p, %lu);\n", wDevID, lpCaps, dwSize); + + if (lpCaps == NULL) return MMSYSERR_NOTENABLED; + + if (wDevID >= MAX_WAVEINDRV) { + TRACE("MAX_WAVINDRV reached !\n"); + return MMSYSERR_BADDEVICEID; + } + + memcpy(lpCaps, &WInDev[wDevID].caps, min(dwSize, sizeof(*lpCaps))); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widRecorder [internal] + */ +static DWORD CALLBACK widRecorder(LPVOID pmt) +{ + WORD uDevID = (DWORD)pmt; + WINE_WAVEIN* wwi = (WINE_WAVEIN*)&WInDev[uDevID]; + WAVEHDR* lpWaveHdr; + DWORD dwSleepTime; + DWORD bytesRead; + int dwBufferSpace; + enum win_wm_message msg; + DWORD param; + HANDLE ev; + + SetEvent(wwi->hStartUpEvent); + + /* make sleep time to be # of ms to record one packet */ + dwSleepTime = ((1 << (wwi->packetSettings & 0xFFFF)) * 1000) / wwi->format.wf.nAvgBytesPerSec; + TRACE("sleeptime=%ld ms\n", dwSleepTime); + + for(;;) { + /* Oddly enough, dwBufferSpace is sometimes negative.... + * + * NOTE: If you remove this call to arts_stream_get() and + * remove the && (dwBufferSpace > 0) the code will still + * function correctly. I don't know which way is + * faster/better. + */ + dwBufferSpace = arts_stream_get(wwi->record_stream, ARTS_P_BUFFER_SPACE); + TRACE("wwi->lpQueuePtr=(%p), wwi->state=(%d), dwBufferSpace=(%d)\n",wwi->lpQueuePtr,wwi->state,dwBufferSpace); + + /* read all data is arts input buffer. */ + if ((wwi->lpQueuePtr != NULL) && (wwi->state == WINE_WS_PLAYING) && (dwBufferSpace > 0)) + { + lpWaveHdr = wwi->lpQueuePtr; + + TRACE("read as much as we can\n"); + while(wwi->lpQueuePtr) + { + TRACE("attempt to read %ld bytes\n",lpWaveHdr->dwBufferLength - lpWaveHdr->dwBytesRecorded); + bytesRead = arts_read(wwi->record_stream, + lpWaveHdr->lpData + lpWaveHdr->dwBytesRecorded, + lpWaveHdr->dwBufferLength - lpWaveHdr->dwBytesRecorded); + TRACE("bytesRead=%ld\n",bytesRead); + if (bytesRead==0) break; + + lpWaveHdr->dwBytesRecorded += bytesRead; + wwi->dwRecordedTotal += bytesRead; + + /* buffer full. notify client */ + if (lpWaveHdr->dwBytesRecorded >= lpWaveHdr->dwBufferLength) + { + /* must copy the value of next waveHdr, because we have no idea of what + * will be done with the content of lpWaveHdr in callback + */ + LPWAVEHDR lpNext = lpWaveHdr->lpNext; + + TRACE("waveHdr full.\n"); + + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + lpWaveHdr = wwi->lpQueuePtr = lpNext; + } + } + } + + /* wait for dwSleepTime or an event in thread's queue */ + WaitForSingleObject(wwi->msgRing.msg_event, dwSleepTime); + + while (ARTS_RetrieveRingMessage(&wwi->msgRing, &msg, &param, &ev)) + { + TRACE("msg=%s param=0x%lx\n",wodPlayerCmdString[msg - WM_USER - 1], param); + switch(msg) { + case WINE_WM_PAUSING: + wwi->state = WINE_WS_PAUSED; + + /* Put code here to "pause" arts recording + */ + + SetEvent(ev); + break; + case WINE_WM_STARTING: + wwi->state = WINE_WS_PLAYING; + + /* Put code here to "start" arts recording + */ + + SetEvent(ev); + break; + case WINE_WM_HEADER: + lpWaveHdr = (LPWAVEHDR)param; + /* insert buffer at end of queue */ + { + LPWAVEHDR* wh; + int num_headers = 0; + for (wh = &(wwi->lpQueuePtr); *wh; wh = &((*wh)->lpNext)) + { + num_headers++; + + } + *wh=lpWaveHdr; + } + break; + case WINE_WM_STOPPING: + if (wwi->state != WINE_WS_STOPPED) + { + + /* Put code here to "stop" arts recording + */ + + /* return current buffer to app */ + lpWaveHdr = wwi->lpQueuePtr; + if (lpWaveHdr) + { + LPWAVEHDR lpNext = lpWaveHdr->lpNext; + TRACE("stop %p %p\n", lpWaveHdr, lpWaveHdr->lpNext); + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + wwi->lpQueuePtr = lpNext; + } + } + wwi->state = WINE_WS_STOPPED; + SetEvent(ev); + break; + case WINE_WM_RESETTING: + wwi->state = WINE_WS_STOPPED; + wwi->dwRecordedTotal = 0; + + /* return all buffers to the app */ + for (lpWaveHdr = wwi->lpQueuePtr; lpWaveHdr; lpWaveHdr = lpWaveHdr->lpNext) { + TRACE("reset %p %p\n", lpWaveHdr, lpWaveHdr->lpNext); + lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; + lpWaveHdr->dwFlags |= WHDR_DONE; + + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); + } + wwi->lpQueuePtr = NULL; + SetEvent(ev); + break; + case WINE_WM_CLOSING: + wwi->hThread = 0; + wwi->state = WINE_WS_CLOSED; + SetEvent(ev); + ExitThread(0); + /* shouldn't go here */ + default: + FIXME("unknown message %d\n", msg); + break; + } + } + } + ExitThread(0); + /* just for not generating compilation warnings... should never be executed */ + return 0; +} + +/************************************************************************** + * widOpen [internal] + */ +static DWORD widOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags) +{ + WINE_WAVEIN* wwi; + + TRACE("(%u, %p %08lX);\n",wDevID, lpDesc, dwFlags); + if (lpDesc == NULL) { + WARN("Invalid Parametr (lpDesc == NULL)!\n"); + return MMSYSERR_INVALPARAM; + } + + if (wDevID >= MAX_WAVEINDRV) { + TRACE ("MAX_WAVEINDRV reached !\n"); + return MMSYSERR_BADDEVICEID; + } + + /* if this device is already open tell the app that it is allocated */ + if(WInDev[wDevID].record_stream != (arts_stream_t*)-1) + { + TRACE("device already allocated\n"); + return MMSYSERR_ALLOCATED; + } + + /* only PCM format is support so far... */ + if (lpDesc->lpFormat->wFormatTag != WAVE_FORMAT_PCM || + lpDesc->lpFormat->nChannels == 0 || + lpDesc->lpFormat->nSamplesPerSec == 0) { + WARN("Bad format: tag=%04X nChannels=%d nSamplesPerSec=%ld !\n", + lpDesc->lpFormat->wFormatTag, lpDesc->lpFormat->nChannels, + lpDesc->lpFormat->nSamplesPerSec); + return WAVERR_BADFORMAT; + } + + if (dwFlags & WAVE_FORMAT_QUERY) { + TRACE("Query format: tag=%04X nChannels=%d nSamplesPerSec=%ld !\n", + lpDesc->lpFormat->wFormatTag, lpDesc->lpFormat->nChannels, + lpDesc->lpFormat->nSamplesPerSec); + return MMSYSERR_NOERROR; + } + + wwi = &WInDev[wDevID]; + + /* direct sound not supported, ignore the flag */ + dwFlags &= ~WAVE_DIRECTSOUND; + + wwi->wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK); + + memcpy(&wwi->waveDesc, lpDesc, sizeof(WAVEOPENDESC)); + memcpy(&wwi->format, lpDesc->lpFormat, sizeof(PCMWAVEFORMAT)); + + if (wwi->format.wBitsPerSample == 0) { + WARN("Resetting zerod wBitsPerSample\n"); + wwi->format.wBitsPerSample = 8 * + (wwi->format.wf.nAvgBytesPerSec / + wwi->format.wf.nSamplesPerSec) / + wwi->format.wf.nChannels; + } + + wwi->record_stream = arts_record_stream(wwi->format.wf.nSamplesPerSec, + wwi->format.wBitsPerSample, + wwi->format.wf.nChannels, + "winearts"); + TRACE("(wwi->record_stream=%p)\n",wwi->record_stream); + wwi->state = WINE_WS_STOPPED; + + wwi->packetSettings = arts_stream_set(wwi->record_stream, ARTS_P_PACKET_SETTINGS, WAVEIN_PACKET_SETTINGS); + TRACE("Tried to set ARTS_P_PACKET_SETTINGS to (%x), actually set to (%x)\n", WAVEIN_PACKET_SETTINGS, wwi->packetSettings); + TRACE("Buffer size is now (%d)\n", arts_stream_get(wwi->record_stream, ARTS_P_BUFFER_SIZE)); + + if (wwi->lpQueuePtr) { + WARN("Should have an empty queue (%p)\n", wwi->lpQueuePtr); + wwi->lpQueuePtr = NULL; + } + arts_stream_set(wwi->record_stream, ARTS_P_BLOCKING, 0); /* disable blocking on this stream */ + + if(!wwi->record_stream) return MMSYSERR_ALLOCATED; + + wwi->dwRecordedTotal = 0; + wwi->wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK); + + ARTS_InitRingMessage(&wwi->msgRing); + + /* create recorder thread */ + if (!(dwFlags & WAVE_DIRECTSOUND)) { + wwi->hStartUpEvent = CreateEventA(NULL, FALSE, FALSE, NULL); + wwi->hThread = CreateThread(NULL, 0, widRecorder, (LPVOID)(DWORD)wDevID, 0, &(wwi->dwThreadID)); + WaitForSingleObject(wwi->hStartUpEvent, INFINITE); + CloseHandle(wwi->hStartUpEvent); + } else { + wwi->hThread = INVALID_HANDLE_VALUE; + wwi->dwThreadID = 0; + } + wwi->hStartUpEvent = INVALID_HANDLE_VALUE; + + TRACE("wBitsPerSample=%u, nAvgBytesPerSec=%lu, nSamplesPerSec=%lu, nChannels=%u nBlockAlign=%u!\n", + wwi->format.wBitsPerSample, wwi->format.wf.nAvgBytesPerSec, + wwi->format.wf.nSamplesPerSec, wwi->format.wf.nChannels, + wwi->format.wf.nBlockAlign); + return widNotifyClient(wwi, WIM_OPEN, 0L, 0L); +} + +/************************************************************************** + * widClose [internal] + */ +static DWORD widClose(WORD wDevID) +{ + WINE_WAVEIN* wwi; + + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't close !\n"); + return MMSYSERR_INVALHANDLE; + } + + wwi = &WInDev[wDevID]; + + if (wwi->lpQueuePtr != NULL) { + WARN("still buffers open !\n"); + return WAVERR_STILLPLAYING; + } + + ARTS_AddRingMessage(&wwi->msgRing, WINE_WM_CLOSING, 0, TRUE); + ARTS_CloseWaveInDevice(wwi); + wwi->state = WINE_WS_CLOSED; + ARTS_DestroyRingMessage(&wwi->msgRing); + return widNotifyClient(wwi, WIM_CLOSE, 0L, 0L); +} + +/************************************************************************** + * widAddBuffer [internal] + */ +static DWORD widAddBuffer(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't do it !\n"); + return MMSYSERR_INVALHANDLE; + } + if (!(lpWaveHdr->dwFlags & WHDR_PREPARED)) { + TRACE("never been prepared !\n"); + return WAVERR_UNPREPARED; + } + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) { + TRACE("header already in use !\n"); + return WAVERR_STILLPLAYING; + } + + lpWaveHdr->dwFlags |= WHDR_INQUEUE; + lpWaveHdr->dwFlags &= ~WHDR_DONE; + lpWaveHdr->dwBytesRecorded = 0; + lpWaveHdr->lpNext = NULL; + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_HEADER, (DWORD)lpWaveHdr, FALSE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widPrepare [internal] + */ +static DWORD widPrepare(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + + if (wDevID >= MAX_WAVEINDRV) return MMSYSERR_INVALHANDLE; + + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) + return WAVERR_STILLPLAYING; + + lpWaveHdr->dwFlags |= WHDR_PREPARED; + lpWaveHdr->dwFlags &= ~WHDR_DONE; + lpWaveHdr->dwBytesRecorded = 0; + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widUnprepare [internal] + */ +static DWORD widUnprepare(WORD wDevID, LPWAVEHDR lpWaveHdr, DWORD dwSize) +{ + TRACE("(%u, %p, %08lX);\n", wDevID, lpWaveHdr, dwSize); + if (wDevID >= MAX_WAVEINDRV) { + WARN("bad device ID !\n"); + return MMSYSERR_INVALHANDLE; + } + + if (lpWaveHdr->dwFlags & WHDR_INQUEUE) { + TRACE("Still playing...\n"); + return WAVERR_STILLPLAYING; + } + + lpWaveHdr->dwFlags &= ~WHDR_PREPARED; + lpWaveHdr->dwFlags |= WHDR_DONE; + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widStart [internal] + */ +static DWORD widStart(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't start recording !\n"); + return MMSYSERR_INVALHANDLE; + } + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_STARTING, 0, TRUE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widStop [internal] + */ +static DWORD widStop(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't stop !\n"); + return MMSYSERR_INVALHANDLE; + } + + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_STOPPING, 0, TRUE); + + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widReset [internal] + */ +static DWORD widReset(WORD wDevID) +{ + TRACE("(%u);\n", wDevID); + if (wDevID >= MAX_WAVEINDRV || WInDev[wDevID].state == WINE_WS_CLOSED) { + WARN("can't reset !\n"); + return MMSYSERR_INVALHANDLE; + } + ARTS_AddRingMessage(&WInDev[wDevID].msgRing, WINE_WM_RESETTING, 0, TRUE); + return MMSYSERR_NOERROR; +} + +/************************************************************************** + * widMessage (WINEARTS.6) + */ +DWORD WINAPI ARTS_widMessage(UINT wDevID, UINT wMsg, DWORD dwUser, + DWORD dwParam1, DWORD dwParam2) +{ + TRACE("(%u, %04X, %08lX, %08lX, %08lX);\n", + wDevID, wMsg, dwUser, dwParam1, dwParam2); + switch (wMsg) { + case DRVM_INIT: + case DRVM_EXIT: + case DRVM_ENABLE: + case DRVM_DISABLE: + /* FIXME: Pretend this is supported */ + return 0; + case WIDM_OPEN: return widOpen (wDevID, (LPWAVEOPENDESC)dwParam1, dwParam2); + case WIDM_CLOSE: return widClose (wDevID); + case WIDM_ADDBUFFER: return widAddBuffer (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_PREPARE: return widPrepare (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_UNPREPARE: return widUnprepare (wDevID, (LPWAVEHDR)dwParam1, dwParam2); + case WIDM_GETDEVCAPS: return widGetDevCaps (wDevID, (LPWAVEINCAPSA)dwParam1, dwParam2); + case WIDM_GETNUMDEVS: return widGetNumDevs (); + case WIDM_RESET: return widReset (wDevID); + case WIDM_START: return widStart (wDevID); + case WIDM_STOP: return widStop (wDevID); + default: + FIXME("unknown message %d!\n", wMsg); + } + return MMSYSERR_NOTSUPPORTED; +} + +/*======================================================================* * Low level DSOUND implementation * *======================================================================*/ static DWORD wodDsCreate(UINT wDevID, PIDSDRIVER* drv) @@ -1430,6 +2062,16 @@ * wodMessage (WINEARTS.@) */ DWORD WINAPI ARTS_wodMessage(WORD wDevID, WORD wMsg, DWORD dwUser, + DWORD dwParam1, DWORD dwParam2) +{ + FIXME("(%u, %04X, %08lX, %08lX, %08lX):stub\n", wDevID, wMsg, dwUser, dwParam1, dwParam2); + return MMSYSERR_NOTENABLED; +} + +/************************************************************************** + * widMessage (WINEARTS.6) + */ +DWORD WINAPI ARTS_widMessage(UINT wDevID, UINT wMsg, DWORD dwUser, DWORD dwParam1, DWORD dwParam2) { FIXME("(%u, %04X, %08lX, %08lX, %08lX):stub\n", wDevID, wMsg, dwUser, dwParam1, dwParam2);

Jan. 6, 2004

Re: Re: Using winebuild explicitly

by Ralf Juengling

On Mon, 2004-01-05 at 13:04, Dimitrie O. Paun wrote: > > There is at least one difference in using a wrapper & dll vs. > > using a single executable: The function GetModuleFileName > > doesn't yield the path to the program (the wrapper) with the > > wrapper-approach (there was some discussion on this in another > > recent thread). Thus, having such flag in winegcc would indeed > > be nice... > > Alexandre is working on a patch to completely remove the > need for such wrapper. Hopefully it will be committed soon > enough so we will not have to create such an option. Cool, that's good news. > > Did so. wineg++ invokes winewrap (without passing on the > > "-v" flag, though) which in turn generates same files > > and compiles them. > > Yes, it doesn't, but you can just copy the winewrap command, add the -v and invoke it manually. That's how I found out which step actually failed... > > The directory in which libwine.so.1 lives, is contained in my > > /etc/ld.so.conf. Are you saying this should be enough for gcc > > to find the library file? > > Right, that's how I thought it's supposed to work. > Did you rebuild the ld cache after updating /etc/ld.so.conf? Yes, I did. gcc -shared -Wl,-Bsymbolic,-z,defs -lwine -o phaeaco.exe.so /tmp/wwrpwsPFIV.spec.o /tmp/wwrpwsPFIV.o /usr/bin/ld: cannot find -lwine collect2: ld returned 1 exit status Error: gcc failed. [juenglin(a)alpspitze bongard]$ gcc --version gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Copyright (C) 2002 Free Software Foundation, Inc. Maybe, this assumption is simply wrong and gcc doesn't look up dynamic libraries that way (at least its man page doesn't say so). The reason that only I have this problem and noone else might be due to my wine setup: I configured with "--prefix=/local" so the libs cannot be found in any of the standard places (/usr/lib or /usr/local/lib). Ralf > > -- > Dimi.

Jan. 5, 2004

#5 - Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Steven Edwards

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > > I am calling this patch pre5 rather than #5 because it doesnt fully > > address the rest of the PSDK porting issues and one of my new years > > resolutions for 2004 is for every patch I send to winehq to be good > > enough to go right in to CVS. ;) > > That's certainly won't happen if you don't attach the patch <g> Hehe your right. Its a good thing it was called pre5. After this one there are still a few minor things with one of the source files calling Heap_StrsupWtoA that needs to be moved inline and the NONAMELESS stuff. I have not done any work to address the NONAMELESSSTRUCT stuff except to just remove all cases of s1.u1 in ReactOS sources I ported. None of my patches to wine-patches reflect this change. If this is accepted I will send a patch in a few days to remove printdlg.h and to move a strdupW2A function inline in the offending source file. Once these changes are done and the NONAMELESS stuff is solved then comdlg32 will be mostly done of all Win16/32, PSDK and Wineism cleanups. I think there is a function or two left that I need to check the declairations of like I have been with NetAPI32 and Setupapi. Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 5, 2004

Re: install default config files to $PREFIX/share/wine

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > But how will we get rid of the drive config? We will need a tool (maybe wineboot) to setup the initial drive config according to the machine setup. A default config file is not going to help with that anyway. -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2004

Re: Re: install default config files to $PREFIX/share/wine

by chmorgan＠charter.net

Registering the dlls? Is this the same as loading them? How would we know which dll was responsible for creating which registry entries? Is it that clear which one should do it? Would the code called during registration check to see if the default keys existed and if it didn't install the default values? Would the inf file be mostly keys we've added for workarounds with apps like installshield installers? I'm asking because I'd really like to have wine create its own default config to simplify the users life and wineinstall, and I'd also like to simplify package managers lives so they don't need to many special scripts. I'm also interested in integrating the ~/.wine/config file into the registry. So feel free to suggest places to look, work and what direction to head. Chris > > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 2004/01/05 Mon PM 04:46:59 EST > To: cmorgan(a)alum.WPI.EDU > CC: <wine-devel(a)winehq.com> > Subject: Re: install default config files to $PREFIX/share/wine > > <chmorgan(a)charter.net> writes: > > > How do we plan to get rid of having default config files? Where would the default registry go? > > It will be created on the fly by registering the various dlls and > creating the remaining needed keys, most likely through a setupapi > .inf script. > > -- > Alexandre Julliard > julliard(a)winehq.com > >

Jan. 5, 2004

Re: install default config files to $PREFIX/share/wine

by Marcus Meissner

On Mon, Jan 05, 2004 at 01:46:59PM -0800, Alexandre Julliard wrote: > <chmorgan(a)charter.net> writes: > > > How do we plan to get rid of having default config files? Where would the default registry go? > > It will be created on the fly by registering the various dlls and > creating the remaining needed keys, most likely through a setupapi > .inf script. But how will we get rid of the drive config? Ciao, Marcus

Jan. 5, 2004

Re: install default config files to $PREFIX/share/wine

by Alexandre Julliard

<chmorgan(a)charter.net> writes: > How do we plan to get rid of having default config files? Where would the default registry go? It will be created on the fly by registering the various dlls and creating the remaining needed keys, most likely through a setupapi .inf script. -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2004

Re: Re: install default config files to $PREFIX/share/wine

by chmorgan＠charter.net

How do we plan to get rid of having default config files? Where would the default registry go? Chris > > From: Alexandre Julliard <julliard(a)winehq.org> > Date: 2004/01/05 Mon PM 03:19:54 EST > To: Chris Morgan <cmorgan(a)alum.wpi.edu> > CC: wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > Chris Morgan <cmorgan(a)alum.wpi.edu> writes: > > > * configure.ac, Makefile.in, documentation/Makefile.in, documentation/samples/ > > Makefile.in > > Chris Morgan <cmorgan(a)alum.wpi.edu> > > Install default wine configuration files to $PREFIX/share/wine for use by > > packages and by future changes to create a default configuration if none is > > present. > > I don't think we want that. Future changes are supposed to get rid of > the need for a config file, so we don't want to give the impression > that external apps can depend on finding a sample config file. > > -- > Alexandre Julliard > julliard(a)winehq.com > > >

Jan. 5, 2004

Is there already a function for this?

by Bill Medland

Does anyone know if we already have a function that measures the true length of a window's text in the following way l = SendMessage (hwnd, WM_GETTEXTLENGTH,..) presumably allocate a buffer SendMessage (hwnd, WM_GETTEXT, 2(l+1)..) Then actually measure the retrieved text. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Jan. 5, 2004

Re: Re: Using winebuild explicitly

by Dimitrie O. Paun

> There is at least one difference in using a wrapper & dll vs. > using a single executable: The function GetModuleFileName > doesn't yield the path to the program (the wrapper) with the > wrapper-approach (there was some discussion on this in another > recent thread). Thus, having such flag in winegcc would indeed > be nice... Alexandre is working on a patch to completely remove the need for such wrapper. Hopefully it will be committed soon enough so we will not have to create such an option. > Did so. wineg++ invokes winewrap (without passing on the > "-v" flag, though) which in turn generates same files > and compiles them. Yes, it doesn't, but you can just copy the winewrap command, add the -v and invoke it manually. > The directory in which libwine.so.1 lives, is contained in my > /etc/ld.so.conf. Are you saying this should be enough for gcc > to find the library file? Right, that's how I thought it's supposed to work. Did you rebuild the ld cache after updating /etc/ld.so.conf? -- Dimi.

Jan. 5, 2004

Re: Using winebuild explicitly

by Ralf Juengling

On Sat, 2004-01-03 at 01:03, Dimitrie O. Paun wrote: > > This should not be necessary with the code in question and > > I would rather like to build just one executable. So I wrote > > a Makefile that does this (not using winegcc & co) by > > calling winebuild explicitly (see below). > > Unfortunately, by doing that we don't learn anything useful > for Wine :) There is absolutely no reason why duplicating the > steps that winegcc takes in your Makefile should make any > difference. > > Speaking of this wrapper script, we should have a flag in winegcc > that disables it. But again, having it should make no difference There is at least one difference in using a wrapper & dll vs. using a single executable: The function GetModuleFileName doesn't yield the path to the program (the wrapper) with the wrapper-approach (there was some discussion on this in another recent thread). Thus, having such flag in winegcc would indeed be nice... > whatsoever. Can you (pretty) please go back to the winegcc stuff, > and run the linking step with the -v option, and send me the > output? Did so. wineg++ invokes winewrap (without passing on the "-v" flag, though) which in turn generates same files and compiles them. The error eventually occurs in linking the wrapper executable: gcc -shared -Wl,-Bsymbolic,-z,defs -lwine -o phaeaco.exe.so /tmp/wwrpLuPoqb.spec.o /tmp/wwrpLuPoqb.o /usr/bin/ld: cannot find -lwine collect2: ld returned 1 exit status Error: gcc failed. > > The Makefile is as follows: > > LIBS = -lwine -lm > > You see, you link against -lwine as well, why would this fail > through winegcc? I'm guessing there's something funny in your > ld setup... The directory in which libwine.so.1 lives, is contained in my /etc/ld.so.conf. Are you saying this should be enough for gcc to find the library file? In the other Makefile (the one where I invoke winebuild explicitly), the path is passed (as an -L option) to winebuild and g++ (c.f. variable LDFLAGS). Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

Jan. 5, 2004

Re: install default config files to $PREFIX/share/wine

by Alexandre Julliard

Chris Morgan <cmorgan(a)alum.wpi.edu> writes: > * configure.ac, Makefile.in, documentation/Makefile.in, documentation/samples/ > Makefile.in > Chris Morgan <cmorgan(a)alum.wpi.edu> > Install default wine configuration files to $PREFIX/share/wine for use by > packages and by future changes to create a default configuration if none is > present. I don't think we want that. Future changes are supposed to get rid of the need for a config file, so we don't want to give the impression that external apps can depend on finding a sample config file. -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2004

Re: install default config files to $PREFIX/share/wine

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > Some simple fix for C++ with the macro FONTSIZE > So ATL and MFC can compile. Why do you need that? It's not in the SDK header AFAICS. -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2004

Re: How can I run a program compiled with winelib when wine has b een uninstalled.

by Mike Hearn

On Mon, 05 Jan 2004 09:57:34 -0800, Steven Edwards wrote: > Right but...There are going to be problems with this untill WINE 1.0. > If the WINE server protocall or API changes the app will break. For the > time being the only solution would be to ship WINE with the app. Once > we have a 1.0 release of winelib this wont be a issue for any > applications linked to 1.x Why? WineLib apps don't RPC to the wineserver directly, they go via the win32 API which is stable. If the wineserver protocol changes, that's hidden behind the dlls right?

Jan. 5, 2004

Re: How can I run a program compiled with winelib when wine has b een uninstalled.

by Steven Edwards

Hi Dimi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > This is not a problem: your app has lots of dependencies anyway, > wine will just be one of them. Gnome apps require the Gnome libs, > they don't package those with each app, do they? :) Right but...There are going to be problems with this untill WINE 1.0. If the WINE server protocall or API changes the app will break. For the time being the only solution would be to ship WINE with the app. Once we have a 1.0 release of winelib this wont be a issue for any applications linked to 1.x Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 5, 2004

Re: Any experts on IsDialogMessage

by Bill Medland

On January 2, 2004 09:56 pm, Dmitry Timoshkov wrote: > "Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > > I am just about to start concentrating on IsDialogMessage, especially in > > the non-dialog context. Our program (suite) uses ActiveX controls > > extensively and is difficult to use because the TAB handling in > > particular is totally wrong. > > Probably what really makes Tab handling wrong is a not correct behaviour > of GetNextDlgTabItem and GetNextDlgGroupItem. I was intending to fix them > at some point, but it seems I have no time to work on them and won't have > it in the near future. BTW can you tell me what incorrect behaviour you are aware of; I'll see if I can fix it while I am working in this area. > > It would be great to have a test suite for that APIs as well. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 5, 2004

Re: How can I run a program compiled with winelib when wine has b een uninstalled.

by Dimitrie O. Paun

On January 5, 2004 11:32 am, Brian Vincent (C) wrote: > Which brings up a good point, is there an easy way to distribute > one? What comes to mind would be some way to adapt the Wine binary > distributions (RPM's, .tgz's) to also install an application at > the same time. This is not a problem: your app has lots of dependencies anyway, wine will just be one of them. Gnome apps require the Gnome libs, they don't package those with each app, do they? :) -- Dimi.

Jan. 5, 2004