[ros-dev] Hook rewrite / regressions
jimtabor.rosdev at gmail.com
Sun Oct 31 01:51:01 UTC 2010
Yes that is right, I'm working on it!
CrystalCPUId has source available and which I'm now working with w2003
sdk mfc to see how mfc uses the SetWindowsHookEx WH_CBT and
WH_MSGFILTER as hooks with callbacks.
./appgray.cpp:37: pThreadState->m_hHookOldCbtFilter =
./thrdcore.cpp:262: pThreadState->m_hHookOldMsgFilter =
./wincore.cpp:637: pThreadState->m_hHookOldCbtFilter =
On Sat, Oct 30, 2010 at 12:23 PM, Olaf Siejka <caemyr at gmail.com> wrote:
> This commit did cause a range of regressions, with apps like KStudio, CPU-z
> and CrystalCPUId. Jim was informed about it and since then is working hard
> to get them back in order. For me and Johannes, at the present moment,
> KSStudio is of top priority, as its utterly vital for any advanced sound
> support works.
KSStudio uses MFC and the crash is related to one of two results of
the first passes (page full) of HCBT_CREATEWND call outs.
> 2010/10/30 Aleksey Bragin <aleksey at reactos.org>
>> we have a serious regression in trunk which started 23rd of October with
>> revision 49231 ("hook rewrite"). Considerable amount of time passed,
>> automatic testing is not possible thus I'm afraid we are accumulating bugs.
>> I think there is a need to revert 49231 + its dependencies in trunk to
>> allow automated testing to work again and also fix regressions caused by
>> this rewrite, and move this rewrite to a branch if possible.
>> In future, it would be a good idea to:
>> a. Discuss such serious rewrite merges beforehand (like Timo did with
>> b. Try not to merge all rewrites simulteneously.
>> E.g. I have to wait with heap rewrite merge (every rewrite contains a
>> certain amount of bugs, by definition) even though it's fully ready.
>> James - could you please share your opinion? The decision is yours, as you
>> are the author of that commit.
>> Aleksey Bragin.
There is a bug report 5670 related to the issue of DosBox, I posted
patches and test results for weeks! Which resulted in bug 5705. All
the tests I had access to passed! AbiWord, FF and OOo uses hooks. I
was even able to install on real hardware w/o any issues with boot
hangs as it persist with Qemu or the build test system! The boot hang
is due to a kernel issue with newer Qemu ( I noticed the degrade in
time when changes had been made to the kernel ) and does not have any
problems with 0.9.0. After adding the patch from bug 5681/5409, Qemu
0.9.0 works w/o issues. From this end, my tests passed and certify the
hook code as valid. I still have two more commits to do with
HCBT_CREATEWND in window.c ( of passing the original Name/Class
strings and MFC research ) and DosBox hook.c that allows WH_MOUSE_LL
to work as it should ( this one is ready ), now DosBox does not lag
when moving the mouse over its window or hangs in transition from
dosbox mouse to explorer mouse.
Before! Hooks never worked! It would not have made it through
callback.c! Even the set next call hook was wrong. So every developer
just turn them off or just moved them around in the code to hid it.
Event hooks ( which or new hook code is based on ) have minor issues
with message sequencing with hook calls, this is pointed out with
user32 wine msg tests, hook checks enabled and the rest commented out.
Like 3xx passed and 11 failures.
I figured out that this needed a desktop to check and monitor global
hooks and a pti to hold the minimal data ( also no TEB ) to help send
messages to other threads even as it had system message queue to work
from. I now marked these threads as "System Threads". Originally this
never worked (find first hook then next hook hid the call and the next
call had a null proc because it was a dead hook), now mouse_ll
messages are sent and the results are seen in hook_tests and debug
More information about the Ros-dev