[WINEOSS] use default prepare functions

Francois Gouget fgouget at free.fr
Fri Mar 18 07:00:16 CST 2005

On Fri, 18 Mar 2005, Robert Reif wrote:
>> Does that mean we could do the same wor winealsa, winearts, etc?
> Yes,  I am going to do winealsa next now that I have an alsa system.
> I haven't really looked at the others yet but will do them if someone
> doesn't beat me to it ;-)

Cool. I think I'll let you win<g>.

I have been thinking about how to share more more code between the 
drivers. My understanding is that we cannot modify the winmm-driver 
protocol because we have to conform to the standard Windows API, mostly 
so that winmm can be reused with as little modifications as possible by 
the ReactOS project.

Steven mentionned another route which would be to implement mmdrv and 
shift our drivers to hook to mmdrv instead of winmm (that's a very rough 
explanation but Steven will fill in the gaps if necessary). But again I 
believe the API is going to constrain us so I don't think we will be 
able to share more code.

So here's another idea (which may be stupid but I have to air it on the 
off chance it's not completely braindead).

The only thing that ReactOS or other projects can reuse is winmm, the 
sound drivers themselves (wineoss, winealsa, etc) are too Unix specific 
so that they will only work in Wine anyway. So a way to share code 
between the drivers would be to put it in another dll and then have 
these drivers link with it. But adding an extra dll is always annoying / 
ugly and I am assuming this is why it has not been done already.

So here's a variant on this theme: why no export Wine-only APIs from 
winmm and have the drivers call these.

  * For instance winmm could implement and export the 
wine_bytes_to_mmtime() function which given the proper parameters should 
be driver-independent so that we could remove its implementation from 
each driver.

  * The drivers already link to winmm so calling these Wine-only APIs 
would be no problem.

  * We could implement these APIs in a separate C file, wine.c, so that 
disabling them in other projects would simply be a matter of removing 
wine.c from the Makefile.

  * This introduces a dependency of the drivers on the Wine project but 
that's not a problem if they're not reusable anyway.

Now maybe I'm mis-evaluating the amount of code that could be shared 
beyond this wine_bytes_to_mmtime() function and this is not worth it. 
Does anyone have a more informed opinion on the matter?

Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
   Any sufficiently advanced Operating System is indistinguishable from Linux

More information about the wine-devel mailing list