[PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS

[Andrew Eikum]

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