Такая странная задачка, никак не могу нагуглить решение, вполне вероятно, что это невозможно, но вдруг. Есть некий 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 и само приложение я никак менять не могу.
Навскидку: 1. Добавить классу вариантов запуска в реестре и перехватить CoCreateInstance, заменив флаг, либо 2. Заменить в реестре реальный класс на прокси, который будет редиректить запросы к оригинальному классу, который понятное дело нужно перерегистрировать под новым CLSID А зачем оно изначально нужно, если не секрет?
Ну это довольно сложно описать. Если кратко, то работает некоя система, которая мониторит поведение процессов. Мне нужно, чтобы эта система не могла ассоциировать поведение COM-объекта с поведением приложения, то есть, чтобы функционал COM-объекта был выполнен в отдельном процессе. --- Сообщение объединено, 22 мар 2020 --- В принципе это можно сделать, если никто не предложит более годной альтернативы, то вероятно пойду по этому пути.
Rel, можно попробовать добавить Reg-Free манифест и переопределить CLSID на класс в маленькой библиотеке которая будет при вызове IClassFactory::CreateInstance создавать объект из реальной DLL через DllSurrogate. Не проверял.
