Ну не в этом суть. И так, и так будет тормозить.

Но тормозит не только в отладчике, тормозит и не в отладчике, если мое информационное окно консоли активно. Тормозит на вышеописанных местах.

Это точно какая-то проблема реализации.
А если отключить хук в коде, но запускать перед эмулятором хук-тест - тогда какие симптомы ?

Тогда все работает идеально.
Однако, вся инициализация и обработчик хука в эмуляторе - предельно просты и приведены выше.

А если запустить хук-тест после запуска эмулятора, а потом переключиться в эмулятор ?

Можно сделать два захода - когда эмулятор оставлен в окне эмуляции, а после запуска хук-теста переключается в окно консоли, и наоборот - оставлен в окне консоли, а потом переключается в окно эмуляции.

Все работает, хоть до, хоть после. Пробовал.

Можно сделать так, чтобы окно эмуляции устанавливало хук только при получении фокуса, а при потере фокуса - убирало хук..

Но лучше - сделать в эмуляторе ещё одно пустое окно, переключение в которое происходило бы без тормозов - и добавлять туда код реализации консоли, пока тормоза не проявятся.

Хочу для эксперимента сделать в библиотеке.

Есть пример пустой библиотеки? А то VisualC по умолчанию пихает туда какой-то фигни, из-за чего размер 160кб. Причем, фиг отключишь в настройках линкера. Не получилось пока что.

В приложении - статически собранная DLL ( с проектом ), которая при загрузке устанавливает хук и начинает писать лог в файл GlobalHook.log, а при выгрузке - убирает хук и закрывает лог.

Хук будет работать только тогда, когда загрузившая эту DLL программа обрабатывает сообщения.

Так в теории. На практике мне эту DLL грузить нечем, а писать в отдельном проекте ещё и специальный загрузчик - лень.

...

Эм... а 86кб почему?)

Сборка статическая - код реализации всех использованных в исходнике DLL вызовов прилинкован к "телу" DLL.