В настоящее время я обслуживаю часть программного обеспечения, которую мы передали на аутсорсинг пару лет назад и которая плохо документирована. Это COM-сервер для использования сторонними приложениями и установщик, который выполняет все необходимое развертывание.
Ядро скомпилировано как 32-битная DLL и предназначено для использования из 32-битных приложений. Также есть прокладка, скомпилированная как 64-битная DLL и предназначенная для использования из 64-битных приложений. Прокладка вызывает CoCreateInstance () для создания экземпляра ядра и перенаправляет вызовы в ядро. Ядро зависит от огромного набора других 32-битных библиотек.
32-разрядное ядро регистрируется точно так же, как обычно внутри процесса - в разделе HKCR \ CLSID есть запись, которая включает идентификатор основного класса и путь к библиотеке в InprocServer32. 64-битная оболочка регистрируется таким же образом, а также для 64-битной оболочки вводится идентификатор приложения - он добавляется в HKCR \ CLSID, а также регистрируется в DCOM - в консоли DCOM есть запись с этим идентификатором приложения.
Сейчас регистрация DCOM выглядит странно. Почему прокладка должна быть зарегистрирована в DCOM, а не в ядре? Я ожидаю, что 32-битное ядро должно быть зарегистрировано в DCOM для создания экземпляра в отдельном процессе и защиты от 64-битного потребителя. Но, видимо, работает так, как сейчас. Какой смысл регистрировать в DCOM 64-битную прокладку, а не 32-битное ядро?
