On 07/25/2011 12:33 PM, Alexandre Julliard wrote:
Andrew Eikum<aei...@codeweavers.com> writes:
On 07/25/2011 09:09 AM, Alexandre Julliard wrote:
It's not the driver's business to check the configuration key. If
there's really a need to know if some other driver was configured, this
info should be passed from the driver loader. But it would be preferable
to avoid that.
I see your point. The idea was to give the user an override, in case
the OSS detection isn't smart enough and refuses to load a legitimate
implementation. If the user explicitly tells us to use OSS, then I
think the heuristics in DllMain should be ignored; nothing in there is
"critical" to our OSS driver.
MMDevAPI could pass some "explicit" flag to the driver, but DllMain
doesn't take arguments (right?). It looks like we'd have to put the
explicit flag into GetEndpointIDs and change MMDevAPI to check that
function during driver load time, or create a new Initialize() entry
point.
Do you prefer either of those options? Should I just go back to the
drawing board on the whole idea?
I guess we could have some sort of priority mechanism, where the driver
can returns its priority, and the loader tries them all and keeps the
highest one.
Mm, don't see much of a difference between this and an ordered list in
the code like we are using now. This also doesn't solve the original
problem of a broken OSS continuing to fail to load even if the user
explicitly requests OSS in the registry.
We also probably need a way to have only mmdevapi handle loading so that
winmm doesn't need to duplicate the search strategy. Though the mmdevapi
side will need to be fixed to support the correct registry syntax.
Yes, that would be nice. What do you mean "correct registry syntax"? Do
you mean listing multiple drivers? I don't see any reason to support that.
Andrew
