Help: будет ли работать хук клавиатуры Win32 под Win64?

[@Vass]

С такими вопросами вам скорее на RSDN.ru там помогут., ибо там специализированный околовиндовый программерский форум.

[@Hint]

msdn.microsoft.com/en-us/library/ms644990(VS.85).aspx

SetWindowsHookEx can be used to inject a DLL into another process. A 32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL cannot be injected into a 32-bit process. If an application requires the use of hooks in other processes, it is required that a 32-bit application call SetWindowsHookEx to inject a 32-bit DLL into 32-bit processes, and a 64-bit application call SetWindowsHookEx to inject a 64-bit DLL into 64-bit processes. The 32-bit and 64-bit DLLs must have different names.

Оно?

[@Mercury13]

Я это видел. Столь же путано и туманно, как в другой доке Micorsoft. Что означает «can be»? В одних случаях вставляет DLL, в других нет? Тогда в каких случаях не вставляется и относится ли к этим случаям глобальный хук клавиатуры?

[@Paul]

Если у вас 32-битная дллка — она загрузится только в 32-битные процессы. Если 64-битная — только в 64-битные процессы. От версии винды зависит только то, сможете ли вы вообще запускать 64-битные процессы. Из решений я вижу только 2 дллки и 2 хукера, хотя может я чего-то не знаю.

[@Mercury13]

Ыгы. Но только в том случае, если dll «injected». Является ли глобальный хук клавиатуры таким случаем? По логике, не должен.

[@Paul]

Хуков клавиатуры есть 2 — обычный и лоу-левел. Глобально можно поставить оба. МСДН говорит, что лоу-левел хук (WH_KEYBOARD_LL) не внедряется в другие процессы, в момент срабатывания хука происходит переключение контекста и хук вызывается в контексте процесса-установщика. Так что вполне возможно, что этот хук будет работать со всеми процессами в не зависимости от битности дллки, в которой находится коллбек.

[@Gorthauer87]

Советую в свободное время таки занятся изучениями чего-то отличного от winAPI, тогда в один прекрасный день можно будет забыть о winAPI как о страшном сне. С развитием .NET'а он всё быстрее и быстрее летит в сторону deprecated. Не удивлюсь, если в Win8 winapi и вовсе будет эмулятором исполнятся

[@Mercury13]

Отлично вас понимаю. И есть желание. Сдам проект — займусь кое-чем другим.

Если прога нерезидентная — а особенно если большая — на все эти runtime-библиотеки начхать. Что мы на работе и делаем: одна копия VCL, пять копий VCL — не важно! Репу начинаем чесать только когда рабочая матрица начинает съедать всю память и надо что-то довычислять, а что-то — кэшировать.

Впрочем, и самые низкоуровневые системные штучки забывать не стоит. Кстати, по поводу .NET: такое будет только если всю оконную библиотеку вместе с диспетчером сообщений перепишут на NET! Скорее уж транзистор дойдёт до физического предела и на 256-ядерных процессорах потребуются совсем другие концепции программирования.

[@Gorthauer87]

>Отлично вас понимаю. И есть желание. Сдам проект — займусь кое-чем другим.
Ну для C++ программистов, которые GUI программируют, я обычно советую использовать Qt, так, как это самый логичный и простой фреймворк, который я только видел для С++, там точно нет никаких проблем со странными хуками, а программы возможно скомпилировать не тольно на x86, amd64, но и на arm, mips, IA-64. Короче говоря, для написания GUI приложений на С++ это одно из лучших решений.
>Впрочем, и самые низкоуровневые системные штучки забывать не стоит.
Самые низкоуровневые системные вызовы не используют winAPI, они пользуются nativeAPI, оно сильно отличается от winAPI, в нем нету такого сильного бремени обратной совместимости, поэтому зачастую старые драйвера не ставятся на новые системы. Это прежде всего системное(ядерное) API, а winAPI это прежде всего юзерспейс, причем, с точки зрения проектирования, весьма уродливый, в основном из за бремени обратной совместимости

[@Paul]

Qt хорошо конечно, но обычно, если нужны хуки — значит очень платформенно-специфическая задача и Qt не поможет. Попробуйте например написать на Qt Punto Switcher не пользуясь SetWindowsHookEx.

[@Gorthauer87]

Ну напрямую такие вещи в Qt коде лучше не юзать, лучше тогда такой платформозависимый код в отдельный класс вынести, а его реализация будет зависить ит платформы.

[@Paul]

я обычно советую использовать Qt, [...skipped...], там точно нет никаких проблем со странными хуками

Т.е. это я к тому писал, что Qt не панацея и без хуков бывает не обойтись.