OLE, COM, COM+

[Emelian]

Статья ни о чем. Ни пользы, ни смысла, всем этим заниматься, никакого. Полезных примеров тоже нет. Если вы готовы реверсить бинарный код Windows, особенно в части довольно старой технологии (судя по картинке, 1999 год – последний), то не проще ли найти в Интернете ранее утекшие туда исходники WinNT, Win2003 Server и WinXPsp1? Там все прочитаете открытым текстом.

А есть еще бинарно совместимая с Windows открытая и свободная операционная система ReactOS. Смотрите ее сколько угодно, зачем еще декомпилировать бинарный код и восстанавливать его на Си (соответствующим плагином IdaPro)? Конечно, вы этого не говорили, но это следует из вашей логики.

Я не знаю ни одного реально практического примера, где была бы полезной технология COM. Вот фирма «1С» обожала эту технологию, пока не стала портировать свой продукт под Linux. А все, что есть на эту тему в Интернете – отстой. Поэтому, самый лучший COM, это программирование собственного виртуального интерфейса, для собственных целей, безо всяких GUID'ов и реестров…

[da-nie]

Я не знаю ни одного реально практического примера, где была бы полезной технология COM.

А Direct-X?

[Emelian]

А Direct-X?

Ну, как бы понятно, что M$ изобрела эту технологию для себя. Сама и использует, причем много где. Вот только обычному программисту от этого профита не очень много. Гораздо более эффективен старый добрый опенсорс.

Я лично много раз пытался найти хороший COM сервер, чтобы использовать в собственных проектах. Но все, что доступно, оказалось так себе. Например, в Visual FoxPro отличный движок БД, но ужасный интерфейс. Сами длл-ки этого движка это COM сервера. Казалось бы, бери и работай, тем более, что компилируемые в VFP exe-шники, тоже используют эти сервера. Но нет, открытые интерфейсы вполне себе закрыты, поскольку по ним нет никакой конкретики. Может быть, там нужные GUID'ы секретные или еще что, но достучаться до реальных функций почти невозможно. У меня были кое-какие успехи, но на реальный проект я так и не вышел. В итоге, пришел к выводу, что гораздо более эффективней использовать SQLite тем более, что его можно внедрять в 64-битные приложения.

Другой пример, мультимедиа (плюс веб-броузеры, pdf-ридеры и тому подобное). Да, как бы можно, в своем окне, вывести несжатый avi-ролик, но что-то серьезное фиг кто даст. Мол, покупайте коммерческую версию. Однако, зачем это надо, если есть опенсорсный FFplay.c, который я прекрасно внедрил в собственный проект. Причем, никаких ограничений на кодеки и все такое. И так во всем. Тот же Direct-X тоже. Есть неплохие, более удобные альтернативы, для разных целей.

[kaleman]

Я не знаю ни одного реально практического примера, где была бы полезной технология COM.

Это потому что вы не занимаетесь разработкой под Windows, поэтому и не знаете. Любое технологическое оборудование типа касс, сканеров штрихкодов, весов, турникетов, принтеров и т.д. Просто втыкаете в комп, ставите SDK и через COM моментально получаете доступ к этому железу из скриптов в 1C, Excel, любой ERP. Решение собирается как из кубиков лего моментально. В Линукс так и не сумели создать что-то сопоставимое по удобству использования и технологичности. Даже в 2021 без COM разработчику под Windows никуда.

[Emelian]

Я занимаюсь «разработкой под Windows», но не работаю с технологическим и торговым оборудованием. Как по мне это не разработка, а обслуживание чужих девайсов. Естественно, раз технология существует, то у нее есть применение. Другое дело, что для собственных, достаточно интересных проектов, применения COM я не вижу.

Уже приводил пример с FoxPro9r.dll / FoxPro9t.dll. Это «интересные» COM сервера, но попробуйте поработайте с ними независимо! А вот с SQLite.c / SQLite.h – пожалуйста, проблем нет. И так во всем. А работа с чужим оборудованием, в своих проектах, как-то не греет, хотя, согласен, если за это платят деньги, то может быть полезной. Но, я как раз не это имел в виду. Больше пользы я вижу в опенсорсе, WTL, например. Да, есть еще ATL, для работы с COM’ом, но применения ему я пока, для себя, не нашел.

[OCTAGRAM]

Я не знаю ни одного реально практического примера, где была бы полезной технология COM

У вас часть кода на Аде, часть кода ещё на чём-то. Чем их сопрягать собираетесь?

Разновидности COM встречаются и под Mac OS. Ну не реестр там, по-другому было. Для Linux я видел и в p7zip автономный COM, и VirtualBox XPCOM с возможностью RPC.

[Emelian]

У вас часть кода на Аде, часть кода ещё на чём-то. Чем их сопрягать собираетесь?

Есть два подхода. Первый, вы используете существующие СОМ-сервера для своих целей. Здесь все плохо, использовать особо нечего, по разным причинам. Хотя могут быть какие-то вынужденные варианты, типа драйверов оборудования от производителей, но это не столько разработка, сколько работа с уже готовым ПО. А, второй, это когда вы используете СОМ с нуля для каких-то своих целей, типа приведенного вами примера. Тут ведь нет стандартного решения, правда?

А уж, какую интеграцию вы придумаете для разнородных продуктов, это уже отдельный разговор. СОМ здесь не единственный вариант, причем, чужими серверами воспользоваться маловероятно, а свои делать трудоемко. Когда мне надо было делать транскрибацию видео, то я взял две программы, видео проигрыватель и Эксел, установил их в смежных окнах, и написал скрипт на AHK, который обеспечивал согласованные команды для обеих программ и вполне успешно получил то, что мне было нужно. Да, это решение на скорую руку, но рабочее. Хотя для серьезной работы лучше найти или сделать специализированный продукт.

Разновидности COM встречаются и под Mac OS. Ну не реестр там, по-другому было. Для Linux я видел и в p7zip автономный COM, и VirtualBox XPCOM с возможностью RPC.

Сама идея СОМ, как виртуальных интерфейсов, реализованных на чем угодно, достаточно продуктивная. Другое дело, что СОМ, был изначально заточен на коммерческое использование, расширяющий возможности, относительно dll, бинарной совместимости. Именно это я и имел в виду, когда выказывал свое разочарование данной технологией. За что-либо путное надо платить деньги, а бесплатное, как правило, не стоит выеденного яйца. Но, платить надо тогда, когда нет другой возможности, однако в ИТ отрасли, альтернативных и бесплатных технологий вполне достаточно, особенно для специалистов.

Что касается использования реестра (именно это главная причина неприязни к СОМ), то это нужно не пользователю, а ИТ гигантам, которые рассматривают Интернет и персональные компьютеры как элементы своей собственной глобальной операционной системы, к которой именно монополисты имеют максимальный доступ, а не формальные владельцы компьютеров, ноутбуков, смартфонов и т.п.

[OCTAGRAM]

чужими серверами воспользоваться маловероятно, а свои делать трудоемко

И что там трудоёмкого? Берём и клепаем интерфейс за интерфейсом

[Emelian]

И что там трудоёмкого? Берём и клепаем интерфейс за интерфейсом

Не, ну если делать «вообще», да еще с помощью ATL, то, как бы обозримо. А если «конкретно», для взаимодействия, в данном случае, двух произвольных разнородных программ, то, наверняка, возникнут «нюансы».

[OCTAGRAM]

Тут в соседней ветке пишут:

Я бы добавил, что утечка утечке рознь.

Из моей практики, циклы в структурах, о которых в первую очередь вспоминают, это ничтожная часть всех утечек.

Куда более распространенная в си ситуация связана с «беспорядочной половой жизнью» указателей и спонтанные, неформализованные и нигде не задокументированные контракты владения вида:

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

и т.д.

Притом что во всех случаях интерфейс, утрируя, может выглядеть как void foo(void* ptr).

При таком подходе утечь память, прозевав, кто же все-таки должен ее прибирать, — раз плюнуть.

это одна из болезненных особенностей поддержки плюсового легаси. Рефакторишь на ссылки/смартпоинтеры и сразу дышится легче.

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

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

За что-либо путное надо платить деньги, а бесплатное, как правило, не стоит выеденного яйца.

Ну и что есть путного за деньги?

[piton_nsk]

не проще ли найти в Интернете ранее утекшие туда исходники WinNT, Win2003 Server и WinXPsp1? Там все прочитаете открытым текстом.

Это, мягко говоря, занятие нетривиальное.

Ни пользы, ни смысла, всем этим заниматься, никакого.

Микрософт офис.
Статья, конечно, завлекательная. Но маловато подробностей.

[Emelian]

Это, мягко говоря, занятие нетривиальное.

Не более «нетривиальное», чем «Обратная разработка программного обеспечения», как пишет автор статьи. Вот посмотрите декомпиляцию бинарного кода для простейших программ: erfaren.narod.ru/index.htm. По моему, проще смотреть исходные тексты Windows, найти которые может быть трудно, но можно.

Микрософт офис.

И что вы собираетесь с ним делать, в рамках темы статьи?

[vilgeforce]

И в самом деле воды много, по реверсу мало. В WinAPI все же не интерфейсы, а функции. Первоисточник в лице MSDN так прямо и пишет.

Упомянутый COMView может для чего-то и хорош, но не для реверсинга. Даже на скринах в статье видно, что CLSID в виде нормального имени класса он не показывает. Поиск по IID в нем есть?

Для тех кто хочет подробностей: реверсинг программ с COM начинается с поиска CLSID/IID которые будут использованы. По оным CLSID/IID нужно найти их нормальные имена (гугл в помощь). Затем в IDA в Структурах (Shift+F9) нужно добавить Vtbl'ы для используемых IID, они будут иметь имена типа IUnknownVtbl, для очень многих интерфейсов там уже все есть. Ну а дальше когда будет сто-то типа call [EAX+0x0C] — применяется структура соответствующего интерфейса. IDA даже параметры покажет. Ну и гугл + MSDN чтобы понимать что методы делают.

[OCTAGRAM]

можно сразу разобраться в алгоритме приложения

Да неужели? Все вызовы простого COM — виртуальные, по смещению в таблице виртуальных методов. Таблиц виртуальных методов COM плодит немеряно, плюс, система ещё прокси генерит даже внутри процесса, для разных apartments. Поди разберись, чей седьмой метод хотят вызвать.

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

Да прям там длительный период. COM 1995, DCOM 1996, вот и все основные события. 2 года, а потом внедрение. Это же не Swift, сменивший 5 ABI. COM+ нигде не видел в действии. Из интересного только OLE Automation и .NET интероп было, и потом надолго стабильность. Подвижки случились только в WinRT.

Учитывая, насколько плохо программисты осведомлены хотя бы о том, что есть, к каким-то подвижкам я бы и не призывал. Подвижки нужны в том, чтобы COM и VirtualBox XPCOM (под Linux) библиотеки делали почаще.