одну её часть, когда мы работаем с примитивными COM объектами
Ну это получается как будто DLL подгрузили в память процесса, просто задокументировав с обоих сторон "карту" методов (интерфейс)
Но... теперь другой случай - например работа с Excel
Здесь уже два процесса: мой и сам Excel
Я задумался, а как происходит межпроцессное взаимодействие здесь? Ну вроде есть RPC у MS и вроде как через этот самый RPC
Это получается что - я из своего процесса через MSRPC могу вызывть какой=то обработчик в другом процессе?
Хорошо, а как тогда уже сам Excel разруливает с каким экземпляром Excel ему работать, если их запущено несколько экземпляров?
Там тоже какой-то межпроцессный обмен должен быть - он уже не через RPC идёт наверное, а с помощью каких-то других техник?
А вообще эти мысли и вопросы у меня возникли из-за того, что есть один комплекс программ, общение внутри этого комплекса программ между собой идёт через COM, и документации нету.... а мне нужно кое-что программно сделать, то, что сейчас делаетс вручную... вот хочу как-то понять какой COM объект создать/метод какого интерфейса вызвать...
Создание COM объектов перехватывал, GUID'ы логировал, но часть из них не зарегистрирована в системе, а в другой часть ничего интересного не нашлось
Теперь немного почитав думаю что надо что-то перехватывать в RPCRT4.DLL чтобы отловить что вызывается в нужный мне момент...?
Дон Бокс, Сущность технологии COM. Ещё был цикл статей попроще, на королевстве.
Долго читать, а сделать нужно побыстрее ) Если идёт работа с локальными приложениями, то какой транспорт будет использоваться в MSRPC? Чем перехватить, чтобы не изобретать велосипедов?🤔
Есть такое понятие как COM севрер
https://learn.microsoft.com/ru-ru/windows/win32/com/com-clients-and-servers
Обсуждают сегодня