Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

[Eric Pouech]

I do think all the recent changes to winecfg are going into the wrong 
direction.

First of all, allowing the devices to be opened more than once without 
having the devices ready for that is a ready bad idea. Basically, 
windows drivers come in two flavors:
- single instance (they can be loaded only once in memory)
- multiple instance (they can be loaded several times in memory)
For the second type, a specific init string (gotten from the registry, 
and usually dealing with the HZ resources involved) is passed to the driver.
In the wine implementation, we don't get anything from the registry, we 
just let the device (from the unix interface it uses) return as many 
audio/midi... ports it finds. This is typically the behavior expected 
from single instance drivers. Among the issues we'll face here are dual 
open of the same unix resource (contention) for several instances, 
overwriting of internal data and structures (they are not prepared for 
that).
Therefore, the multiple open patch has to be reverted.

Secondly, I do think it's a bad idea to reconstruct in winecfg most the 
driver management. It's not done correctly (the DRV_INIT, DRV_ENABLE and 
DRV_LOAD messages are not correctly passed). If it works today, it's by 
chance as the configure message is never handled (we just put out a 
message box), but it doesn't access the internal structures. To do it, 
we need the DRV_ messages sent.

Finally, I'm not sure that presenting all the drivers, and the ports 
available is really meaningful for most users. Some drivers return just 
potential entries (esound for example). Even with the caps, most users 
won't tell the difference between alsa and oss entries.

Lately, the available drivers button is not really useful. We shouldn't 
present non available drivers to the users, and just let him/her choose 
among the available ones (or just to mark the ones which are not available).

-- 
Eric Pouech