1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Всегда запускать COM-объект внутри суррогата?

Тема в разделе "WASM.WIN32", создана пользователем Rel, 22 мар 2020.

  1. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.546
    Такая странная задачка, никак не могу нагуглить решение, вполне вероятно, что это невозможно, но вдруг. Есть некий COM-объект, зарегистрированный в системе как InProcServer, и есть некое приложение, которое инстанцирует этот COM-объект с помощью CoCreateInstance(... CLSCTX_INPROC_SERVER ...). К исходному коду приложения я доступа не имею. Так же, как вам наверное известно, COM-объекты могут исполняться внутри так называемых процессов суррогатов (dllhost.exe по-умолчанию). Для этого COM-объекту нужно прописать AppID и в соответствующем поле AppID прописать значение DllSurrogate. В том случае, когда приложение и DLL, в которой есть реализация COM-объекта, не совпадают по архитектурам (например, если приложение 64-битное, а COM-объект 32-битный), то COM-объект будет инстацирован внутри процесса суррогата. Если же архитектуры совпадают, то COM-объект безусловно загружается в инстанциирующее его приложения, то есть его код будет работать внутри процесса приложения, а не суррогата. Внимание вопрос: можно ли сделать так, чтобы COM-объект всегда исполнялся в процессе суррогате, даже в случае совпадения архитектур. Напомню, что приложение инстанциирует его с флагом CLSCTX_INPROC_SERVER и само приложение я никак менять не могу.
     
  2. ormoulu

    ormoulu Active Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    482
    Навскидку:
    1. Добавить классу вариантов запуска в реестре и перехватить CoCreateInstance, заменив флаг, либо
    2. Заменить в реестре реальный класс на прокси, который будет редиректить запросы к оригинальному классу, который понятное дело нужно перерегистрировать под новым CLSID

    А зачем оно изначально нужно, если не секрет?
     
  3. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.546
    Ну это довольно сложно описать. Если кратко, то работает некоя система, которая мониторит поведение процессов. Мне нужно, чтобы эта система не могла ассоциировать поведение COM-объекта с поведением приложения, то есть, чтобы функционал COM-объекта был выполнен в отдельном процессе.
    --- Сообщение объединено, 22 мар 2020 ---
    В принципе это можно сделать, если никто не предложит более годной альтернативы, то вероятно пойду по этому пути.
     
  4. Thetrik

    Thetrik UA6527P

    Публикаций:
    0
    Регистрация:
    25 июл 2011
    Сообщения:
    519
    Rel, можно попробовать добавить Reg-Free манифест и переопределить CLSID на класс в маленькой библиотеке которая будет при вызове IClassFactory::CreateInstance создавать объект из реальной DLL через DllSurrogate. Не проверял.