Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

Using Object Pascal or RIDL Syntax
Наткнулся как–то на сравнение синтаксисов IDL в Delphi, но не смог докопаться, а как работать с паскалевским–то, ведь Delphi моего патриотизма не оценила и показывала только RIDL. Оказывается, даже в XE2 его нету, в документации к Seattle, наверное, забыли убрать, зато в древней Delphi 2007 можно зайти в Tools » Options » Environment Options » Delphi Options » Type Library, переключить Language в Pascal, после этого обычным File » Open… открыть .tlb и переключиться на вкладку Text.

Понадобилось поизучать одну библиотечку без документации, ибо эта библиотечка может потенциально помочь мне поддерживать бинарные форматы, в которых ВУЗы обязаны посылать сведения в РосОбрНадзор. А библиотечка муторная, и в синтаксисе IDL у меня глаза начинают вытекать, вот я и вернулся к этому вопросу и–таки получил её в паскале–подобном синтаксисе.

Можно посмотреть здесь: 1, 2

С документацией на формат XML дела тоже не заладились. Когда–то документацию можно было скачать с сайта госконторы, которая этот формат и делала, а сейчас на её сайте какая–то хрень, и ничего не найти. И на сайте, куда переехал программный пакет GosInsp, тоже не видать.

@OCTAGRAM:
OCTAGRAM

emitcom: An Emitter of COM Interfaces
Некогда я с Internet Archive понакачал всяких разных .zip, и какие–то из них с документацией к SOM 3.0 Beta, но в формате PostScript, а мне как–то лень было их перекодировать, не думал, что там что–то особо новое найду. Сегодня собрался и–таки нашёл. Мучил меня вопрос, как делать ODdual классы, а конкретно, там указаны ограничения на типы данных, которые допустимы в ODdual классах, но эти типы нигде не объявлены. Я, конечно, могу написать что–нибудь вроде typedef somToken BSTR, но как ctypelib поймёт, что это именно тот BSTR? Все BSTR будут интерпретироваться как UTF-16 строки или есть какой–то .idl для SOM, в котором BSTR объявлен и помечен так, чтобы проецироваться в нужный тип COM? Не меньшее удивление вызывали IUnknown и IDispatch. В состав OpenDoc 2.1.4, по крайней мере, такой IDL не входит, я всё перерыл, а если в бете было ещё одно средство интеграции SOM и COM, то, может быть, и основные типы OLE были объявлены в IDL, который был в составе SOM 3.0 Beta.

@OCTAGRAM:
OCTAGRAM

Установил OpenDoc на Windows 2000, так как на более новых были проблемы это сделать (16–битный InstallShield, например), а формат установочных файлов такой, что не подкопаться. Поизучал. Увидел внутри SOM Collection Classes, правда, под именем odsomuc.dll, а не somuc.dll. Таким образом, до сих пор не найденная SOM 3.0 Beta уже ничего уникального не содержит. Event Manager (somem) нашёлся в SOM 2.1, который я извлёк из VisualAge C++ v3.5 FixPak 9. Коллекции — вот здесь. Вот и всё. Я очень рад, что больше ничего нельзя потерять. Надо, не надо — потом разберёмся, главное, что есть.
Для интеграции между SOM и COM, а также между OpenDoc и OLE применяется утилита ctypelib. При этом вызов DllGetClassObject находится в odole.dll, а некоторые рабочие механизмы — в oddsole.dll, например, я там вижу такие строки, как ISOMObjDispatch, ISOMObjRef, ISOMObjClassFactory. Вот эту систему я бы очень хотел посмотреть в действии. Насколько я понял, сначала мы вызовом sc.exe -sir крафтим из наших .idl, SOM Compiler (sc.exe) и SOM Interface Repository (emitir.dll) файлик .ir. Этот файл по свойствам похож на COM'овский .tlb, но только .tlb неизменен, а .ir редактируем. Затем вызывается ctypelib. ctypelib смотрит переменную среды SOMIR, эта переменная содержит разделённый ; список файлов .ir, среди них должен оказаться и наш файлик, в нём ищется указанный модуль и на основе этой информации создаётся TLB для COM. Если ничего не предпринимать, то вызовы из COM в SOM работают только через IDispatch, но можно пометить свой класс ODdual, приведя его, конечно, в соответствие, и его проекция в COM станет дуальной. Я думал, тут генерятся какие–то C файлы, ан нет, всё в рантайме, похоже. Любопытно.
Есть и признаки того, что пишущие для OpenDoc разработчики не вполне приняли идеологию SOM. При том, что там всё на классах SOM, здесь читаем:
The generally preferred procedure is to create only one SOM class, a subclass of ODPart whose interface contains nothing but your public methods (overrides of the methods of ODPart and its superclasses). That SOM class delegates all of its method calls to a C++ wrapper class, which contains the functionality for the public methods as well as any private fields and methods. Additional classes can be subclasses of your C++ wrapper class.
Казалось бы, зачем заворачивать класс в класс, если уже и так есть класс? Хотел бы я посмотреть на разработчиков под Mac OS X, которые бы в качестве preferred procedure заворачивали так же класс в класс. Кроме тех болезных, конечно, которые портируют уже написанное не–OpenStep приложение. Ещё один аргумент в пользу того, что DTS C++ поздно подоспел. Разработчики как–то не уловили, что SOM — это и есть то, что нужно для классов, и какие–то другие не–SOM классы им не нужны.

По идее, OpenDoc воплощает Open Scripting Architecture, ту самую, что в современной Mac OS X, ну разве что OSAEvents, а не AppleEvents. Правда, на уровне библиотек я так и не увидел, в чём это выражается. Я думал, что OSA — это аналог JSR-223 для нативного кода, но, похоже, это нечто более абстрактное.

@OCTAGRAM:
OCTAGRAM

Novell ComponentGlue
Оказывается, гипотетический мост между SOM и COM не такой уж и гипотетический! Точнее, там не сам COM, а OLE Automation, что тоже весьма интересно. Это расширяет список из 8ми известных мне языков программирования, для которых была прямая поддержка SOM, до практически всех языков программирования, способных делать OLE Automation вызовы.
OpenDoc parts can be incorporated inside as OLE2 application
OLE 2 applications can be included within an OpenDoc application
OpenDoc scripts, which control a component's behavior, can drive OLE 2 components; OLE Automation scripts can drive OpenDoc parts.
Every OpenDoc part is an OLE Control (OCX), which can be used by any OCX tool, such as Microsoft Access.

@plumbum:
plumbum

compuphase.com <compuphase.com> простой терминал с возможностью расширения плагинами.

@lovesan:
lovesan

Такое написал: github.com

Вобщем, библиотечка, основанная на DirectShow, которая позволяет проигрывать аудио. В т.ч. не только из файлов, а скажем и по http.

Библиотечка имеет COM-интерфейс, соответственно, ее можно использовать из разных языков — включены, в частности, CLI-интерфейс на чистом Си, интерфейсы для .NET и для Common Lisp.

love5an.livejournal.com

@sany:
sany

ATL — это пиздец. Представьте, если бы в STL было бы разрешено приведение std::string к char, а взятие адреса из std::string возвращало бы указатель на внутренний массив char.

@OCTAGRAM:
OCTAGRAM

octagram.name

В качестве летней практики накатал сравнение объектных систем (см. теги)

@Proxy-M:
Proxy-M

в boost есть такой замечательный способ работать с серийными портами через Boost.Asio
boost.org
а кто мне скажет как таким же замечательным кросс-платформенным методом получить те самые имена всех доступных портов в системе?

@Macron:
Macron

наверное нужно вечером запилить MTR, а то потери пакетов безумно надоели. Будет хоть что предъявить техподдержке.

P.S. если сотворить com-канал, это меня от них не спасет же?

@lovesan:
lovesan

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

Вот C++

Блять, C++ можно использовать чтобы векторы-матрицы на стеке перемножать(хотя и то, тут лучше на GPGPU что-нибудь). А вот блять для чего-то большего — это получается пиздец.

Вот например, все знают, есть таки штуки как коллбэки, анонимные функции и замыкания. Ну, где-то есть, а в C++ нету. Потому что язык говно и автоматизированного управления памятью в нем нет. И пиздец, полный пиздец выходит, когда надо писать что-то, связанное с концепцией "событий", ну и вообще, асинхронного оповещения чего-либо о чем-либо.
Полный, блять, пиздец.

Самую лучшую вариацию на тему обработки этого острого угла в C++, я видел в COM(Ага, в COM, не в Qt — в Qt совсем говно сраное). Там есть такой концепт как Outgoing interfaces. Это когда мы реализуем какой-то интерфейс, и поставляем указатель на реализацию этого интерфейса нашим объектом какому-нибудь другому объекту, который будет дергать методы нашего интерфейса, типа, когда возникнут какие-либо события.

Но, мало того что вместо одного, блять, ссаного замыкания, мы городим реализацию outgoing COM-интерфейса, так рантайм COM требует вдобавок реализовать кучу сраных обвесок на тему аггрегации и управления памятью(в основном для обхода циклических ссылок — потому что подсчет ссылок, на котором основано управление временем жизни объектов в COM, с ними понятное дело, не справляется) и самому объекту "с событиями", и нам. Короче, пиздец, ад и содомия.

А вообще, когда у меня дело доходит до "событий" в C++, я стараюсь пользоваться старыми добрыми виндовыми очередями сообщений(кстати, обработка событий в DirectShow много где основана именно на них, а не на исходящих интерфейсах, что интересно).

Ну типа, LRESULT CALLBACK HandleMessage(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch(msg) ... }

Гораздо проще и приятнее, чем городить нормальную ОО-архитектуру на C++(последнее все-равно ведь не выйдет, как ни старайся).

@lovesan:
lovesan

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

habrahabr.ru

@KennyHORROR:
KennyHORROR

Мои попытки сделать последнюю долбанную лабу по COM упираются в упорное нежелание этой фигни работать как надо. Пока использовалась DLL всё работало отлично, но стоило мне перенести мой объект в другой процесс как начались проблемы... Уже второй вечер без результатно борюсь с возвратом E_NOINTERFACE. =\

@Zert:
Zert

groups.google.com

@asmer:
asmer

Кто-нить знает, как просниффить отправляемое по \3 \4 в \2?

@VexeR:
VexeR

Повторюсь, но во вменяемое время... Пытаюсь работать с COM-портом. Отправляю строку, возвращается то же самое, как эхо. Вопрос — какого черта? В смысле, дайте пример работающий, что ли... Сам уже задолбался, найденное в гугле все некошерное почему-то. Должна же быть от Жуйка польза)

@lovesan:
lovesan

Рационализация моей работы с COM. Необходимая, наверное, вещь, раз тут один долбоеб уже заикнулся об этом.

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

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

@lovesan:
lovesan

Полтора месяца я ебался с кривым Clozure CL, который поддерживает метаобъектный протокол CLOS через задницу, и то кое-как.

Но, я таки его одолел, и по этому случаю закоммитил в Doors: github.com
Теперь на CCL тоже можно писать COM-компоненты, и дергать COM-интерфейсы и даже целые COM-классы.
Еще я тестировал на clisp и SBCL, там тоже все хорошо работает.

Пример тут, например: github.com
Ясно видна сила MOP — класс hello-world-object является инстансом класса factory-class, а последний является инстансом и одновременно наследником com-class. А все три метаобъекта классов, и все их экземпляры, являются инстансами com-object.
com-обжекты можно дичайше круто передавать в чужой код, и чужой код, на каком-нибудь C++ или C#, будет дергать через виртуальные функции интерфейсов родные лисповые обобщенные фунцкции, которые мы писали на лиспе.

Метаклассы это вообще круто, они дичайше абстрагируют и очень сильно помогают писать меньше кода.

@delayer:
delayer

к вопросу ранее о пробросе com-порта по сети — VSPE (http://www.eterlogic.com/Products.VSPE.html) должно спасти отца русской демократии

@delayer:
delayer

Жуйк, чем можно в винде раздать по сети COM-порт? Биплааатно... С линуксом все понятно — remserial

@Willi:
Willi

есть ли предпотения среди компаний,регистрирующих домены в зоне .com?

@Gem:
Gem

QEMU: не работают порты мультипортовки в гостевой ОС
rsdn.ru