Войти
Модель компонентных объектов (COM ) - это двоичный интерфейс стандарт для программных компонентов, представленный Microsoft в 1993 году. Он используется для включения межпроцессного взаимодействия объект создание в большом количестве языков программирования. COM является основой для нескольких других технологий и сред Microsoft, включая OLE, OLE Automation, Browser Helper Object, ActiveX, COM +, DCOM, оболочка Windows, DirectX, UMDF и среда выполнения Windows. Суть COM - это не зависящий от языка способ реализации объектов, которые можно использовать в средах, отличных от той, в которой они были созданы, даже за пределами машин. Для хорошо написанных компонентов COM позволяет повторно использовать объекты, не зная об их внутренней реализации, поскольку заставляет разработчиков компонентов предоставлять четко определенные интерфейсы, которые отделены от реализации. Различная семантика распределения языков учитывается путем возложения на объекты ответственности за их собственное создание и уничтожение посредством подсчета ссылок. Преобразование типов между различными интерфейсами объекта достигается с помощью метода QueryInterface. Предпочтительный метод «наследования» в COM - это создание подобъектов, которым делегируются «вызовы» методов.
COM - это интерфейсная технология, определенная и реализованная как стандартная только в Microsoft Windows и Apple Core Foundation 1.3 и более поздних версиях плагина интерфейс прикладного программирования (API). Последний реализует только часть всего COM-интерфейса. Для некоторых приложений COM был по крайней мере частично заменен платформой Microsoft.NET, а поддержка Web Services через Windows Communication Foundation (WCF). Однако COM-объекты можно использовать со всеми языками.NET через.NET COM Interop. Сетевой DCOM использует двоичные проприетарные форматы, в то время как WCF поощряет использование обмена сообщениями на основе XML SOAP. COM очень похож на другие интерфейсные технологии компонентного программного обеспечения, такие как CORBA и Enterprise JavaBeans, хотя у каждой есть свои сильные и слабые стороны. В отличие от C ++, COM предоставляет стабильный двоичный интерфейс приложения (ABI), который не меняется между выпусками компилятора. Это делает COM-интерфейсы привлекательными для объектно-ориентированных библиотек C ++, которые должны использоваться клиентами, скомпилированными с использованием разных версий компилятора.
Один из первых методов межпроцессное взаимодействие в Windows было динамическим обменом данными (DDE), впервые представленным в 1987 году, что позволяло отправлять и получать сообщения в так называемых «разговорах» между приложениями., который участвовал в создании архитектуры COM, позже распространил в Microsoft два внутренних документа, охватывающих концепцию программных компонентов: Объектная архитектура: работа с безопасностью неизвестного или типа в динамически расширяемой библиотеке классов в 1988 году и о наследовании. : Что это означает и как использовать в 1990 году. Они легли в основу многих идей, лежащих в основе COM. Связывание и встраивание объектов (OLE), первая объектно-ориентированная структура Microsoft, была построена на основе DDE и разработана специально для составных документов. Он был представлен в Word для Windows и Excel в 1991 году, а позже был включен в Windows, начиная с версии 3.1 в 1992 году. Примером составного документа является электронная таблица встроен в документ Word для Windows: по мере внесения изменений в электронную таблицу в Excel они автоматически появляются внутри документа Word.
В 1991 году Microsoft представила Visual Basic Extensions (VBX) с Visual Basic 1.0. VBX - это пакетное расширение в форме библиотеки динамической компоновки (DLL), которая позволяет графически размещать объекты в форме и управлять ими с помощью свойств и методов. Позже они были адаптированы для использования в других языках, таких как Visual C ++. В 1992 году, когда была выпущена версия 3.1 Windows, Microsoft выпустила OLE 2 с лежащей в основе объектной моделью. Двоичный интерфейс приложения COM (ABI) был таким же, как MAPI ABI (выпущен в 1992 г.), и, как и он, был основан на MSRPC и, в конечном итоге, на Open Group DCE / RPC. В то время как OLE 1 был ориентирован на составные документы, COM и OLE 2 были разработаны для работы с программными компонентами в целом. Текстовые разговоры и сообщения Windows оказались недостаточно гибкими, чтобы обеспечить надежный и расширяемый общий доступ к функциям приложений, поэтому COM был создан в качестве новой основы, а OLE сменили на OLE2. В 1994 году пользовательские элементы управления OLE (OCX) были представлены в качестве преемника элементов управления VBX. В то же время Microsoft заявила, что OLE 2 будет называться просто «OLE», и что OLE больше не является аббревиатурой, а является названием всех компонентных технологий компании. В начале 1996 года Microsoft нашла новое применение для настраиваемых элементов управления OLE, расширив возможности своего веб-браузера для представления содержимого, переименовав некоторые части OLE, относящиеся к Интернету «ActiveX », и постепенно переименовал все технологии OLE в ActiveX, за исключением технологии составных документов, которая использовалась в Microsoft Office. Позже в том же году Microsoft расширила COM для работы в сети с DCOM.
COM была основной платформой разработки программного обеспечения для Windows и, как таковая, повлияла на разработку ряда поддерживающих технологий.. На него также сильно повлияли более ранние технологии.
COM заменил DDE в качестве предпочтительной формы межпроцессного взаимодействия.
В качестве межъязыковой компонентной модели COM полагается на язык определения интерфейса, или IDL, для описания объектов и связанных функций. COM IDL в значительной степени основан на многофункциональном IDL DCE / RPC с объектно-ориентированными расширениями. Собственная реализация Microsoft DCE / RPC, известная как MSRPC, широко используется в качестве основного механизма межпроцессного взаимодействия для служб и внутренних компонентов Windows NT, что делает его очевидным выбором в качестве основы.
DCOM (распределенный COM) расширил возможности COM: от простой поддержки одного пользователя с отдельными приложениями, взаимодействующими на рабочем столе Windows, до активации объектов, работающих в разных контекстах безопасности и на разных машинах в сеть. Вместе с этим были добавлены необходимые функции для настройки того, какие пользователи имеют право создавать, активировать и вызывать объекты, для идентификации вызывающего пользователя, а также указывать необходимое шифрование для безопасности вызовов.
Для предоставления разработчикам поддержки распределенных транзакций, пула ресурсов, отключенных приложений, публикации событий и подписки, улучшенной памяти и процессора (потока) для разработчиков. управления, а также позиционировать Windows как альтернативу другим операционным системам корпоративного уровня, Microsoft представила технологию под названием Microsoft Transaction Server (MTS) в Windows NT 4. В Windows 2000 это существенное расширение для COM был включен в операционную систему (в отличие от ряда внешних инструментов, предоставляемых MTS ) и переименован в COM + . В то же время Microsoft перестала выделять DCOM как отдельную сущность. Компоненты, которые использовали службы COM +, обрабатывались более непосредственно добавленным уровнем COM +, в частности, за счет поддержки перехвата операционной системой. В первом выпуске MTS перехват был добавлен - установка компонента MTS изменяла бы реестр Windows для вызова программного обеспечения MTS, а не непосредственно компонента. Windows 2000 также доработала приложение панели управления службами компонентов, используемое для настройки компонентов COM +.
Преимущество COM + состояло в том, что его можно было запускать в «фермах компонентов». Экземпляры компонента, если они закодированы правильно, могут быть объединены и повторно использованы новыми вызовами его процедуры инициализации без выгрузки из памяти. Компоненты также могут быть распределены (вызваны с другой машины). COM + и Microsoft Visual Studio предоставили инструменты, упрощающие создание прокси на стороне клиента, поэтому, хотя DCOM использовался для удаленного вызова, это было легко сделать для разработчиков. COM + также представил механизм событий подписчика / издателя, называемый COM + Events, и предоставил новый способ использования MSMQ (технология, обеспечивающая асинхронный обмен сообщениями между приложениями) с компонентами, называемыми Компоненты в очереди . События COM + расширяют модель программирования COM + для поддержки событий с поздней привязкой (см. Поздняя привязка ) или вызовов методов между издателем или подписчиком и системой событий.
Microsoft.NET предоставляет средства как для предоставления технологии компонентов, так и для взаимодействия с COM + (через сборки COM-взаимодействия);.NET предоставляет оболочки для большинства часто используемых элементов управления COM. Microsoft.NET скрывает большую часть деталей от создания компонентов и, следовательно, упрощает разработку..NET может использовать COM + через пространство имен System.EnterpriseServices, а некоторые службы, предоставляемые COM +, были продублированы в последних выпусках.NET. Например, пространство имен System.Transactions в.NET предоставляет класс TransactionScope, который обеспечивает управление транзакциями без использования COM +. Аналогично, поставленные в очередь компоненты можно заменить на Windows Communication Foundation с транспортом MSMQ. (Однако MSMQ - это собственный компонент COM.) Имеется ограниченная поддержка обратной совместимости. COM-объект может использоваться в.NET путем реализации Runtime Callable Wrapper (RCW). Объекты.NET, которые соответствуют определенным ограничениям интерфейса, могут использоваться в COM-объектах путем вызова вызываемой COM-оболочки (CCW). Как со стороны COM, так и со стороны.NET объекты, использующие другую технологию, отображаются как собственные объекты. См. COM-взаимодействие. WCF (Windows Communication Foundation) упрощает ряд проблем удаленного выполнения COM. Например, это позволяет более легко упорядочивать объекты по значению через границы процесса или машины.
Новая среда выполнения Windows (или WinRT, не путать с Windows RT ) от Microsoft и модель программирования и приложения, по сути, представляет собой API-интерфейс на основе COM, хотя он полагается на улучшенный COM. Благодаря своей основе, подобной COM, среда выполнения Windows позволяет относительно легко взаимодействовать с несколькими языками, как и COM, но по сути это неуправляемый собственный API. Однако определения API хранятся в файлах ".winmd", которые закодированы в формате метаданных ECMA 335, в том же формате метаданных CLI, который использует.NET с некоторыми изменениями. Этот общий формат метаданных позволяет значительно снизить накладные расходы, чем P / Invoke, когда WinRT вызывается из приложений.NET, а его синтаксис намного проще.
Компоненты COM и ActiveX выполняются как собственный код на компьютере пользователя без изолированной программной среды. Поэтому есть несколько ограничений на то, что может делать код. Таким образом, предшествующая практика встраивания компонентов ActiveX на веб-страницы с помощью Internet Explorer приводила к проблемам с заражением вредоносным ПО. Microsoft осознала проблему ActiveX еще в 1996 году, когда Чарльз Фицджеральд сказал: «Мы никогда не заявляли заранее, что ActiveX по своей сути безопасен». Последние версии Internet Explorer запрашивают пользователя перед установкой элементов управления ActiveX, что позволяет пользователю запретить установку элементов управления с сайтов, которым он не доверяет. Элементы управления ActiveX подписаны с помощью цифровых подписей, чтобы гарантировать их подлинность. Также можно полностью отключить элементы управления ActiveX или разрешить только некоторые из них. Прозрачная поддержка внепроцессных COM-серверов по-прежнему способствует безопасности программного обеспечения с точки зрения изоляции процессов. Это может быть полезно для разделения подсистем большого приложения на отдельные процессы. Изоляция процесса ограничивает повреждение состояния в одном процессе от негативного воздействия на целостность других процессов, поскольку они взаимодействуют только через строго определенные интерфейсы. Таким образом, для восстановления допустимого состояния необходимо перезапустить только затронутую подсистему. Это не относится к подсистемам в одном процессе, где мошеннический указатель в одной подсистеме может случайным образом повредить другие подсистемы.
Программисты COM создают свое программное обеспечение, используя COM-осведомленные компоненты. Различные типы компонентов идентифицируются идентификаторами класса (CLSID), которые являются глобальными уникальными идентификаторами (GUID). Каждый COM-компонент раскрывает свои функции через один или несколько интерфейсов . Различные интерфейсы, поддерживаемые компонентом, отличаются друг от друга с помощью идентификаторов интерфейсов (IID), которые также являются идентификаторами GUID. COM-интерфейсы имеют привязки на нескольких языках, таких как C, C ++, Visual Basic, Delphi, Python и нескольких языков сценариев, реализованных на платформе Windows. Весь доступ к компонентам осуществляется с помощью методов интерфейсов. Это позволяет использовать такие методы, как межпроцессное или даже межкомпьютерное программирование (последнее с использованием поддержки DCOM).
Все компоненты COM реализуют интерфейс IUnknown (настраиваемый), который предоставляет методы для подсчета ссылок и преобразования типов (кастинг). Пользовательский интерфейс IUnknown состоит из указателя на таблицу виртуальных методов , которая содержит список указателей на функции, реализующие функции, объявленные в интерфейсе, в том же порядке, в котором они объявлены в интерфейсе. Таким образом, затраты на вызов внутри процесса сопоставимы с вызовами виртуальных методов в C ++. В дополнение к настраиваемым интерфейсам COM также поддерживает интерфейсы диспетчеризации, унаследованные от IDispatch. Интерфейсы диспетчеризации поддерживают позднее связывание для OLE Automation. Это позволяет осуществлять доступ к интерфейсам диспетчеризации из более широкого диапазона языков программирования, чем пользовательские интерфейсы.
COM-класс («кокласс») представляет собой конкретную реализацию одного или нескольких интерфейсов и очень похож на классы в языках объектно-ориентированного программирования. Классы создаются на основе их идентификатора класса (CLSID ) или на основе их строки программного идентификатора (progid). Как и многие объектно-ориентированные языки, COM обеспечивает отделение интерфейса от реализации. Это различие особенно сильно проявляется в COM, где к объектам нельзя получить доступ напрямую, а только через их интерфейсы. COM также поддерживает несколько реализаций одного и того же интерфейса, так что клиенты в среде выполнения могут выбирать, какую реализацию интерфейса создать.
Библиотеки типов содержат метаданные для представления типов COM. Эти типы описаны с помощью языка определения интерфейса Microsoft (MSIDL / IDL). Файлы IDL определяют объектно-ориентированные классы, интерфейсы, структуры, перечисления и другие определяемые пользователем типы независимо от языка. IDL по внешнему виду похож на объявления C ++ с некоторыми дополнительными ключевыми словами, такими как «интерфейс» и «библиотека» для определения интерфейсов и коллекций классов. IDL также поддерживает использование атрибутов в квадратных скобках перед объявлениями для предоставления дополнительной информации, такой как идентификаторы GUID интерфейса и отношения между параметрами указателя и полями длины. Файлы IDL компилируются компилятором MIDL . Для C / C ++ компилятор MIDL генерирует независимый от компилятора файл заголовка, содержащий определения структур, соответствующие vtbls объявленных интерфейсов, и файл C, содержащий объявления интерфейса GUID. Исходный код C ++ для прокси-модуля также может быть сгенерирован компилятором MIDL. Этот прокси-сервер содержит заглушки методов для преобразования вызовов COM в вызовы удаленных процедур, чтобы включить DCOM для связи вне процесса. Файлы IDL также могут быть скомпилированы компилятором MIDL в библиотеку типов (TLB). Файлы TLB содержат двоичные метаданные, которые могут обрабатываться компиляторами различных языков и средами выполнения (например, VB, Delphi,.NET и т. Д.) Для создания языковых конструкций для представления типов COM, определенных в TLB. Для C ++ это преобразует TLB обратно в его представление IDL.
Поскольку COM - это среда выполнения, типы должны быть индивидуально идентифицируемыми и определяемыми во время выполнения. Для этого используются глобальные уникальные идентификаторы (GUID). Каждому типу COM назначается собственный идентификатор GUID для идентификации во время выполнения. Чтобы информация о типах COM была доступна как во время компиляции, так и во время выполнения, COM использует библиотеки типов. Благодаря эффективному использованию библиотек типов COM реализует свои возможности в качестве динамической основы для взаимодействия объектов.
Рассмотрим следующий пример определения компонентного класса в IDL:
компонентный класс SomeClass {[по умолчанию] interface ISomeInterface; };Приведенный выше фрагмент кода объявляет COM-класс с именем SomeClass, который реализует интерфейс с именем ISomeInterface.
. Это концептуально эквивалентно определению следующего класса C ++:
class SomeClass: public ISomeInterface {......};, где ISomeInterface - это чистый виртуальный класс C ++ (иногда называемый абстрактным базовым классом).
IDL-файлы, содержащие COM-интерфейсы и классы, компилируются в файлы библиотек типов (TLB), которые впоследствии могут анализироваться клиентами во время выполнения, чтобы определить, какие интерфейсы поддерживает объект, и вызвать методы интерфейса объекта.
В C ++ объекты COM создаются с помощью функции CoCreateInstance, которая принимает в качестве аргументов идентификатор класса (CLSID) и идентификатор интерфейса (IID). Создание экземпляра SomeClassможет быть реализовано следующим образом:
ISomeInterface * interface_ptr = NULL; HRESULT hr = CoCreateInstance (CLSID_SomeClass, NULL, CLSCTX_ALL, IID_ISomeInterface, (void **) interface_ptr);
В этом примере подсистема COM используется для получения указателя на объект, реализующий интерфейс ISomeInterface, и требуется конкретная реализация этого интерфейса CLSID_SomeClass в коклассе.
Все COM-объекты используют подсчет ссылок для управления временем жизни объекта. Счетчики ссылок контролируются клиентами с помощью методов AddRef и Release в обязательном интерфейсе IUnknown, который реализуют все COM-объекты. Затем COM-объекты отвечают за освобождение собственной памяти, когда счетчик ссылок падает до нуля. Некоторые языки (например, Visual Basic ) обеспечивают автоматический подсчет ссылок, поэтому разработчикам COM-объектов не нужно явно поддерживать какой-либо внутренний счетчик ссылок в своих исходных кодах. В C ++ кодировщик может либо выполнять явный подсчет ссылок, либо использовать интеллектуальные указатели для автоматического управления счетчиком ссылок.
Ниже приведены рекомендации о том, когда вызывать AddRef и Release для COM-объектов:
Не все вызовы счетчика ссылок отправляются удаленным объектам по сети; Прокси-сервер хранит только одну ссылку на удаленный объект и поддерживает свой собственный локальный счетчик ссылок. Чтобы упростить разработку COM, Microsoft представила ATL (Active Template Library) для разработчиков на C ++. ATL обеспечивает парадигму разработки COM более высокого уровня. Он также защищает разработчиков клиентских приложений COM от необходимости напрямую поддерживать подсчет ссылок, предоставляя объекты интеллектуального указателя. Другие библиотеки и языки, поддерживающие COM, включают классы Microsoft Foundation, VC Compiler COM Support, VBScript, Visual Basic, ECMAScript (JavaScript ) и Borland Delphi.
COM - это не зависящий от языка двоичный стандарт, который может быть разработан в любой язык программирования, способный понимать и реализовывать свои двоично определенные типы данных и интерфейсы. Реализации COM отвечают за вход в среду COM и выход из нее, создание экземпляров и подсчет ссылок COM-объектов, запросы объектов для поддерживаемых интерфейсов, а также обработку ошибок. Компилятор Microsoft Visual C ++ поддерживает расширения для языка C ++, называемые атрибутами C ++. Эти расширения предназначены для упрощения разработки COM и удаления большей части связующего кода, необходимого для реализации серверов COM в C ++.
В Windows классы COM, интерфейсы и библиотеки типов перечислены как GUID в реестре, в HKEY_CLASSES_ROOT \ CLSID для классов и HKEY_CLASSES_ROOT \ Interface для интерфейсов. Библиотеки COM используют реестр, чтобы найти либо правильные локальные библиотеки для каждого COM-объекта, либо сетевое расположение для удаленной службы.
COM без регистрации (RegFree COM) - это технология, представленная в Windows XP, которая позволяет использовать компоненты модели компонентных объектов (COM) для хранения метаданных активации и CLSID (Class ID) для компонента без использования реестра. Вместо этого метаданные и идентификаторы CLSID классов, реализованных в компоненте, объявляются в манифесте сборки (описанном с помощью XML ), хранящемся либо в качестве ресурса в исполняемом файле, либо в виде отдельного файла. установлен вместе с компонентом. Это позволяет устанавливать несколько версий одного и того же компонента в разные каталоги, описываемые их собственными манифестами, а также развертывание XCOPY. Этот метод имеет ограниченную поддержку COM-серверов EXE и не может использоваться для общесистемных компонентов, таких как MDAC, MSXML, DirectX или Internet Explorer.
Во время загрузки приложения загрузчик Windows ищет манифест. Если он присутствует, загрузчик добавляет из него информацию в контекст активации. Когда фабрика классов COM пытается создать экземпляр класса, сначала проверяется контекст активации, чтобы увидеть, можно ли найти реализацию для CLSID. Реестр сканируется только в случае сбоя.
COM-объекты также могут быть созданы вручную, учитывая путь к DLL и GUID объекта. Это не требует регистрации DLL или GUID в системном реестре и не использует файлы манифеста. COM-DLL экспортирует функцию с именем DllGetClassObject. Вызов DllGetClassObject с желаемым GUID и IID_IClassFactory предоставляет экземпляр фабричного объекта . У объекта Factory есть метод CreateInstance, который может создавать экземпляры объекта с помощью GUID интерфейса. Это тот же процесс, который используется внутри при создании экземпляров зарегистрированных компонентов COM.
Если созданный COM-объект создает экземпляр другого COM-объекта с помощью универсального API CoCreateInstance, он попытается сделать это обычным универсальным способом, используя файлы реестра или манифеста. Но он может создавать внутренние объекты (которые могут вообще не регистрироваться) и передавать им ссылки на интерфейсы, используя свои собственные личные знания.
COM-объекты могут быть прозрачно созданы и на них можно ссылаться из одного процесса (внутри процесса), через границы процесса (вне процесса) или удаленно через сеть (DCOM). Внепроцессные и удаленные объекты используют маршаллинг для сериализации вызовов методов и возвращаемых значений через границы процесса или сети. Этот маршаллинг невидим для клиента, который обращается к объекту, как если бы он был локальным внутрипроцессным объектом.
В COM многопоточность решается с помощью концепции, известной как апартаменты. Отдельный COM-объект находится ровно в одном апартаменте, который может быть однопоточным или многопоточным. В COM есть три типа квартир: однопоточная квартира (STA), многопоточная квартира (MTA) и ниточно-нейтральная квартира (NA). Каждая квартира представляет собой один механизм, посредством которого внутреннее состояние объекта может быть синхронизировано в нескольких потоках. Процесс может состоять из нескольких COM-объектов, некоторые из которых могут использовать STA, а другие могут использовать MTA. Все потоки, обращающиеся к COM-объектам, аналогично живут в одной квартире. Выбор квартиры для COM-объектов и потоков определяется во время выполнения и не может быть изменен.
| Тип подразделения | Описание |
|---|---|
| Однопотоковое подразделение (STA), (ThreadingModel = Apartment) | Отдельный поток предназначен для выполнения методов объекта. При таком расположении вызовы методов из потоков за пределами подразделения упорядочиваются и автоматически ставятся в очередь системой (через стандартную очередь сообщений Windows). Таким образом, среда выполнения COM обеспечивает автоматическую синхронизацию, чтобы гарантировать, что каждый вызов метода объекта всегда выполняется до завершения перед вызовом другого. Таким образом, разработчику не нужно беспокоиться о блокировке потоков или условиях гонки. |
| Многопоточный блок (MTA), (ThreadingModel = Free) | Среда выполнения COM не обеспечивает синхронизации, и нескольким потокам разрешено вызывать объекты COM одновременно. Следовательно, COM-объекты должны выполнять свою собственную синхронизацию, чтобы предотвратить одновременный доступ из нескольких потоков, вызывающий состояние гонки. Вызовы объекта MTA из потока в STA также упорядочиваются. |
| Динамически определяемое подразделение (ThreadingModel = Both) | В режиме «Оба подразделения» сервер автоматически выбирает STA или MTA при создании объекта, чтобы соответствовать типу подразделения вызывающего потока. Это может быть полезно, чтобы избежать накладных расходов на маршалинг, когда к серверам MTA обращается поток STA. |
| Нейтральная квартира потока (NA), (ThreadingModel = Neutral) | Специальная квартира без назначенных потоков. Когда поток STA или MTA вызывает объект NA в том же процессе, вызывающий поток временно покидает свою квартиру и выполняет код непосредственно в NA без переключения потоков. Следовательно, можно рассматривать NA как оптимизацию для эффективных вызовов методов взаимодействия. |
Потоки и объекты, принадлежащие одному апартаменту, подчиняются одним и тем же правилам доступа к потокам. Таким образом, вызовы методов, которые выполняются внутри одной квартиры, выполняются напрямую, без помощи COM. Вызов методов, выполняемых по квартирам, осуществляется через маршаллинг. Это требует использования прокси и заглушек.
Так как COM имеет довольно сложную реализацию, программисты могут быть отвлечены некоторыми "водопроводными" проблемами.
Когда STA инициализируется, он создает скрытое окно, которое используется для маршрутизации сообщений между подразделениями и процессами. Очередь сообщений этого окна должна регулярно «прокачиваться». Эта конструкция известна как «насос сообщений ». В более ранних версиях Windows невыполнение этого требования могло вызвать общесистемные взаимоблокировки. Эта проблема осложняется некоторыми Windows API, которые инициализируют COM как часть своей реализации, что вызывает «утечку» деталей реализации.
Подсчет ссылок в COM может вызвать проблемы, если два или более объекта имеют циклические ссылки. Это необходимо учитывать при разработке приложения, чтобы объекты не остались сиротами. Объекты также могут оставаться с активными счетчиками ссылок, если используется модель «приемника событий» COM. Поскольку объекту, который запускает событие, нужна ссылка на объект, реагирующий на событие, счетчик ссылок последнего никогда не достигнет нуля. Контрольные циклы обычно прерываются с использованием либо внешнего завершения, либо разделения идентификаторов. В технике внеполосного завершения объект предоставляет метод, который при вызове заставляет его отбрасывать ссылки на другие объекты, тем самым прерывая цикл. В методе разделения идентификаторов одна реализация предоставляет два отдельных COM-объекта (также известных как идентификаторы). Это создает слабую ссылку между COM-объектами, предотвращая ссылочный цикл.
Поскольку внутрипроцессные COM-компоненты реализованы в файлах DLL, а регистрация допускает только одну версию для каждого CLSID, они могут в некоторых ситуациях подвергаться «DLL Hell "эффект. Возможность COM без регистрации устраняет эту проблему для внутрипроцессных компонентов; COM без регистрации недоступен для серверов вне процесса.
