Alex Villacís Lasso wrote:
(resent because previous attempt never appeared in wine-devel)
This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features.
Even for review it's easier by small chunks...
The following is the list of features added by the patch:
- Implementation of acmDriverAddW(), and delegation of acmDriverAddA()
to acmDriverAddW()
- you shouldn't compute the length of the necessary unicode buffer with strlen * sizeof(WCHAR). See rest of the code for good example - when you free lParamW, lParamW can be another non null value (a window handle for example) and you shouldn't free it
- Working implementation of modes of operation of acmDriverAdd[AW]: add
driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND)
- I wonder if we should really (internally) register the nofication windows the same ways as the other drivers... this is only used for notification (one way). I'd rather use a separate internal type
- 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)
- 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 ?
- 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
A+