On 07/25/2011 12:33 PM, Alexandre Julliard wrote:
Andrew Eikumaeikum@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