winmm DriverCallback with 0 CALLBACK_WINDOW

[Maarten Lankhorst]

Hey,

Op 16-03-11 15:52, Joerg-Cyril.Hoehle at t-systems.com schreef:
> 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 ...)
Considering PostThreadMessage(NULL) is supposed to post to the thread 
queue this is fine, feel free to fix though.

> 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?
In that case I wouldn't worry about it, just handle it in DriverCallback 
to save on duplication.

> 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?
I honestly can't remember. Probably because I only checked with 
sndvol32, feel free to send in a patch for it though.

Cheers,
Maarten