Hi,
Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case.
(As a consequence, Wine's player thread will send notification messages to itself ...)
Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback.
Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed.
Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly?
Any ideas? Jörg Höhle
BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only?