Вопросы о новичке о COM

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

Вы можете использовать COM без реестра или подход COM-lite, где вы просто экспортируете фабричные методы, такие как

__ declspec (dllexport) void MyDllCreateFoo (IFoo ** ppFoo);

Пользователи DLL будут вызывать ваша фабрика для создания вашего класса CMyFoo, который реализует IFoo. Что такое DllRegisterServer et. al. do, помимо прочего, позволяет искать CMyFoo и другие классы в реестре.

Q3: Вы правы по сути, если не по духу. Файлы .def и .idl - довольно разные звери. Файлы .def используются только компоновщиком и даже не являются необходимыми - вы можете экспортировать все функции, которые хотите, используя __ declspec (dllexport) void foo () { }

внутри ваш код C ++.

Файлы .idl используются для создания заголовков C ++ (.h), которые включены как в DLL, так и в ее клиенты. Он генерирует интерфейсы и некоторый связующий код, который выполняет такие вещи, как сбор параметров.

Опять же, технически вам не нужно использовать IDL для использования COM, но это может сделать вещи более удобными.

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

Пока что у вас все в точности правильно. Единственное, что я хотел бы прояснить, - это «Классы, реализующие интерфейс IUnknown». Класс представлен объектом, реализующим интерфейс IClassFactory . Вы можете получить такую ​​фабрику классов, вызвав DllGetClassObject в DLL, а затем вы можете попросить фабрику классов создать объект класса. Это похоже на многие другие объектно-ориентированные системы: существует множество объектов, которые представляют классы и могут использоваться для производства экземпляров.

Другие полезные факты о COM:

• Существует небольшая, но сложная библиотека вспомогательных функций, в основном с префиксом Co . Именно они фактически загружают библиотеки DLL, находят экспортируемые функции и вызывают их. Клиентский код обычно не вызывает экспорт DLL напрямую (хотя написать собственную систему хостинга для простых внутрипроцессных COM-объектов довольно просто).
• Существует важный интерфейс IDispatch , который добавляет еще один уровень абстракции, чтобы можно было динамически идентифицировать методы для вызова объекта, используя строку для поиска метода и передавая массив значений аргументов. . Это позволяет языкам сценариев безопасно вызывать COM-объекты (т. Е. Таким образом, чтобы допускать ошибки программиста вместо сбоев).
• Существует более сложная система «маршалинга», позволяющая вызывать объекты из других потоков, других процессов или даже других компьютеров; в своей удаленной (и ориентированной на безопасность) форме он назывался DCOM.Он не имел успеха ни в чем подобном масштабе, как в других случаях использования COM.
• Межпроцессная поддержка была основой OLE2, уловки, которую каждое приложение поспешно поддержало в начале 1990-х, большинство из них неправильно реализовали (очень сложные) интерфейсы, что приводило к сбою.
• Гораздо более успешными оказались элементы управления OLE, которые были технически намного проще (без маршалинга) и предлагали способ расширения Visual Basic.
• Существует по крайней мере одна широко распространенная система, вдохновленная COM, которая несовместима с COM, но разделяет точно такие же концепции (по крайней мере, простые вещи), которая называется XPCOM и является основой веб-браузера Mozilla Firefox.
• Если вы используете COM повсеместно, у вас будет отличный способ интеграции с .NET framework, поскольку он обеспечивает превосходную совместимость с COM. Но вы должны точно следовать правилам COM: AddRef / Release должны работать точно так, как определено, поэтому объект никогда не должен быть уничтожен, пока его счетчик ссылок больше нуля, он должен быть можно использовать QueryInterface , чтобы найти IUnknown из любого интерфейса, а оттуда, чтобы вернуться к исходному интерфейсу, IUnknown , полученный из любого интерфейса, всегда должен иметь тот же адрес памяти на время существования объекта (поэтому его можно использовать для сравнения идентичности).Так, например: не создавайте COM-объекты в стеке и не возвращайте отдельные объекты из QueryInterface (то есть объекты, которые имеют свой собственный QueryInterface , который возвращает разные интерфейсы) .
• Основная проблема с COM заключается в том, что в нем есть как минимум два стандартных способа представления строк. Ни один из них не использует подсчет ссылок. Я не понимаю, почему они никогда не определяли интерфейс IString , но они этого не сделали.
• Вы сойдете с ума, если попытаетесь написать COM-код без интеллектуальных указателей для хранения ссылок или без базового класса, который поможет вам реализовать интерфейсы, например class MyClass: COM :: Object {... )