Hooks & COM

← →
volser (2005-11-28 20:15) [0]

Я взаимодействую с глобальным хуком через сообщения и FileMapping. Но хотелось бы что бы мой хук в другом процессе был COM Сервер (OLE ) и общатся через определнный интерфейс. Может кто-то подобное делал?

← →
Digitman © (2005-11-29 08:22) [1]

> взаимодействую с глобальным хуком через сообщения и FileMapping

а по-хорошему надо бы с помощью NamedPipes

> мой хук в другом процессе был COM Сервер (OLE )

сомнительная по необходимости затея

← →
Leonid Troyanovsky © (2005-11-29 11:35) [2]

> Digitman © (29.11.05 08:22) [1]

> > взаимодействую с глобальным хуком через сообщения и FileMapping

> а по-хорошему надо бы с помощью NamedPipes

А чем оно лучше? Оно ж на одной станции.

--
Regards, LVT.

← →
Digitman © (2005-11-29 15:03) [3]

> Leonid Troyanovsky © (29.11.05 11:35) [2]

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

← →
Leonid Troyanovsky © (2005-11-29 15:18) [4]

> Digitman © (29.11.05 15:03) [3]

> сегодня на одной, а завтра на разных)

Тогда уж tcp, на послезавтра :)

--
Regards, LVT.

← →
Digitman © (2005-11-29 15:28) [5]

> Leonid Troyanovsky © (29.11.05 15:18) [4]

для ЛВС слишком жирно)

← →
wal © (2005-11-29 16:54) [6]

> для ЛВС слишком жирно)
Сегодня ЛВС, завтра WAN ;)

← →
volser (2005-11-29 23:15) [7]

Так а как на счет COM?
И почему сомнительная? ЧТо лучше обмениваться сообщения и возвращать результат не понятно куда. И как на счет многопоточности? Как узнать на какое сообщение лежит ответ? Не легче было бы взять интефейс и работать с ним и как между процессами передаются данные не интересует.

← →
Набережных С. © (2005-11-30 08:43) [8]

> volser (29.11.05 23:15) [7]

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

← →
Digitman © (2005-11-30 09:26) [9]

> volser (29.11.05 23:15) [7]

> почему сомнительная?

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

> ЧТо лучше обмениваться сообщения и возвращать результат
> не понятно куда

как это "не понятно куда" ?

если речь идет о SendMessage(), то получателю сообщения без разницы, кто явился его отправителем - результат обработки будет возвращен именно тому отправителю, который вызвал ту самую SendMessage().

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

> как на счет многопоточности?

она никак не мешает сабжу

← →
volser (2005-11-30 12:49) [10]

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

А разве не достаточно выполнить что-то типа такого кода
TAutoObjectFactory.Create(ComServer, THookServer, Class_HookServer, ciSingleInstance); для регистрации фабрики?

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

А причем здесь TAutoObjectFactory ? это ж для фаблик олей-объектов ...

Ты вроде бы речь ведешь о СОМ-взаимодействии ?

Ну так, значит, и фабрика должна создаваться как TCOMObjectFactory ..

> мне интересно чтио будет если это сделать в разных процессах.

попробуй - увидишь ...

> Digitman © (30.11.05 09:26) [9]

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

Ну это-то как раз не проблема. К тому-же, если объект уже существует, то и фабрика ему как-бы ни к чему. Он может, например, зарегистрироваться в таблице исполняемых объектов. Только вот зарегистрировать там можно только один интерфейс одного объекта некоторого класса. А если ClassID налету генерить, то как их потом искать? Но с фабриками все равно та же фигня.

> volser (30.11.05 12:49) [10]

> А разве не достаточно выполнить что-то типа такого кода
> TAutoObjectFactory.Create(ComServer, THookServer, Class_HookServer,
> ciSingleInstance); для регистрации фабрики?

Достаточно, если делать это в секции инициализации модуля. Тогда, если это exe-сервер, объект ComServer произведет регистрацию фабрик. Во всех остальных случаях это нужно делать вручную, вызовом RegisterClassObject у каждой фабрики.

> Только мне интересно чтио будет если это сделать в разных
> процессах.

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

В любом случае, если уж использовать СОМ, то код хука нужно делать клиентом, только так. А управляющее приложение - сервером.

> если уж использовать СОМ, то код хука нужно делать клиентом,
> только так. А управляющее приложение - сервером

совершенно логично.

Hooks &amp; COM Найти похожие ветки

Hooks & COM Найти похожие ветки