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
