RFC: implementation of driver functionality in msacm (RESEND)

[Alex Villací­s Lasso]

Eric Pouech wrote:

>> * Implementation of broadcasts to notification windows on driver 
>> add/remove, enabling/disabling, and priority changes
>
> - MSDN seems to state that differed notification is actually a 
> counter, not a simple boolean (whereas enable/disable is a boolean)

I have just read the MSDN web page, and I see no remark that suggests 
that deferred notification should behave as a counter instead of a 
simple on/off flag. Or maybe I am reading the page incorrectly...

>> * Fix for implementation quirks of acmDriverMessage() in order to 
>> allow native codecs to display configuration dialogs
>
> this seems rather hackish. did you actually tested this on Windows ? 
> Moreover, the size bits look especially suspicious. Where did you get 
> the 16 value from ?

I tested the native msacm32.dll from Windows 98 SE on Wine, and it 
reported a 16-byte struct size to the winemp3 codec. Since the goal was 
to allow native codecs no reason at all for not displaying the 
configuration dialog, I decided to use that size, even when the 
structure size in Wine is only 12 bytes.

>> * Working implementation of acmDriverPriority(), with support of 
>> delayed notification broadcasts (for one process only). Includes 
>> saving new priorities and enabled status to registry
>> * Loading of codec priorities and enabled status from registry
>> * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics()
>>
>> I must note that in order to provide support for acmDriverAddW() in 
>> ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an 
>> application-supplied module with an application-supplied driverProc 
>> as a full-blown winmm driver. Therefore, the patch includes a new 
>> procedure in winmm called wineAddDriver(), that instructs winmm to 
>> build a hDrvr from a supplied hModule/driverProc pair, rather than 
>> loading both from a DLL, as OpenDriver() does. This allows the rest 
>> of the code to continue using SendDriverMessage() as usual.
>
> this shouldn't be done that way, but rather by reimplementing 
> senddrivermessage in msacm32

That was the very thing I didn't want to do. So, while we are at it, 
should it be reimplemented for all codecs, or just the ones supplied by 
the application? Native msacm32 seems to relay to winmm for registered 
codecs, since I can see calls to SendDriverMessage().

Alex Villacís Lasso