Com objects on linux

Why Component Object Model (COM) is not supported on linux. Plz anyone brief me through its technical perspective. I know COM is a standard developed by microsoft but after compilation what are the facts that do not let COM objects run on the Linux environment.

I only have a minute now to discuss this, but basically, *nix doesn’t have any real exact counterpart to the Windows Registry, which is an important although not absolutely needed requirement of COM.

The COM specification is really just a description of how memory should look if an object is built according to its specification. In Linux one could build the object exactly according to the COM specification (using C, C++, or any language that supports use of pointers) and use it in exactly the same manner, but the dynamic loading of the object would have to be done by the client/host without Registry support. All that really means is that the LoadLibrary() part would have to be done by the client, and the exported COM function DllGetClassObject() would also have to be done there too. I have personally done this many times with Windows COM myself, and in fact there is something of a name for it, i.e., ‘Registry Free COM’. This can even be done if the object isn’t even registered with RegSvr32.exe. Perhaps later I’ll have time to elaborate if you have any questions.

@hamzaali906: For heavens sake please stop with the duplicate posting!

Источник

COM-технология и Linux

А в linux’е что-то типа windows’кой COM-технологии есть.

Re: COM-технология и Linux

А что тебе от нее собственно надо в Linux. Как ты ее в обще понимаешь. Ежу ясно, что никто тут (в Linux) писать компоненты для VB не будет 🙂 А в остальном, пиши свои интерфейсы, фабрики, чем ником тебе. Вообще собственно что нужно то, а то вопрос не совсем понятен

Re: COM-технология и Linux

Не знаю как ком ком+ в Линуксе поддерживаются довольно неплохо и даже доки на русском есть. И книги на рынке. если мне неизменяет память то ето что-то близкое k RPC. Под рукой ничего более подробного нет.

Re: COM-технология и Linux

Понятно. Но все же, какие именно задачи он (COM) должен решать в Linux. Ведь в большинстве случаев не обязательно лезть в дебри сложной технологии, биться как говориться в лоб, когда можно найти другое решение, причем не худшее. Я понимаю, что в Linux важен сам принцип COM — отделение реализации от интерфейса. А вот с COM+ . Пока не смотрел что за чудо, нет времени и обхожусь без него вполне, но позже обязательно взгляну, поэтому тут мне сказать нечего

Re: COM-технология и Linux

Есть например Bonobo,
есть еще несколько попыток сделать подобное, каждая реализация используется своим целевым пользователе,
будь то разработчики KDE, GNOME или RH.

Re: COM-технология и Linux

Может, я не правильно вопрос поставил. Или, я неправильно понимаю суть COM-технологии. Короче говоря, меня интересует возможность закатать объект в разделяемую библиотеку.

Re: COM-технология и Linux

По-поводу «отделение реализации от интерфейса»,
рекомендую (в качестве саморекламы 😉 посмотреть
http://root.cern.ch/root/htmldoc/TGuiBuilder.html
Чем тебе не COM 😉

Шаг 2 — набираем «Ctrl-S» и спасаем «интерфейс» в файл qq.C
http://carrot.cern.ch/

Работет (без-воз-мездно, то есть за-даром) как под M$, так и под Linuxом

Re: COM-технология и Linux

Ну тогда всего сказанного вполне достаточно.Пиши интерфейсы и через них работай с объектами.

Re: COM-технология и Linux

>закатать объект в разделяемую библиотеку

Смотри, как это делаем мы:

— получаем из него «разделяемую библиотеку»
Tetris.so для Linux
Tetris.dll для M$
которую можно динамически подгружать

— эта «разделяемая библиотека» содержит всю
информацию об обьекте (чем не COM) Tetris :
все methods, data members etc.

Источник

Портирование COM на Linux

Мне нравится технология COM. Но речь пойдет не о технологии, восхвалении или недостатках COM, а опыте переноса и реализации на Linux. Велосипед? Целесообразность? Давайте не будем на этом заострять внимание.

В общем понимании, объект класса, реализующий как минимум один COM-интерфейс. Реализация объекта в основном скрывается в динамически подключаемой библиотеке, называемой COM-сервер (2) , для использования публикуются и распространяются интерфейсы.

COM-интерфейс, абстрактный класс содержащий только чисто виртуальные функции. Выделяется особый интерфейс IUnknown, любой COM-объект обязан реализовывать данный интерфейс.

Каждый COM-интерфейс должен содержать некий свой идентификатор. В COM он определяется структурой GUID и вот тут столкнемся с первым недостатком COM. GUID непонятен и не читаем ну и все остальное описанное на Wiki. Нам он то же нужен, но в более читаемом и понятном виде (назовем его uiid).

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

Резюме
COM-объект, содержит единственный идентификатор класса. Реализует как минимум один COM-интерфейс — IUnknown (любой COM-интерфейс имеет уникальный идентификатор интерфейса). Разные реализации COM-объекта могут иметь один и тот же идентификатор класса (пример: release и debug версия).

Динамически подключаемой библиотека (для Linux это Shared object — so) реализующая как минимум один COM-объект. Сервер должен экспортировать определенный набор функций:

Создает объект класса по clsuid, увеличивает количество ссылок на so, каждый раз при успешном создании объекта. Вызов IUnknown::AddRef, так же должен увеличивать счетчик ссылок на so, а IUnknown::Release должен уменьшать.

Если количество ссылок на SO равно 0, то можно выгружать библиотеку.

Регистрирует в “реестре” все clsuid сервера. Вызывается единожды при инсталляции COM-сервера.

Удаляет из “реестра” записи о зарегистрированных clsuid сервера. Вызывается единожды при деинсталляции COM-сервера.

Пример SimpleHello, объявляем интерфейс IHello:

Набор макросов скрывает реализации функций, предоставляя более структурированное объявление и логику.

Dom::Implement — скрывает реализацию методов интерфейса IUnknown, добавляет “сахарок”, при объявлении интерфейсов реализуемых объектом (С++11 и variadic templates):

Интерфейс IRegistryServer — определяет набор методов работы с “реестром” COM-серверов.

Важность реестра можно недооценить, но он является наверное главным столпом COM. Microsoft пишет в системный реестр, создает сложную структуру описания интерфейсов и их атрибутов (idl), я пошел немного по другому пути.

В реализации реестр базируется на файловой системе.
Какие плюшки? Понятность, простота, возможность восстановления, особая плюшка при регистрации сервера можно задать некого рода namespace (директорию относительно базового реестра в которой будет регистрироваться объекты сервера), тем самым можно реализовать целостность и версионность приложений использующих технологию.

Из недостатков, возможные проблемы с безопасностью, подмена реализаций объектов.

Как использовать, пример приложения (4)

Для того чтобы заставить все работать потребуется еще небольшая “библиотечка” и небольшая “программка”.

“Библиотечка” — ни что иное как обертка реализующая и собирающая все в единое целое, работу с реестром, загрузку\выгрузку SO, создание объектов.
Она единственная должна быть указана при сборке приложения. Все остальное, “хочется верить”, она сделает сама.

“Программка” — regsrv — собственно это аналог программы Microsoft RegSrv32, выполняющей те же действия (+ возможность указания namespace, + возможность получения списка зарегистрированных clsuid и COM-серверов).

Dom (Dynamic Object Model), моя реализация для Linux.

Источник

OLE, COM, COM+

Обратная разработка программного обеспечения — процедура получения информации об алгоритме. При этом получение этих данных напрямую зависит от того, насколько много есть информации о приложении в документации, и от того, какой использовался способ для создания файла. Всё еще больше усложняется, если алгоритм заимствует фрагменты из других приложений или операционной системы. Эта статья расскажет о механизмах, которые заложены в ОС Windows, благодаря которым процесс обратной разработки может стать весьма сложным процессом.

С чего всё началось

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

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

В операционной системе Windows подход к созданию отдельных компонентов был реализован в предоставлении унифицированных интерфейсов, которыми приложения пользуются и по сей день. Эти интерфейсы называются WinAPI. Их исследование достаточно тривиально, большая часть интерфейсов задокументирована и поэтому их обратная разработка заключается в том, чтобы найти в документации название и прочитать данные о параметрах и возвращаемом значении.

Каждый WinAPI интерфейс позволяет сделать минимальное действие, которое может произвести ОС, то есть если программист решит написать приложение, то для его реализации придётся задействовать несколько сотен, а то и тысяч интерфейсов. Отдельно стоит упомянуть, что это далеко не единственный способ, который доступен в ОС для реализации алгоритмов. ОС Windows также предлагает компонентный подход для построения приложений. Это означает, что программист может объединять целые программы вместе, чтобы реализовать выполнение алгоритма. Возможно это за счет использования механизма Component Object Module.

Появление COM не случайно, реализация этого механизма — логичный этап развития. На схеме ниже можно увидеть ретроспективу создания механизмов в ОС Windows:

Картинка наглядно показывает, как связано появление того или иного механизма. Реализация каждого нового механизма это решение проблем, которые возникли при реализации предыдущего механизма. Картинка включает в себя такие механизмы как OLE, COM+, DCOM, которые тоже, надо сказать очень сложные с точки зрения реализации и изучения.

Некоторые полезные определения

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

COM дает возможность переиспользовать куски приложения. Работает за счет того, что можно собрать исполняемый кусок кода и расположить его в реестре ОС. Кусок кода получит уникальный идентификатор и будет вызывать ОС каждый раз, как приложения будут запрашивать обработку данных по идентификатору. Для создания кода можно использовать любой компилируемый язык программирования.

OLE — механизм связывания и внедрения данных в различные приложения. Больше всего распространен в приложениях, которые используются для офисных задач. Открытие таблицы Excel в документе Word самый распространенный пример использования механизма.

DCOM — механизм, который предоставляет возможность работать с объектами COM в рамках локальной сети или Интернета.

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

Примеры и практика

Давайте попробуем посмотреть, как обозначенные выше механизмы выглядят в ПО при обратной разработке. Начнем с OLE. Как было сказано выше, этот механизм проще всего обнаружить в офисных документах. Попробуем найти такой документ.

Для исследования был выбран вот этот документ. Он представляет собой docx файл, по сути это архив, который содержит некоторое количество файлов с инструкциями, как его рендерить. Заглянем внутрь: в этом формате все данные, которые могут быть добавлены через OLE это файлы, которые расположены в директории «word/embeddings». Заголовок содержимого объекта можно видеть ниже:

Ничего особенно примечательного, такие объекты можно анализировать с использованием набор инструментов oletools.

OLE объект представляет собой файловую систему, в которую можно положить информацию необходимую для встраивания данных. Если воспользоваться инструментом oleobj, то можно увидеть, что внутри объекта находится txt файл. Кстати, это можно увидеть и из шестнадцатеричного редактора:

Объект COM — представление зависит от типа предоставляемого функционала, чаще всего в программном обеспечении используется в совокупности с WinAPI CoCreateInstance. Визуально исследовать объекты можно через относительно простой инструмент — COMView. Пример работы инструмента:

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

Как найти объекты COM+? Если в COMView вы обнаружили объект, который имеет интерфейс IUnknown, перед вами COM+ объект. Например:

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

Статья подготовлена Александром Колесниковым в рамках курса «Reverse-Engineering. Professional». Если интересно узнать больше о программе и формате обучения на этом курсе, приходите на день открытых дверей онлайн, на котором вы также сможете познакомиться с преподавателем.

Источник