Re: winmm DriverCallback with 0 CALLBACK_WINDOW

[Maarten Lankhorst]

Hey,

Op 16-03-11 15:52, [e-mail] 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