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+
--
Eric Pouech
