Andrew,
it's good that you log these now. I had a question in mind since your winmm rewrite:
Your rewrite no more maps WOD_XYZ* messages to waveOut functions. I believe that it is possible that an old app entirely uses the generic SendDriverMessage function (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific wave/midi* ones. Can you be sure that this is not supported by native, esp. w9x?
If Wine does not map these, all we'll get to "hear" in AppDB is that attentive people miss sound or music that they remember listening to 10 years ago on native.
Regards, Jörg Höhle
On Wed, Feb 08, 2012 at 11:22:42AM +0100, Joerg-Cyril.Hoehle@t-systems.com wrote:
Your rewrite no more maps WOD_XYZ* messages to waveOut functions. I believe that it is possible that an old app entirely uses the generic SendDriverMessage function (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific wave/midi* ones. Can you be sure that this is not supported by native, esp. w9x?
Good question. All of the following is on my Win 7 VM. I tested both with no compatibility and with WinXP SP3 compatibility.
I tried using OpenDriver with "wave", "wavemapper", "wdmaud.drv", and "msacm32.drv" (last two found in Win 7 registry), all of which return NULL (ie, error). So I think SendDriverMessage() is unlikely to be interesting.
I wasn't able to get any useful results with WODM_* or WOD_* through waveOutMessage. Interestingly, WOD_OPEN returns NOTSUPPORTED, while WODM_OPEN crashes. I tried passing various combinations of WAVEOPENDESC, MMDRV_MESSAGE_PARAMS (not in the PSDK or Wine's include), and NULL to the function, but everything crashes. It's possible there's something useful there, but I can't figure out how to get at it.
Using the simpler case of WODM_GETNUMDEVS also failed in every case.
If Wine does not map these, all we'll get to "hear" in AppDB is that attentive people miss sound or music that they remember listening to 10 years ago on native.
Well, hopefully they would also file bugs :)
Andrew