Как работает это странное 32-битное / 64-битное решение для взаимодействия?

Question

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

Ядро скомпилировано как 32-битная DLL и предназначено для использования из 32-битных приложений. И есть также оболочка, скомпилированная как 64-битная DLL и предназначенная для использования из 64-битных приложений. Оболочка вызывает CoCreateInstance () для создания экземпляра ядра и перенаправляет вызовы в ядро. Ядро зависит от огромного набора других 32-битных библиотек.

32-разрядное ядро ​​регистрируется точно так же, как это обычно делается на сервере in-proc - в HKCR \ CLSID есть запись, содержащая идентификатор класса ядра и путь к библиотеке в InprocServer32. 64-битная прокладка регистрируется таким же образом, а также вводится идентификатор приложения для 64-битной прокладки - он добавляется в HKCR \ CLSID и также регистрируется в DCOM - в консоли DCOM есть запись с этим идентификатором приложения.

Теперь регистрация DCOM выглядит странно. Почему шим должен быть зарегистрирован в DCOM, а не в ядре? Я ожидаю, что 32-разрядное ядро ​​должно быть зарегистрировано в DCOM для создания экземпляра в отдельном процессе и экранирования от 64-разрядного потребителя. Но, видимо, работает так, как сейчас. Какой смысл в регистрации 64-битного шимма, а не 32-битного ядра в DCOM?

Answer 1

Напомним, что вы можете смешивать и сопоставлять 32-битные и 64-битные библиотеки DLL и процессы. В этом случае 32-разрядное ядро ​​не использует DCOM, поскольку оно может быть загружено непосредственно в 32-разрядный процесс хоста. Для 64-битной оболочки требуется DCOM, поскольку разработчики используют возможность COM размещать ядро ​​в отдельном процессе, даже на одной машине. Это необходимо, поскольку 32-битное ядро ​​не может быть загружено на 64-битный хост. Использование DCOM позволяет маршаллизировать все вызовы в ядро ​​и из ядра, сидя в отдельном 32-битном процессе. Это оптимальное соглашение, поскольку вызов ядра не идет через DCOM. Скорее всего, разработчики воспользовались этим при тестировании, отлаживая в 32-битном процессе, не мешая DCOM, пока не было доказано, что ядро ​​работает достаточно хорошо, чтобы попытаться вызвать его из 64-битного приложения.