Модель компонентных объектов ( COM ) — это стандарт двоичного интерфейса для программных компонентов , представленный Microsoft в 1993 году. Он используется для создания объектов межпроцессного взаимодействия (IPC) в большом количестве языков программирования . 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). [1] Последний реализует лишь часть всего COM-интерфейса. [2] Для некоторых приложений COM был заменен, по крайней мере в некоторой степени , платформой Microsoft .NET и поддержкой веб-служб через Windows Communication Foundation (WCF). Однако COM-объекты можно использовать со всеми языками .NET через .NET COM Interop . Сетевой DCOM использует собственные двоичные форматы , а WCF поощряет использование сообщений SOAP на основе XML . COM очень похож на другие технологии интерфейсов компонентного программного обеспечения , такие как CORBA и Enterprise JavaBeans , хотя каждая из них имеет свои сильные и слабые стороны. В отличие от C++, COM предоставляет стабильный двоичный интерфейс приложения (ABI), который не меняется между выпусками компилятора. [3] Это делает COM-интерфейсы привлекательными для объектно-ориентированных библиотек C++, которые будут использоваться клиентами, скомпилированными с использованием разных версий компилятора.
Одним из первых методов межпроцессного взаимодействия в Windows был динамический обмен данными (DDE), [4] впервые представленный в 1987 году, [5] который позволял отправлять и получать сообщения в так называемых «разговорах» между приложениями. Энтони Уильямс, принимавший участие в создании архитектуры COM, позже распространил в Microsoft два внутренних документа, в которых рассматривалась концепция программных компонентов: « Объектная архитектура: работа с неизвестным (или) типобезопасностью в динамически расширяемой библиотеке классов в 1988 году» и О наследовании: что это значит и как его использовать в 1990 году. Они легли в основу многих идей, лежащих в основе COM. Связывание и внедрение объектов (OLE), первая объектная платформа Microsoft, была построена на основе DDE и разработана специально для составных документов . Он был представлен в Word для Windows и Excel в 1991 году, а позже был включен в Windows, начиная с версии 3.1 в 1992 году. Примером составного документа является электронная таблица , встроенная в документ Word для Windows: по мере внесения изменений в электронную таблицу в Excel они автоматически появляются внутри документа Word.
В 1991 году Microsoft представила расширения Visual Basic (VBX) вместе с Visual Basic 1.0. VBX — это упакованное расширение в виде библиотеки динамической компоновки (DLL), которое позволяет графически размещать объекты в форме и управлять ими с помощью свойств и методов . Позже они были адаптированы для использования другими языками, такими как Visual C++ . В 1992 году, когда была выпущена версия Windows 3.1 , Microsoft выпустила OLE 2 с базовой объектной моделью . Двоичный интерфейс приложения COM (ABI) был таким же, как и MAPI ABI (выпущенный в 1992 году), и, похоже, он был основан на MSRPC и, в конечном итоге, на DCE/RPC Open Group . В то время как 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 . [6]
COM был основной платформой разработки программного обеспечения для Windows и, как таковой, повлиял на развитие ряда вспомогательных технологий. На него также сильно повлияли более ранние технологии.
COM заменил DDE в качестве предпочтительной формы межпроцессного взаимодействия.
В качестве межъязыковой модели компонентов COM полагается на язык определения интерфейса (IDL) для описания объектов и связанных с ними функций. IDL COM в значительной степени основан на многофункциональном IDL DCE/RPC с объектно-ориентированными расширениями. Собственная реализация DCE/RPC от Microsoft, известная как MSRPC, широко используется в качестве основного механизма межпроцессного взаимодействия для служб и внутренних компонентов Windows NT, что делает ее очевидным выбором в качестве основы.
DCOM ( Distributed COM ) расширил возможности COM от простой поддержки одного пользователя с отдельными приложениями, взаимодействующими на рабочем столе Windows, до активации объектов, работающих в разных контекстах безопасности и на разных машинах в сети. При этом были добавлены необходимые функции для настройки того, какие пользователи имеют право создавать, активировать и вызывать объекты, для идентификации вызывающего пользователя, а также указания необходимого шифрования для безопасности вызовов.
Чтобы Microsoft могла предоставить разработчикам поддержку распределенных транзакций , объединения ресурсов, автономных приложений, публикации событий и подписки, лучшего управления памятью и процессором (потоками), а также позиционировать Windows как альтернативу другим операционным системам корпоративного уровня, Microsoft представила технологию под названием Microsoft Transaction Server (MTS) в Windows NT 4. В Windows 2000 это значительное расширение COM было включено в операционную систему (в отличие от серии внешних инструментов, предоставляемых MTS ) и переименовано в COM+ . В то же время Microsoft уменьшила значение DCOM как отдельного объекта. Компоненты, использующие службы COM+, обрабатывались более непосредственно добавленным уровнем COM+, в частности, за счет поддержки перехвата операционной системой. В первом выпуске МТС был добавлен перехват - установка компонента МТС модифицировала реестр Windows для вызова программного обеспечения МТС, а не непосредственно компонента. В Windows 2000 также было изменено приложение панели управления службами компонентов, используемое для настройки компонентов COM+.
Преимущество COM+ заключалось в том, что его можно было запускать в «фермах компонентов». Экземпляры компонента, если они закодированы правильно, могут быть объединены в пул и повторно использованы новыми вызовами его процедуры инициализации без выгрузки его из памяти. Компоненты также могут быть распределены (вызваны с другой машины). COM+ и Microsoft Visual Studio предоставили инструменты, упрощающие создание прокси на стороне клиента, поэтому, хотя для удаленного вызова использовался DCOM, разработчикам было легко это сделать. COM+ также представил механизм событий подписчика/издателя под названием COM+ Events и предоставил новый способ использования MSMQ (технологии, обеспечивающей асинхронный обмен сообщениями между приложениями) с компонентами под названием Queued Components . События 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 путем реализации вызываемой оболочки среды выполнения (RCW). [7] NET-объекты, соответствующие определенным ограничениям интерфейса, могут использоваться в COM-объектах путем вызова вызываемой оболочки COM (CCW). [8] Как со стороны COM, так и со стороны .NET объекты, использующие другую технологию, отображаются как собственные объекты. См. COM-взаимодействие .
WCF (Windows Communication Foundation) упрощает ряд проблем удаленного выполнения COM. Например, это упрощает прозрачную маршализацию объектов по значениям между границами процесса или машины.
Модель программирования и приложений Microsoft Windows Runtime (или WinRT, не путать с Windows RT ) по существу представляет собой API на основе COM, хотя и опирается на расширенный COM. Благодаря своей основе, подобной COM, среда выполнения Windows обеспечивает относительно простой интерфейс с несколькими языками, как и COM, но по сути это неуправляемый собственный API. Однако определения API хранятся в файлах «.winmd», которые закодированы в формате метаданных ECMA 335, том же формате метаданных CLI , который использует .NET, с некоторыми изменениями. Этот общий формат метаданных позволяет значительно снизить накладные расходы, чем P/Invoke, когда WinRT вызывается из приложений .NET, а его синтаксис намного проще.
Nano-COM — это чрезвычайно небольшое подмножество компонентной объектной модели, ориентированное исключительно на аспекты COM, связанные с двоичным интерфейсом приложения (ABI), которые позволяют вызывать функции и методы в независимо скомпилированных модулях/компонентах. Nano-COM можно легко выразить в одном заголовочном файле C++, который можно переносить на все компиляторы C++. Nano-COM расширяет собственный ABI базовой архитектуры команд и ОС, добавляя поддержку ссылок на типизированные объекты (типичные ABI ориентированы только на атомарные типы, структуры, массивы и соглашения о вызове функций). Основа Nano-COM использовалась Mozilla для загрузки Firefox (называемого XPCOM ), и в настоящее время используется в качестве базовой технологии ABI для DirectX / Direct3D / DirectML .
Заголовочный файл Nano-COM определяет или называет как минимум три типа:
dynamic_cast<T>получения новых типов интерфейсов и подсчета ссылок а-ля.shared_ptr<T>.Многие варианты использования Nano-COM также определяют две функции для обращения к буферам памяти, выделенным вызываемому абоненту, в качестве результатов.
Некоторые реализации Nano-COM, такие как Direct3D, избегают функций распределителя и ограничиваются использованием только буферов, выделяемых вызывающей стороной.
В Nano-COM нет понятия классов, квартир, маршалинга, регистрации и т. д. Вместо этого ссылки на объекты просто передаются через границы функций и выделяются с помощью стандартных языковых конструкций (например, нового оператора C++).
Компоненты COM и ActiveX запускаются как собственный код на компьютере пользователя без использования песочницы. Поэтому существует мало ограничений на то, что может делать код. Таким образом , предыдущая практика встраивания компонентов ActiveX в веб-страницы с помощью Internet Explorer приводила к проблемам с заражением вредоносным ПО . Microsoft осознала проблему ActiveX еще в 1996 году, когда Чарльз Фицджеральд сказал: «Мы никогда не заявляли заранее, что ActiveX по своей природе безопасен». [9] Последние [ когда? ] версии Internet Explorer запрашивают у пользователя перед установкой элементов управления ActiveX, что позволяет пользователю запретить установку элементов управления с сайтов, которым пользователь не доверяет. Элементы управления ActiveX подписываются цифровыми подписями , гарантирующими их подлинность. Также можно полностью отключить элементы управления ActiveX или разрешить только некоторые из них. Прозрачная поддержка внепроцессных COM-серверов по-прежнему способствует безопасности программного обеспечения с точки зрения изоляции процессов . Это может быть полезно для разделения подсистем большого приложения на отдельные процессы. Изоляция процессов не позволяет повреждению состояния в одном процессе негативно влиять на целостность других процессов, поскольку они взаимодействуют только через строго определенные интерфейсы. Таким образом, для восстановления допустимого состояния необходимо перезапустить только затронутую подсистему. Это не относится к подсистемам одного и того же процесса, где несанкционированный указатель в одной подсистеме может случайно повредить другие подсистемы.
Программисты COM создают свое программное обеспечение, используя компоненты , поддерживающие COM . Различные типы компонентов идентифицируются идентификаторами классов (CLSID), которые являются глобальными уникальными идентификаторами (GUID). Каждый COM-компонент реализует свою функциональность через один или несколько интерфейсов . Различные интерфейсы, поддерживаемые компонентом, отличаются друг от друга с помощью идентификаторов интерфейсов (IID), которые также являются GUID. COM-интерфейсы имеют привязки к нескольким языкам, таким как C , C++ , Visual Basic , Delphi , Python [10] [11] и нескольким языкам сценариев, реализованным на платформе Windows. Весь доступ к компонентам осуществляется через методы интерфейсов. Это позволяет использовать такие методы, как межпроцессное или даже межкомпьютерное программирование (последнее использует поддержку DCOM).
Все компоненты COM реализуют интерфейс IUnknown ( custom ), который предоставляет методы для подсчета ссылок и преобразования типов (приведения). Пользовательский интерфейс IUnknown состоит из указателя на таблицу виртуальных методов , содержащую список указателей на функции, реализующие функции, объявленные в интерфейсе, в том же порядке, в котором они объявлены в интерфейсе. Таким образом, накладные расходы на внутрипроцессный вызов сравнимы с вызовами виртуальных методов в C++ . Помимо пользовательских интерфейсов, COM также поддерживает интерфейсы диспетчеризации , унаследованные от IDispatch . Интерфейсы диспетчеризации поддерживают позднее связывание для OLE-автоматизации . Это позволяет обеспечить естественный доступ к диспетчерским интерфейсам из более широкого диапазона языков программирования, чем к пользовательским интерфейсам.
Класс 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 достигает своих возможностей в качестве динамической среды для взаимодействия объектов.
Рассмотрим следующий пример определения coclass в IDL:
coclass SomeClass { [по умолчанию] интерфейс ISomeInterface;};Приведенный выше фрагмент кода объявляет COM-класс с именем SomeClass, который реализует интерфейс с именем ISomeInterface.
Это концептуально эквивалентно определению следующего класса C++:
класс SomeClass : public ISomeInterface { ... ... }; где ISomeInterface — это чистый виртуальный класс C++ (иногда называемый абстрактным базовым классом).
Файлы IDL, содержащие интерфейсы и классы COM, компилируются в файлы библиотек типов (TLB), которые позже могут быть проанализированы клиентами во время выполнения, чтобы определить, какие интерфейсы поддерживает объект, и вызвать методы интерфейса объекта.
В C++ экземпляры COM-объектов создаются с помощью CoCreateInstanceфункции, которая принимает идентификатор класса (CLSID) и идентификатор интерфейса (IID) в качестве аргументов. Создание экземпляра SomeClassможет быть реализовано следующим образом:
ISomeInterface * интерфейс_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 (библиотеку активных шаблонов) для разработчиков C++. ATL обеспечивает парадигму разработки COM более высокого уровня. Это также защищает разработчиков клиентских приложений COM от необходимости напрямую поддерживать подсчет ссылок, предоставляя объекты интеллектуальных указателей . Другие библиотеки и языки, поддерживающие COM, включают классы Microsoft Foundation , поддержку COM компилятора VC , [12] VBScript , Visual Basic , ECMAScript ( JavaScript ) и Borland Delphi .
COM — это независимый от языка двоичный стандарт, который можно разработать на любом языке программирования, способном понимать и реализовывать двоично определенные типы данных и интерфейсы. Реализации COM отвечают за вход в среду COM и выход из нее, создание экземпляров COM-объектов и подсчет ссылок, запрос объектов для поддерживаемых интерфейсов, а также обработку ошибок. Компилятор Microsoft Visual C++ поддерживает расширения языка C++ , называемые атрибутами C++ . [13] Эти расширения предназначены для упрощения разработки COM и удаления большей части шаблонного кода , необходимого для реализации COM-серверов на C++. [14]
В Windows классы COM, интерфейсы и библиотеки типов перечислены по GUID в реестре , в разделе HKEY_CLASSES_ROOT\CLSID для классов и HKEY_CLASSES_ROOT\Interface для интерфейсов. Библиотеки COM используют реестр для поиска либо правильных локальных библиотек для каждого COM-объекта, либо сетевого расположения для удаленной службы.
COM без регистрации (RegFree COM) — это технология, представленная в Windows XP , которая позволяет компонентам модели компонентных объектов (COM) хранить метаданные активации и CLSID ( Class ID) для компонента без использования реестра . Вместо этого метаданные и CLSID классов, реализованных в компоненте, объявляются в манифесте сборки (описанном с помощью XML ), который хранится либо как ресурс в исполняемом файле, либо как отдельный файл, установленный вместе с компонентом. [15] Это позволяет устанавливать несколько версий одного и того же компонента в разные каталоги, описываемые их собственными манифестами, а также развертывание XCOPY . [16] Этот метод имеет ограниченную поддержку для серверов EXE COM [17] и не может использоваться для общесистемных компонентов, таких как MDAC , MSXML , DirectX или Internet Explorer .
Во время загрузки приложения загрузчик Windows ищет манифест. [18] Если он присутствует, загрузчик добавляет информацию из него в контекст активации. [16] Когда фабрика классов COM пытается создать экземпляр класса, сначала проверяется контекст активации, чтобы увидеть, можно ли найти реализацию для CLSID. Только если поиск не удался, реестр сканируется. [16]
COM-объекты также можно создавать вручную, учитывая путь к файлу DLL и GUID объекта. Для этого не требуется регистрация DLL или GUID в системном реестре и не используются файлы манифеста. COM DLL экспортирует функцию с именем DllGetClassObject. Вызов DllGetClassObject с нужным GUID и IID_IClassFactory предоставляет экземпляр объекта фабрики . Объект Factory имеет метод CreateInstance, который может создавать экземпляры объекта с учетом GUID интерфейса. [19] Это тот же процесс, который используется внутри компании при создании экземпляров зарегистрированных COM-компонентов. [20]
Если созданный COM-объект создает экземпляр другого COM-объекта с помощью универсального API CoCreateInstance, он попытается сделать это обычным универсальным способом, используя файлы реестра или манифеста. Но он может создавать внутренние объекты (которые могут быть вообще не зарегистрированы) и передавать к ним ссылки на интерфейсы, используя свои собственные знания.
Объекты COM могут быть прозрачно созданы и на них можно ссылаться внутри одного и того же процесса (внутри процесса), за пределами границ процесса (вне процесса) или удаленно по сети (DCOM). Внепроцессные и удаленные объекты используют маршалинг для сериализации вызовов методов и возврата значений через границы процесса или сети. Эта сортировка невидима для клиента, который обращается к объекту, как если бы он был локальным внутрипроцессным объектом.
В COM многопоточность рассматривается с помощью концепции, известной как апартаменты . [21] Отдельный COM-объект находится ровно в одном апартаменте, который может быть однопоточным или многопоточным. В COM существует три типа апартаментов: однопоточные апартаменты (STA) , многопоточные апартаменты (MTA) и нейтрально-потоковые апартаменты (NA). Каждая квартира представляет собой один механизм, посредством которого внутреннее состояние объекта может быть синхронизировано между несколькими потоками. Процесс может состоять из нескольких COM-объектов, некоторые из которых могут использовать STA, а другие — MTA. Все потоки, обращающиеся к COM-объектам, аналогично живут в одном апартаменте. Выбор места для COM-объектов и потоков определяется во время выполнения и не может быть изменен.
Потоки и объекты, принадлежащие одному и тому же подразделению, подчиняются одним и тем же правилам доступа к потокам. Таким образом, вызовы методов, выполняемые внутри одного и того же подразделения, выполняются напрямую, без какой-либо помощи со стороны COM. Вызовы методов, выполняемые между квартирами, достигаются посредством маршалинга. Для этого необходимо использовать прокси и заглушки.
Поскольку COM имеет довольно сложную реализацию, программисты могут отвлекаться на некоторые «сантехнические» проблемы.
Когда STA инициализируется, она создает скрытое окно, которое используется для маршрутизации сообщений между подразделениями и процессами. Очередь сообщений этого окна должна регулярно «накачиваться». Эта конструкция известна как « насос сообщений ». В более ранних версиях Windows невыполнение этого требования могло привести к общесистемным взаимоблокировкам. Эта проблема усложняется тем, что некоторые API-интерфейсы Windows инициализируют COM как часть своей реализации, что приводит к «утечке» деталей реализации.
Подсчет ссылок в COM может вызвать проблемы, если на два или более объектов имеются циклические ссылки . При разработке приложения это необходимо учитывать, чтобы объекты не оставались бесхозными. Объекты также могут оставаться с активными счетчиками ссылок, если используется модель «приемника событий» COM. Поскольку объекту, который запускает событие, необходима ссылка на объект, реагирующий на событие, счетчик ссылок последнего никогда не достигнет нуля. Опорные циклы обычно разрываются с помощью внеполосного завершения или разделения идентификаторов. В методе внеполосного завершения объект предоставляет метод, который при вызове заставляет его удалить ссылки на другие объекты, тем самым разрывая цикл. В методе разделенной идентификации одна реализация предоставляет два отдельных COM-объекта (также известных как идентификаторы). Это создает слабую ссылку между COM-объектами, предотвращая цикл ссылок.
Поскольку внутрипроцессные COM-компоненты реализуются в файлах DLL, а регистрация допускает только одну версию для каждого CLSID, в некоторых ситуациях они могут подвергаться эффекту « DLL Hell ». Возможность COM без регистрации устраняет эту проблему для компонентов, находящихся в процессе обработки; COM без регистрации недоступен для серверов вне процесса.
Если вызов функции CoGetClassObject находит объект класса, который должен быть загружен в DLL, CoGetClassObject использует экспортированную из DLL функцию DllGetClassObject.