winmm DriverCallback with 0 CALLBACK_WINDOW
m.b.lankhorst at gmail.com
Wed Mar 16 14:01:46 CDT 2011
Op 16-03-11 15:52, Joerg-Cyril.Hoehle at t-systems.com schreef:
> 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.
More information about the wine-devel