Разница между традиционной DLL и COM DLL

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

Если COM для повторного использования компонентов на двоичном уровне, я думаю, что традиционная DLL может добиться того же. Они оба выставляют функции, они оба являются бинарными, и какова точка обращения к COM-подходу?

В настоящее время у меня возникает ощущение, что традиционные методы DLL выставляют методы " плоские", в то время как COM DLL выставляет методы в иерархии " ООП". И способ ООП, кажется, лучший подход. Может ли это быть причиной того, что COM превалирует?

Большое спасибо.

Ответ 1

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

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

Это может быть больше OOPy, COM не поддерживает наследование, потому что OOP настолько сложно получить совместимость на двоичном уровне. Эта проблема требует поддержки во время выполнения, в которую встраивается весь код, таких виртуальных машин, как .NET и Java.

Ответ 2

COM-DLL - это просто DLL с точками входа Com-specific. COM предоставляет фабрикам классов для создания COM-объектов, поэтому должен быть способ получить доступ к одной из фабрик классов, реализованных COM-сервером. Что делает DllGetClassObject. Кроме того, COM DLL является самостоятельной регистрацией: они могут уведомлять Windows о доступных классах и интерфейсах. Точкой входа для регистрации самого DLL является DllRegisterServer.

Есть пара других точек входа, но они расположены вдоль этих линий.

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

Если бы не было стандартизованной точки входа для классов классов, то каждая DLL должна была бы определить свою собственную точку входа и эту информацию нужно было бы поместить в реестр Windows, чтобы инфраструктура COM узнала, как получить доступ каждый класс DLL factory. Нет никаких оснований для дополнительной сложности, так что точка входа также является стандартизированной.

Что касается того, где COM отличается от "C", основное отличие заключается в концепции контрактов. COM поощряет программистов мыслить в терминах абстрактных интерфейсов между модулями, а не в иерархическом, сверху вниз разложении функциональности. Это один вид "ООП", но этот термин слишком свободен, чтобы использовать его много, ИМО. Преимущества контрактного подхода многообразны для сильно типизированных, статически связанных языков, таких как C/С++.

Ответ 3

Думаю, прочитав первую главу Essential COM, у вас будет очень хорошее представление о том, зачем использовать COM.

Чтобы быть простым, COM обеспечивает совместимость на двоичном уровне, независимо от того, какой язык вы использовали, какую версию компилятора вы использовали. Речь идет не о "ООП", вы наверняка могли бы вывести класс С++ из DLL, но они не "бинарно совместимы".

Ответ 4

В Windows много применений. Многие типы библиотечного кода хранятся в DLL. Например, одна из них - это узлы .net, которые представляют собой другой зверь.

COM DLL не лучше, чем "обычная двоичная PE-библиотека", поскольку COM DLL также является простой DLL. Что делает DLL-библиотеку COM DLL, возможно, в дополнение к другим вещам, определенным экспорту, которые соответствуют определенному контракту (сигнатуре) [поисковой записи IUnknown] или даже нескольким типам канонизированных интерфейсов [lookup entry "dual interface" ], которые не позволяют только инстанцирование определенных объектов внутри DLL, но также автоматическое обнаружение сервисов, включая имена функций и типы параметров.

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

Такая гибкость позволила построить целую гигантскую COM-инфраструктуру, включая регистрацию компонентов, DCOM (вызов по сети) и т.д. Это сделало довольно удобным предоставление COM-интерфейсов для компонентов Windows (например, WMI) и офисных компонентов, Многие другие популярные интерфейсы были реализованы выше COM, например ADO.

Все это хорошо, но COM не "превалирует" в любом смысле. COM DLL - это меньшинство DLL. Plain DLL и .NET DLL очень популярны. Microsoft считает, что интерфейсы .net превосходят COM. Многие уроды unix и другие считают, что библиотеки DLL - это плохая идея, поскольку она не предоставляет службы компоновки во время выполнения в том же смысле, что и обычные объекты unix. Несмотря на то, что я разработчик окон, я также считаю, что SOs обеспечивают превосходную альтернативу, и я надеюсь иметь их один раз.

Ответ 5

Если вы хотите узнать о причинах внедрения COM и философии, лежащей в его основе, я настоятельно рекомендую читать От CPP до COM

Ответ 6

Ключевое отличие заключается в том, что COM обеспечивает двоичную совместимость.

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

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

Спецификация COM гарантирует, что интерфейс IUnknown всегда находится в одном и том же месте в DLL, поэтому, даже если объект будет пересмотрен для поддержки дополнительных интерфейсов, метод QueryInterface можно еще безопасно назвать.

Ответ 7

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

COM-дескрипторы

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

COM стал стандартом, потому что, хотя вы можете создать традиционную DLL, которая обрабатывает каждый из вышеперечисленных элементов, вам нужно будет сформулировать ожидаемый контракт при отправке вашей DLL

используя правила COM, эта артикуляция сделана для вас

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

Ответ 8

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

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

Бросьте в IDL и скомпилируйте библиотеку типов в DLL, и у вас есть самоописывающие интерфейсы. С помощью обычных DLL вы должны знать из внешних документов, какие у них есть методы и параметры, которые они принимают.

Стандарт COM также может быть кросс-платформенным. Mac версии Office поддерживают COM, и были реализации для Unix и Unix-подобных систем, хотя они никогда не пользовались популярностью.