Jan. 10, 2006
8:15 p.m.
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+ -- Eric Pouech