Объектная модель компонента

С

Объектная модель компонента
Аббревиатура	С
Статус	Действующий
Впервые опубликовано	1993 год ( 1993 )
Последняя версия	Уровень жизни 2021
Организация	Майкрософт
Ряд	Системные службы
Базовые стандарты	МИДЛ , UUID
Сопутствующие стандарты	заменено: ДДЕ на базе COM: OLE , OLE Automation , вспомогательный объект браузера , ActiveX , COM+ , DCOM , оболочка Windows , DirectX , UMDF , среда выполнения Windows.
Домен	Интерфейс компонентов
Веб-сайт	учиться .microsoft .с /en-нас /окна /win32 /с /модель-компонента-объекта

Модель компонентных объектов ( COM ) — это технология двоичного интерфейса для программных компонентов от Microsoft , которая позволяет использовать объекты между независимо от языка различными языками программирования , контекстами программирования, процессами и машинами .

COM является основой для других технологий компонентов, специфичных для домена Microsoft, включая OLE , OLE Automation , ActiveX , COM+ и DCOM, а также таких реализаций , как DirectX , оболочка Windows , UMDF , среда выполнения Windows и вспомогательный объект браузера .

COM позволяет использовать объект, зная только его интерфейс; а не его внутренняя реализация. Разработчик компонента определяет интерфейсы , которые отделены от реализации.

Поддержка нескольких контекстов программирования осуществляется путем использования объекта для аспектов, которые было бы сложно реализовать как средство. Поддержка многократного использования объекта осуществляется путем требования к каждому объекту уничтожить себя посредством подсчета ссылок . Доступ к интерфейсам объекта (аналогично преобразованию типов ) также предоставляется каждым объектом.

COM доступен только в Microsoft Windows и Apple Core Foundation 1.3 и более поздних версиях подключаемого интерфейса прикладного программирования (API). Последний реализует лишь часть всего COM-интерфейса.

Со временем COM заменяется другими технологиями, такими как Microsoft .NET и веб-службы (т. е. через WCF ). Однако COM-объекты можно использовать на языке .NET через COM Interop .

COM похож на другие технологии компонентов, такие как SOM , CORBA и Enterprise JavaBeans , хотя каждая из них имеет свои сильные и слабые стороны.

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

История

(DDE), представленный в 1987 году, Динамический обмен данными был одной из первых технологий межпроцессного взаимодействия в Windows . Это позволяло отправлять и получать сообщения в так называемых диалогах между приложениями.

Энтони Уильямс, занимавшийся разработкой архитектуры COM, распространил в Microsoft два документа, в которых рассматривалась концепция программных компонентов: « Объектная архитектура: работа с неизвестным или типобезопасностью в динамически расширяемой библиотеке классов в 1988 году» и «О наследовании: что это значит и как». To Use It в 1990 году. Они легли в основу многих идей, лежащих в основе COM.

Связывание и внедрение объектов (OLE), первая объектная платформа Microsoft, была построена на основе DDE и разработана специально для составных документов . Он был представлен в Word и Excel в 1991 году, а позже был включен в Windows, начиная с версии 3.1 в 1992 году. Примером составного документа является электронная таблица, встроенная в документ Word. При внесении изменений в электронную таблицу Excel они автоматически отображаются в документе Word.

В 1991 году Microsoft представила технологию расширения Visual Basic (VBX) вместе с Visual Basic 1.0. VBX — это упакованное расширение в виде библиотеки динамической компоновки (DLL), которое позволяет графически размещать объекты в форме и управлять ими с помощью свойств и методов . Позже они были адаптированы для использования другими языками, такими как Visual C++ .

В 1992 году вместе с Windows 3.1 Microsoft выпустила OLE 2 с новой базовой объектной моделью COM. COM Двоичный интерфейс приложения (ABI) был таким же, как и MAPI ABI (выпущенный в 1992 году), и, похоже, он был основан на MSRPC и, в конечном итоге, на Open Group DCE/RPC . COM был создан для замены DDE, поскольку его текстовый диалог и дизайн обмена сообщениями Windows не были достаточно гибкими, чтобы обеспечить надежный и расширяемый обмен функциями приложения.

В 1994 году технология пользовательского управления OLE (OCX), основанная на COM, была представлена ​​как преемница VBX. В то же время Microsoft заявила, что OLE 2 будет называться просто «OLE».

В начале 1996 года Microsoft нашла новое применение OCX – расширив возможности своего веб-браузера. Microsoft переименовала некоторые части OLE, относящиеся к Интернету , в ActiveX и постепенно переименовала все технологии OLE в ActiveX, за исключением технологии составных документов, которая использовалась в Microsoft Office .

Позже в 1996 году Microsoft расширила COM для работы в сети с помощью DCOM .

Связанные технологии

МСРПК

IDL COM основан на многофункциональном IDL DCE/RPC с объектно-ориентированными расширениями. Реализация DCE/RPC от Microsoft, MSRPC , используется в качестве основного механизма межпроцессного взаимодействия для служб и внутренних компонентов Windows NT, что делает ее очевидным выбором в качестве основы.

ДКОМ

Основная статья: Объектная модель распределенных компонентов

DCOM расширяет возможности COM от простой поддержки одного пользователя с отдельными приложениями, взаимодействующими на рабочем столе Windows, до активации объектов, работающих в разных контекстах безопасности и на разных компьютерах в сети. При этом были добавлены необходимые функции для настройки того, какие пользователи имеют право создавать, активировать и вызывать объекты, для идентификации вызывающего пользователя, а также указания необходимого шифрования для безопасности вызовов.

COM+

Microsoft представила Microsoft Transaction Server (MTS) в Windows NT 4, чтобы предоставить разработчикам поддержку распределенных транзакций , объединения ресурсов, автономных приложений, публикации событий и подписки, лучшего управления памятью и процессором (потоками), а также позиционировать Windows как альтернатива другим операционным системам корпоративного уровня.

Этот набор функций , переименованный в COM+ в Windows 2000, был включен в операционную систему в отличие от ряда внешних инструментов, предоставляемых MTS. В то же время Microsoft уменьшила значение DCOM как отдельного объекта. Компоненты, использующие COM+, обрабатывались более непосредственно добавленным уровнем COM+; в частности, за счет поддержки перехвата операционной системой. В первой версии МТС был добавлен перехват: установка компонента МТС модифицировала реестр Windows для вызова программного обеспечения МТС, а не непосредственно компонента.

Windows 2000 включала обновления панели управления службами компонентов для настройки компонентов COM+.

Преимущество COM+ заключалось в том, что его можно было запускать в «фермах компонентов». Экземпляры компонента, если они закодированы правильно, могут быть объединены в пул и повторно использованы новыми вызовами его процедуры инициализации без выгрузки его из памяти. Компоненты также могут быть распределены (вызваны с другой машины). COM+ и Microsoft Visual Studio предоставили инструменты, упрощающие создание прокси на стороне клиента, поэтому, хотя для удаленного вызова использовался DCOM, разработчикам было легко это сделать. COM+ также представил механизм событий подписчика/издателя под названием COM+ Events и предоставил новый способ использования MSMQ (технологии, обеспечивающей асинхронный обмен сообщениями между приложениями) с компонентами под названием Queued Components . События COM+ расширяют модель программирования COM+ для поддержки событий позднего связывания (см. Позднее связывание ) или вызовов методов между издателем или подписчиком и системой событий.

.СЕТЬ

Основная статья: .NET Framework

.NET — это компонентная технология Microsoft, заменяющая COM. .NET скрывает многие детали создания компонентов и, следовательно, упрощает разработку.

.NET предоставляет оболочки для часто используемых элементов управления COM.

.NET может использовать COM+ через System.EnterpriseServices пространство имен, а некоторые службы, предоставляемые COM+, были продублированы в .NET. Например, System.Transactions пространство имен предоставляет TransactionScope класс, который обеспечивает управление транзакциями без использования COM+. Аналогично, компоненты в очереди могут быть заменены Windows Communication Foundation (WCF) транспортом MSMQ .

Поддержка обратной совместимости ограничена. COM-объект можно использовать в .NET путем реализации вызываемой оболочки среды выполнения (RCW). NET-объекты, соответствующие определенным ограничениям интерфейса, можно использовать в COM-объектах путем вызова вызываемой оболочки COM (CCW). Как со стороны COM, так и со стороны .NET объекты, использующие другую технологию, отображаются как собственные объекты. См. COM-взаимодействие .

WCF упрощает ряд проблем удаленного выполнения COM. Например, это упрощает прозрачную маршализацию объектов по значениям между границами процесса или машины.

Среда выполнения Windows

Основная статья: Среда выполнения Windows

Среда выполнения Windows ( WinRT ) — это API на основе COM, хотя и расширенный вариант COM. Благодаря своей COM-подобной основе WinRT поддерживает взаимодействие из нескольких контекстов программирования, но это неуправляемый собственный API. Определения API хранятся в файлах «.winmd», которые закодированы в формате метаданных ECMA 335; тот же формат метаданных CLI , который использует .NET, с некоторыми изменениями. Этот формат метаданных позволяет значительно снизить накладные расходы, чем P/Invoke, когда WinRT вызывается из приложений .NET.

Нано-КОМ

Nano-COM — это подмножество COM, ориентированное на аспекты COM, связанные с двоичным интерфейсом приложений (ABI), которые позволяют вызывать функции и методы в независимо скомпилированных модулях/компонентах. Nano-COM можно выразить в переносимом заголовочном файле C++. Nano-COM расширяет собственный ABI базовой архитектуры команд и ОС для поддержки ссылок на типизированные объекты, тогда как типичный ABI фокусируется на атомарных типах, структурах, массивах и соглашениях о вызовах функций.

Заголовочный файл Nano-COM определяет или называет как минимум три типа:

• GUID – определяет тип интерфейса

• HRESULT – коды результатов метода, такие как S_OK, E_FAIL, E_OUTOFMEMORY.

• IUnknown – базовый тип для ссылок на объекты; абстрактные виртуальные функции для поддержки dynamic_cast<T>-стиль приобретения новых типов интерфейса и подсчета ссылок а-ля shared_ptr<T>

Во многих случаях использования Nano-COM в качестве результатов определяются две функции для обращения к буферам памяти, выделенным вызываемому абоненту:

• <NanoCom>Alloc — вызывается реализациями метода для выделения необработанных буферов (не объектов), которые возвращаются вызывающему объекту.

• <NanoCom>Free – вызывается вызывающими методами для освобождения буферов, выделенных вызываемым объектом, когда они больше не используются.

Некоторые реализации Nano-COM, такие как Direct3D, избегают функций распределителя и ограничиваются использованием только буферов, выделяемых вызывающей стороной.

В Nano-COM нет понятия классов, квартир, маршалинга, регистрации и т. д. Вместо этого ссылки на объекты просто передаются через границы функций и распределяются с помощью стандартных языковых конструкций (например, C++). new оператор).

Основа Nano-COM использовалась Mozilla для загрузки Firefox (называемого XPCOM ), и в настоящее время используется в качестве базовой технологии ABI для DirectX / Direct3D / DirectML .

Безопасность

В Интернет Эксплорере

Поскольку элемент управления ActiveX (любой COM-компонент) работает как собственный код, без защиты в песочнице , существует несколько ограничений на его возможности. Использование компонентов ActiveX, поддерживаемых Internet Explorer , на веб-странице приводит к проблемам с заражением вредоносным ПО . Microsoft осознала эту проблему еще в 1996 году, когда Чарльз Фицджеральд сказал: «Мы никогда не заявляли заранее, что ActiveX внутренне безопасен». Более поздние версии Internet Explorer запрашивают пользователя перед установкой элемента управления ActiveX, позволяя заблокировать установку.

В качестве уровня защиты элемент управления ActiveX подписывается цифровой подписью, гарантирующей подлинность.

Также можно полностью отключить элементы управления ActiveX или разрешить только некоторые из них.

Повреждение процесса

Прозрачная поддержка внепроцессных COM-серверов повышает безопасность программного обеспечения с точки зрения изоляции процессов . Это может быть полезно для разделения подсистем большого приложения на отдельные процессы. Изоляция процессов не позволяет повреждению состояния в одном процессе негативно влиять на целостность других процессов, поскольку они взаимодействуют только через строго определенные интерфейсы. Таким образом, для восстановления допустимого состояния необходимо перезапустить только затронутую подсистему. Это не относится к подсистемам одного и того же процесса, где несанкционированный указатель в одной подсистеме может случайно повредить другие подсистемы.

Связывание

COM поддерживается через привязки на нескольких языках, таких как C , C++ , Visual Basic , Delphi , Python. и несколько контекстов сценариев Windows. Доступ к компонентам осуществляется через методы интерфейса . Это обеспечивает прямой вызов внутри процесса и доступ через подсистему COM/DCOM между процессами и компьютерами.

Типовая система

Кокласс

Сокласс , COM - класс, реализует один или несколько интерфейсов. Он идентифицируется идентификатором класса, называемым CLSID , который является GUID , и удобочитаемым программным идентификатором, называемым ProgID . Кокласс создается с помощью одного из этих идентификаторов.

Интерфейс

Каждый COM- интерфейс расширяет IUnknown интерфейс, который предоставляет методы для подсчета ссылок и доступа к другим интерфейсам объекта — аналогично преобразованию типов , также известному как приведение типов.

Интерфейс идентифицируется идентификатором интерфейса (IID), GUID.

Пользовательский интерфейс , все, что получено из IUnknown, обеспечивает ранний доступ через указатель на таблицу виртуальных методов , содержащую список указателей на функции, реализующие функции, объявленные в интерфейсе, в том порядке, в котором они объявлены. Таким образом, накладные расходы на внутрипроцессный вызов сравнимы с вызовом виртуального метода C++.

Диспетчеризация, также известная как доступ с поздним связыванием , обеспечивается путем реализации IDispatch. Диспетчеризация обеспечивает доступ из более широкого диапазона контекстов программирования, чем пользовательский интерфейс.

Как и многие объектно-ориентированные языки, COM обеспечивает отделение интерфейса от реализации. Это различие особенно заметно в COM, где объект не имеет интерфейса по умолчанию. Клиент должен запросить интерфейс для получения доступа. COM поддерживает несколько реализаций одного и того же интерфейса, поэтому клиенты могут выбирать, какую реализацию интерфейса использовать.

Библиотека типов

COM Библиотека типов определяет метаданные COM, такие как сопутствующие классы и интерфейсы. Библиотеку можно определить как язык определения интерфейса (IDL); синтаксис, независимый от языка программирования. IDL похож на C++ с дополнительным синтаксисом для определения интерфейсов и сопутствующих классов. IDL также поддерживает атрибуты в квадратных скобках перед объявлениями для определения метаданных, таких как идентификаторы и связи между параметрами.

Файл IDL компилируется с помощью компилятора MIDL. Для использования с C/C++ компилятор MIDL создает файл заголовка с struct определения, соответствующие vtbls интерфейсов объявленных интерфейсов, и файл C, содержащий объявления GUID . Исходный код C++ для прокси-модуля также может быть сгенерирован компилятором MIDL. Этот прокси-сервер содержит заглушки методов для преобразования вызовов COM в вызовы удаленных процедур, чтобы включить DCOM для связи вне процесса.

MIDL может генерировать библиотеку двоичных типов (TLB), которая может использоваться другими инструментами для поддержки доступа из другого контекста.

Примеры

Следующий код IDL объявляет сокласс с именем SomeClass который реализует интерфейс с именем ISomeInterface.

coclass SomeClass {
  [default] interface ISomeInterface;
};

Это концептуально эквивалентно следующему коду C++, где ISomeInterface — это чистый виртуальный класс , также известный как абстрактный базовый класс.

class ISomeInterface {};
class SomeClass : public ISomeInterface {
};

В C++ объекты COM создаются через подсистему COM. CoCreateInstance функция, которая принимает CLSID и IID. SomeClass можно создать следующим образом:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL, IID_ISomeInterface, (void**)&interface_ptr);

Подсчет ссылок

COM-объект использует подсчет ссылок для управления временем жизни объекта. Счетчик ссылок на объект контролируется клиентами через IUnknown AddRef и Release методы. COM-объекты отвечают за освобождение собственной памяти, когда счетчик ссылок падает до нуля. Некоторые контексты программирования (например, Visual Basic ) обеспечивают автоматический подсчет ссылок для упрощения использования объектов. В C++ интеллектуальный указатель можно использовать для автоматизации управления счетчиком ссылок.

Ниже приведены рекомендации относительно того, когда следует вызывать AddRef и Release :

• Функции, которые возвращают ссылку на интерфейс (через возвращаемое значение или через параметр «out»), увеличивают счетчик возвращаемого объекта.

• Release вызывается до того, как указатель интерфейса будет перезаписан или выйдет за пределы области действия.

• Если создается копия указателя ссылки на интерфейс, AddRef. вызывается

• AddRef и Release вызываются на интерфейсе, на который ссылаются (а не на другом интерфейсе того же объекта), поскольку объект может реализовать подсчет ссылок для каждого интерфейса, чтобы выделить внутренние ресурсы только для интерфейсов, на которые ссылаются.

Для удаленных объектов не все вызовы счетчика ссылок передаются по сети. Прокси-сервер хранит только одну ссылку на удаленный объект и поддерживает собственный счетчик локальных ссылок.

Чтобы упростить разработку COM для разработчиков C++, Microsoft представила ATL (Active Template Library) . ATL предоставляет парадигму разработки COM относительно высокого уровня. Это также защищает разработчиков клиентских приложений COM от необходимости напрямую поддерживать подсчет ссылок, предоставляя интеллектуальные типы указателей. Другие библиотеки и языки, поддерживающие COM, включают классы Microsoft Foundation , поддержку COM компилятора VC , VBScript , Visual Basic , ECMAScript ( JavaScript ) и Borland Delphi .

Контекст программирования

COM — это независимый от языка двоичный стандарт, который позволяет использовать объекты в любом контексте программирования, имеющем доступ к его двоичным интерфейсам.

Клиентское программное обеспечение COM отвечает за включение подсистемы COM, создание экземпляров и подсчет ссылок COM-объектов, а также запрос объектов на наличие поддерживаемых интерфейсов.

Компилятор Microsoft Visual C++ поддерживает расширения языка C++, называемые атрибутами C++ . которые предназначены для упрощения разработки COM и минимизации шаблонного кода, необходимого для реализации COM-серверов на C++.

Тип хранилища метаданных

Первоначально метаданные библиотеки типов должны были храниться в системном реестре. COM-клиент будет использовать информацию реестра для создания объекта.

COM без регистрации (RegFree) был представлен в Windows XP , чтобы позволить хранить метаданные библиотеки типов в виде манифеста сборки либо в качестве ресурса в исполняемом файле, либо в отдельном файле, установленном вместе с компонентом. Это позволяет устанавливать несколько версий одного и того же компонента на одном компьютере в разных каталогах. И это позволяет развертывать XCOPY . Эта технология имеет ограниченную поддержку серверов EXE COM. и не может использоваться для общесистемных компонентов, таких как MDAC , MSXML , DirectX или Internet Explorer .

Во время загрузки приложения загрузчик Windows ищет манифест. Если он присутствует, загрузчик добавляет информацию из него в контекст активации. Когда фабрика классов COM пытается создать экземпляр класса, сначала проверяется контекст активации, чтобы определить, можно ли найти реализацию CLSID. Только если поиск не удался, реестр сканируется.

COM-объект может быть создан без информации о библиотеке типов; только путь к файлу DLL и CLSID. Клиент может использовать функцию COM DLL. DllGetClassObject с CLSID и IID_IClassFactory для создания экземпляра объекта фабрики . Затем клиент может использовать объект фабрики CreateInstance чтобы создать экземпляр. Это тот же процесс, который использует подсистема COM. Если объект, созданный таким образом, создает другой объект, он сделает это обычным способом (с использованием реестра или манифеста). Но он может создавать внутренние объекты (которые могут быть вообще не зарегистрированы) и передавать к ним ссылки на интерфейсы, используя свои собственные знания.

сортировка

Объект COM можно прозрачно создавать и использовать внутри того же процесса (внутри процесса), за пределами границ процесса (вне процесса) или удаленно по сети (DCOM). Внепроцессные и удаленные объекты используют маршалинг для сериализации вызовов методов и возврата значений через границы процесса или сети. Эта сортировка невидима для клиента, который обращается к объекту, как если бы он был локальным внутрипроцессным объектом.

Резьба

В COM многопоточность рассматривается с помощью концепции, известной как апартаменты . Отдельный COM-объект находится ровно в одном апартаменте, который может быть однопоточным или многопоточным. В COM существует три типа апартаментов: однопоточные апартаменты (STA) , многопоточные апартаменты (MTA) и нейтрально-потоковые апартаменты (NA). Каждая квартира представляет собой один механизм, посредством которого внутреннее состояние объекта может быть синхронизировано между несколькими потоками. Процесс может состоять из нескольких COM-объектов, некоторые из которых могут использовать STA, а другие — MTA. Все потоки, обращающиеся к COM-объектам, аналогично живут в одном апартаменте. Выбор места для COM-объектов и потоков определяется во время выполнения и не может быть изменен.

Тип квартиры	Модель резьбы	Описание
Однопоточная квартира (СТА)	Квартира	Один поток предназначен для выполнения методов объекта. Вызовы методов из потоков за пределами апартамента маршалируются и автоматически ставятся в очередь системой (через обмен сообщениями Windows). Таким образом, среда выполнения COM обеспечивает синхронизацию, гарантируя, что каждый вызов метода объекта будет выполнен до завершения, прежде чем будет вызван другой.
Многопоточная квартира (МТА)	Бесплатно	Среда выполнения COM не обеспечивает синхронизацию, и нескольким потокам разрешено одновременно вызывать методы объекта. Объект должен обрабатывать синхронизацию, чтобы предотвратить одновременный доступ из нескольких потоков из-за проблем. Вызовы объекта MTA из потока в STA также маршалируются.
Динамически определенная квартира	Оба	Сервер автоматически выбирает STA или MTA при создании объекта в соответствии с типом подразделения вызывающего потока. Это может быть полезно, чтобы избежать накладных расходов на маршаллинг, когда к серверам MTA обращается поток STA.
Квартира с нейтральной резьбой (NA)	Нейтральный	Особая квартира без каких-либо закрепленных тем. Когда поток STA или MTA вызывает объект NA в том же процессе, вызывающий поток временно покидает свою квартиру и выполняет код непосредственно в NA без какого-либо переключения потоков. Следовательно, NA можно рассматривать как оптимизацию для эффективных вызовов межапартаментных методов.

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

Критика

Сложность

COM относительно сложен, особенно по сравнению с более современными компонентными технологиями, такими как .NET.

Перекачка сообщений

Когда STA инициализируется, она создает скрытое окно, которое используется для маршрутизации сообщений между подразделениями и процессами. Очередь сообщений этого окна должна регулярно «накачиваться». Эта конструкция известна как « насос сообщений ». В более ранних версиях Windows невыполнение этого требования могло привести к общесистемным взаимоблокировкам. Эта проблема усложняется тем, что некоторые API-интерфейсы Windows инициализируют COM как часть своей реализации, что приводит к «утечке» деталей реализации.

Подсчет ссылок

Подсчет ссылок в COM может вызвать проблемы, если на два или более объекта имеются циклические ссылки . При разработке приложения это необходимо учитывать, чтобы объекты не оставались бесхозными. Объекты также могут оставаться с активными счетчиками ссылок, если используется модель «приемника событий» COM. Поскольку объекту, который запускает событие, необходима ссылка на объект, реагирующий на событие, счетчик ссылок последнего никогда не достигнет нуля. Опорные циклы обычно разрываются с помощью внеполосного завершения или разделения идентификаторов. При использовании метода внеполосного завершения объект предоставляет метод, который при вызове заставляет его удалить ссылки на другие объекты, тем самым разрывая цикл. В методе разделенной идентификации одна реализация предоставляет два отдельных COM-объекта (также известных как идентификаторы). Это создает слабую ссылку между COM-объектами, предотвращая цикл ссылок.

DLL Ад

Поскольку внутрипроцессные COM-компоненты реализуются в файлах DLL, а регистрация допускает только одну версию для каждого CLSID, в некоторых ситуациях они могут подвергаться эффекту « DLL Hell ». Возможность COM без регистрации устраняет эту проблему для компонентов, находящихся в процессе обработки; COM без регистрации недоступен для серверов вне процесса.

См. также

• Соглашение о вызовах – способы вызова подпрограмм на компьютерах.
• Общеязыковая инфраструктура – ​​Технический стандарт
• D-Bus — промежуточное программное обеспечение Linux
• Интерфейс внешних функций — интерфейс для вызова функций из других языков программирования.
• Internet Communications Engine – программное обеспечение с открытым исходным кодом.
• Удаленный вызов метода Java - интерфейс прикладного программирования, используемый в средах Java. Страницы, отображающие описания викиданных в качестве запасного варианта.
• KDE Frameworks — коллекция библиотек и программных фреймворков для платформы Qt.
• Искажение имен – техника построения компилятора
• Портативный объект (вычисления) - Объект в распределенном программировании.
• SWIG - инструмент с открытым исходным кодом для создания привязок к языкам программирования. Страницы, отображающие описания викиданных в качестве запасного варианта.

Ссылки

• «COM: Краткое введение (PowerPoint)» (Прямая ссылка на файл PowerPoint (PPT)) . Проверено 7 марта 2006 г.
• Бокс, Дон (1998). Необходимый COM . Аддисон-Уэсли. ISBN  978-0-201-63446-4 .
• Чаппелл, Дэвид (1996). Понимание ActiveX и OLE . Майкрософт Пресс. ISBN  978-1-57231-216-6 .
• «Интеграция и миграция служб COM+ в WCF» . Проверено 15 апреля 2010 г.

Внешние ссылки

• Объектная модель компонентов в MSDN
• Интервью с Тони Уильямсом, соавтором COM (веб-трансляция, август 2006 г.)
• Информация: разница между элементами управления OLE и элементами управления ActiveX от Microsoft
• Спецификация формата данных TypeLib (неофициальная) с утилитой дампера с открытым исходным кодом.
• Глоссарий COM/DCOM (archive.org)