We never "load" a driver more than once. Winecfg calls winmm OpenDriver which will only ever load a single instance of the driver into memory. Subsequent OpenDriver calls will reference the existing in memory driver. Wine models the single instance device driver that supports multiple physical devices.
what you end up with is a situation where: - two calls to OpenDriver for the same driver will provide: + a separate HDRVR (one for each call) + the same driver ID at the driver level + an implementation at the driver level with a single data state shared across the two HDRVR instance - most of the drivers are not prepared for that. As a simple example: h1 = OpenDriver("a.drv", ...); h2 = OpenDriver("a.drv", ...); // h1 <> h2, but driver ids are the same // start a play back on one of media stream of a.drv with h1 CloseDriver(h2, 0, 0); // playback will stop, and all data of h1 have been cleared // by closing h2 !
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.
It is true that winecfg is not calling each sub system driver (WaveIn, WaveOut, ...) like windows but device probing is done at main driver load in most drivers (and I am fixing the ones that don't) because device configuration is dynamic rather than read from the registry so opening the sub drivers individually to query static data is not a problem. I have a version of the alsa driver that can change registry entries from the configure dialog.
yes, but it implies that all drivers configured by winecfg must be single instance drivers.
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.
Jack and esound are fundamentally flawed because they create 10 virtual sound cards that all reference a single physical device. This doesn't take into account multiple devices. The proper way to implement this is to allow multiple opens of the same device (just like windows). That way two or more programs can open one card and other programs can open another card and none of the programs are aware or even care about the others. I have multiple sound cards and headsets in a single computer for music and VoIP and I need a way for individual programs to work with specific devices (just like in windows).
we do agree here that jack & esound (like any interface with integrated audio mixer) should be multiple instance drivers and not single instance ones.
[snip]
Hiding stuff in the registry without giving the user an easy way (GUI rather than reading the source and using regedit) of configuring the sound system is not good.
that's not what I'm asking for. I request having even for winecfg driver loading/unloading to be handled through winmm, and not by winecfg itself, which forces you in lots of unneeded kludges.
The direction I am trying to take the winecfg it to allow specific driver configuration through the windows DRV_CONFIGURE mechanism which displays a driver specific dialog box for changing driver specific registry entries. This is the only time there is potential contention problems between programs but only if configuration is performed immediately while the other programs are accessing the driver.
that's not true see above
A+