winmm DriverCallback with 0 CALLBACK_WINDOW

[Joerg-Cyril.Hoehle at t-systems.com]

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?