Hey,
Op 16-03-11 15:52, joerg-cyril.hoe...@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
