[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