Comments 12
С такими вопросами вам скорее на RSDN.ru там помогут., ибо там специализированный околовиндовый программерский форум.
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.
Оно?
Я это видел. Столь же путано и туманно, как в другой доке Micorsoft. Что означает «can be»? В одних случаях вставляет DLL, в других нет? Тогда в каких случаях не вставляется и относится ли к этим случаям глобальный хук клавиатуры?
Если у вас 32-битная дллка — она загрузится только в 32-битные процессы. Если 64-битная — только в 64-битные процессы. От версии винды зависит только то, сможете ли вы вообще запускать 64-битные процессы. Из решений я вижу только 2 дллки и 2 хукера, хотя может я чего-то не знаю.
Ыгы. Но только в том случае, если dll «injected». Является ли глобальный хук клавиатуры таким случаем? По логике, не должен.
Хуков клавиатуры есть 2 — обычный и лоу-левел. Глобально можно поставить оба. МСДН говорит, что лоу-левел хук (WH_KEYBOARD_LL) не внедряется в другие процессы, в момент срабатывания хука происходит переключение контекста и хук вызывается в контексте процесса-установщика. Так что вполне возможно, что этот хук будет работать со всеми процессами в не зависимости от битности дллки, в которой находится коллбек.
Советую в свободное время таки занятся изучениями чего-то отличного от winAPI, тогда в один прекрасный день можно будет забыть о winAPI как о страшном сне. С развитием .NET'а он всё быстрее и быстрее летит в сторону deprecated. Не удивлюсь, если в Win8 winapi и вовсе будет эмулятором исполнятся
Отлично вас понимаю. И есть желание. Сдам проект — займусь кое-чем другим.
Если прога нерезидентная — а особенно если большая — на все эти runtime-библиотеки начхать. Что мы на работе и делаем: одна копия VCL, пять копий VCL — не важно! Репу начинаем чесать только когда рабочая матрица начинает съедать всю память и надо что-то довычислять, а что-то — кэшировать.
Впрочем, и самые низкоуровневые системные штучки забывать не стоит. Кстати, по поводу .NET: такое будет только если всю оконную библиотеку вместе с диспетчером сообщений перепишут на NET! Скорее уж транзистор дойдёт до физического предела и на 256-ядерных процессорах потребуются совсем другие концепции программирования.
Если прога нерезидентная — а особенно если большая — на все эти runtime-библиотеки начхать. Что мы на работе и делаем: одна копия VCL, пять копий VCL — не важно! Репу начинаем чесать только когда рабочая матрица начинает съедать всю память и надо что-то довычислять, а что-то — кэшировать.
Впрочем, и самые низкоуровневые системные штучки забывать не стоит. Кстати, по поводу .NET: такое будет только если всю оконную библиотеку вместе с диспетчером сообщений перепишут на NET! Скорее уж транзистор дойдёт до физического предела и на 256-ядерных процессорах потребуются совсем другие концепции программирования.
>Отлично вас понимаю. И есть желание. Сдам проект — займусь кое-чем другим.
Ну для C++ программистов, которые GUI программируют, я обычно советую использовать Qt, так, как это самый логичный и простой фреймворк, который я только видел для С++, там точно нет никаких проблем со странными хуками, а программы возможно скомпилировать не тольно на x86, amd64, но и на arm, mips, IA-64. Короче говоря, для написания GUI приложений на С++ это одно из лучших решений.
>Впрочем, и самые низкоуровневые системные штучки забывать не стоит.
Самые низкоуровневые системные вызовы не используют winAPI, они пользуются nativeAPI, оно сильно отличается от winAPI, в нем нету такого сильного бремени обратной совместимости, поэтому зачастую старые драйвера не ставятся на новые системы. Это прежде всего системное(ядерное) API, а winAPI это прежде всего юзерспейс, причем, с точки зрения проектирования, весьма уродливый, в основном из за бремени обратной совместимости
Ну для C++ программистов, которые GUI программируют, я обычно советую использовать Qt, так, как это самый логичный и простой фреймворк, который я только видел для С++, там точно нет никаких проблем со странными хуками, а программы возможно скомпилировать не тольно на x86, amd64, но и на arm, mips, IA-64. Короче говоря, для написания GUI приложений на С++ это одно из лучших решений.
>Впрочем, и самые низкоуровневые системные штучки забывать не стоит.
Самые низкоуровневые системные вызовы не используют winAPI, они пользуются nativeAPI, оно сильно отличается от winAPI, в нем нету такого сильного бремени обратной совместимости, поэтому зачастую старые драйвера не ставятся на новые системы. Это прежде всего системное(ядерное) API, а winAPI это прежде всего юзерспейс, причем, с точки зрения проектирования, весьма уродливый, в основном из за бремени обратной совместимости
Qt хорошо конечно, но обычно, если нужны хуки — значит очень платформенно-специфическая задача и Qt не поможет. Попробуйте например написать на Qt Punto Switcher не пользуясь SetWindowsHookEx.
Sign up to leave a comment.
Help: будет ли работать хук клавиатуры Win32 под Win64?