Предпосылки следующие: уже существует куча программ(и в настоящее время тоже создаются), использующих те или иные хуки. Идея заключается в том, чтобы собрать подобные программы "под одну крышу". Естественно, ни о какой совместимости с уже существующими программами не может идти речи, но при разработке новых можно этот факт учесть.

Принцип работы следующий: есть некая интеграционная оболочка. Все программы, которым нужны хуки, подсоединяются к оболочке в виде плагинов. При старте оболочка опрашивает плагины, какие им нужны хуки, после этого сама кумулятивно(как бы, через логическое сложение) ставит требуемые хуки. По приходе событий от хука оболочка раздает сообщения плагинам, которым нужен данный хук.

Преимущества такого подхода:
1. 100% равноправие для всех плагинов. В обычной системе одна программа, использующая хук, может его заглушить, и тогда событие не дойдет до остальных программ, нуждающихся в этом хуке. Здесь же ставится всего один хук данного типа, поэтому, если оболочка получает событие, то оно гарантированно дойдет до всех.
2. Возможность из одного окна/меню настраивать все программы(плагины), т.е. единый унифицированный интерфейс.

Недостатки:
1. "Скованные одной цепью" (с) N.P.
То есть, если один плагин идет в разнос, он тянет за собой все остальные. Но эту проблему можно решить, запуская программу не напрямую, а с помощю загрузчика, который работает условно по такой схеме:
Do
CreateProcess("myshell.exe"...)
WaitForSingleObject(...)
Loop While IsTerminationCorrect() = FALSE

Я уже написал каркас и простенький плагин(просит хук на клаву, озвучивает нажатия(физические/ввод) клавиш). Осталось только написать менеджер плагинов с UI.
Доступ к исходникам у меня будет завтра-послезавтра.

Есть какие-нибудь предложения/пожелания по поводу организации данной системы?

Toxic
Вот некоторая интересная из статьи И.Н. Коваленко "Photon microGUI: По ту строну картинки" (QNX):

Распределенное пространство событий

В любой графической системе есть понятие событий. Обычно событие характеризуется определенным набором атрибутов, в том числе координатами объекта, с которым оно связано. Ядро системы отвечает за определение адресата, то есть модуля который должен обработать событие. События и объекты существуют в одной плоскости.

Основная суть идеи, реализованной в системе Photon, состоит в введении третьей координаты - оси событий. В результате события и объекты связываются в единое пространство. Как будет показано далее, фрагменты этого пространства могут быть распределены по узлам сети, поэтому разработчики системы используют выражение "распределенным пространство событий". Эта концепция, несмотря на свою простоту, имеет очень интересные следствия.

События

Во избежание неоднозначностей, оговорюсь что термин "событие" в системе Photon имеет точный смысл и, когда он употребляется, имеется ввиду именно этот смысл.
Событие представляет собой сообщение ОС QNX с определенной структурой и семантикой, посылаемое всем "заинтересованным" приложениям ядром системы Photon. Этот факт обычно скрыт от приложений, поскольку прикладной интерфейс системы Photon оперирует именно понятием "событие", а не "сообщение". Это, однако, не мешает приложениям системы Photon получать обычные сообщения.

Поскольку события существуют в пространстве, они (как и регионы) имеют координаты, причем не обязательно точечные. Каждое событие характеризуется прямоугольной областью, определяющей зону действия события и положение события относительно оси событий. Все события распространяются вдоль этой оси в одном из двух направлений. При возбуждении события, для него задаются источник (регион, от которого оно начинает двигаться), адресат и направление распространения. Возможна также прямая доставка событий от источника к адресату (прыжком).

Регионы

Для определения соответствия между событием и адресатом используется понятие регионов, "населяющих" пространство событий. Регион тоже определяется прямоугольной областью, но он не двигается вдоль оси событий - его положение фиксировано. Каждый регион имеет два атрибута - чувствительность (sensitivity) и непрозрачность (opacity).
Под чувствительностю понимается способность региона "замечать" указанные события, "проходящие" через него. Под непрозрачностью понимается способность региона вырезать из области указанных событий ту часть, которая пересекается с его собственной областью. Каждый регион имеет также и владельца - приложение, который будет уведомляться о событиях, к которым регион чувствителен. Иначе говоря, регион это агент приложения в пространстве событий.

При прохождении события через регионы, непрозрачные для него, область определения события трансформируется. Если первоначально эта область представляет собой прямоугольник, то при поступлении события к адресату она, в общем случае, выглядит как швейцарский сыр и описывается списком прямоугольников меньшего размера. Особенно наглядно этот процесс проявляется для событий DRAW/EXPOSE - когда приложение пытается себя перерисовать, графический драйвер получает только те фрагменты картинки, которые не перекрыты на экране другими программами (т.е. регионами).

Графическое ядро

В традиционных графических системах нижний уровень представлен графическим драйвером. Все остальные модули и приложения пользуются его услугами. Поскольку драйвер работает с локальной видеосистемой, приложения ограничены локальным компьютером.

Несколько дальше идет система X Window, реализующая концепцию клиент-сервер применительно к графической системе. В ней существует понятие X-протокола, обеспечиваемого X-сервером (включающим в себя видеодрайвер). Клиенты (то есть приложения) могут пользоваться услугами любого доступного X-сервера, в том числе удаленного. Однако события могут возникать только там-же, где функционирует сервер.

Система Photon делает следующий шаг. Здесь видеодрайвер является таким же приложением, как и любая пользовательская программа. Все приложения и компоненты системы взаимодействуют между собой, получают информацию о событиях и реализуют свой сервис через единый унифицированный механизм регионов (агентов) и событий. Это свойство системы разработчики называют когерентностью. Абстракция регионов и событий поддерживается графическим ядром, которое и называется Photon. Поскольку транспортным механизмом для событий являетются сообщения сетевой ОС QNX, регион и владелец могут находиться на разных узлах сети. Регионы (как и положено агентам) служат не только для получения информации о событиях, но и для реализации собственных целей приложения. Например, для того чтобы что-либо нарисовать, приложение возбуждает событие типа DRAW, для перемещения объекта - событие DRAG, для перемещения мыши - PTR_MOVE и т.д., используя свой собственный регион в качестве источника события. Модуль, обеспечивающий соответсвующий сервис, просто устанавливает регион, чувствительный к соответствующему типу событий.

Таким образом, в системе Photon события, регионы и приложения могут быть произвольным образом распределены по сети.

Драйверы ввода/вывода

Под ними понимаются драйверы указательных устройств и клавиатуры (устройства ввода) а также видеодрайверы и драйверы принтеров (устройства вывода). Как было отмечено выше, драйверы являются обычными приложениями, так что их название говорит лишь об их функциональном назначении, но не об особом механизме работы. Технологически взаимодействие между ядром, драйверами и приложениями выглядит следующим образом.

Ядро при запуске создает два фиксированных региона - корневой (root) и регион устройств (device). Если представить себе пространство событий в виде аквариума, то корневой регион это сторона, противоположная наблюдателю (пользователю). Ближнаяя сторона соотвествует экрану монитора, а регион устройств находится посередине.

По принятому соглашению, драйверы устройств устанавливают свои регионы перед регионом устройств (ближе к наблюдателю), а прочие приложения - за ним. При этом драйверы ввода посылают события в сторону корневого региона, где они принимаются какими-либо приложениями и, возможно, трансформируются. Затем приложения посылают соответствующие события в обратную сторону, где они принимаются и обрабатываются драйверами вывода.

Необходимость в существовании формального региона устройств объясняется принятой технологией указания относительного положения регионов вдоль оси событий. При создании региона его положение задается неявно, через понятия предков, потомков и братьев. Потомок (child) всегда ближе к наблюдателю, чем предок (parent), а брат потомка может быть ближе чем он (brother-in-front), либо дальше (brother-behind), но в любом случае ближе предка. Регионы драйверов являются потомками региона устройств, а регионы прочих приложений - потомками корневого региона. Кроме того, благодаря региону устройств, ядро имеет возможность получать интересующие его события от драйверов до того, как они попадут к приложениям.

Black_mirror
Что-то я не понял, что ты хотел сказать. Данная абстракция применима к GUI, а для данного проекта оно зачем?

P.S. кинь ссылочку на полный материал - вещь интересная, как-нибудь на досуге почитаю.

Toxic
В некоторых случаях программу интересует событие только если оно произошло в какой-то определенной области. Причем если оно произошло именно в этой области то другие знать о нем не должны. По моему такой механизм стоит предусмотреть. Если конечно это возможно. А необходимость использовать хуки свидетельствует только о кривизне винды. И боюсь что есть только один метод исправления горбатого 8)
P.S: Тот сайт вроде умер, так что статью добавлю сюда. Только в ней много информации рекламного характера.

1684724503__qnx.zip

Black_mirror
По моему такой механизм стоит предусмотреть
Да, механизм нужный, но не здесь. Ведь у меня другие цели, здесь он совершенно ни к чему.

А необходимость использовать хуки свидетельствует только о кривизне винды.
Согласен. На что Bill Gates бы заявил: "This is not a bug, this is a feature." :)

Ну что ж, господа, вот исходники. Прошу критиковать с особой свирепостью :)

Сразу отмечу: это только каркас, поэтому кое что не доделано:
1. IShell.Exe работает жестко с одним плагином, путь к которому прописан в исходнике.
2. в IShell.Dll из всех поцедур хуков проверена и работает только WH_KEYBOARD. Остальные были созданы путем COPY&PASTE.


453793761__IShell.zip

Что, никто не хочет даже поругать? Абыдна! :(((

Ну раз не хотите ругать, то выскажите мнения или предложения по поводу организации данной системы. Ведь отсустсвие критики вовсе не говорит о ее безупречности.

Вещь интересная, если её правильно развивать дальше.

Когда я увидел TrueLaunchBar, я плюнул на это дело, т.к. он уже содержит все то, что я хотел сделать.

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

Так что все?

Всё, не всё.
{Когда я увидел TrueLaunchBar, я плюнул на это дело, т.к. он уже содержит все то, что я хотел сделать}

Значит нужно делать, то чего в ней нет.
Не могбы дать ссылочку, где её выкачать. Или если нету, то могбы кинуть на мыло, если не особо большая. :)

avalonec@mail.ru

http://www.truelaunchbar.com/

Зы: использую версию 2.2, 3.0 глючит..

У меня подобное обкатывается в программе. Каждый плагин при загруке указывает, какой хук ему нужен. Затем вешаются нужные хуки, у каждого из которых своя очередь процедур плагинов, которые следует вызывать.

Пасиба, посмотрю...