Обновите ArcaOS до уровня NeoWPS Установите набор PNG иконок, нарисованных дизайнером, специализирующемся на оформлении OS/2 Установите eSchemes 2018, чтобы менять цвета и кнопки на рабочем столе

TITLE: Open Sibyl

DATE: 2004-02-26 11:11:24

AUTHOR: Yuri Prokushev

Перед написанием я планировал сделать обзорную статью по результатам работ, но по мере написания возникло много вопросов связанных с проектированием программы. Поэтому данная статья получилась более постановочная. В свете выхода статьи о Sibyl данную можно рассматривать как продолжение ;).

Введение

Известная многим RAD-среда Speed-soft Sibyl фактически прекратила свое существование в 2000 году. При этом небыло никаких официальных заявлений о прекращении разработки. Однако, многие источники поддверждали сей неприятный факт. В то же время объявлися проект Megido, который просуществовал примерно год. Проект базировался на исходных текстах Sibyl и ставил своей целью разработку RAD-среды под Linux. Именно в то время я скачал исходные тексты Sibyl. После выхода Sibyl fix 4 исходный текст был успешно скомпилирован с небольшими изменениями. Исходный текст, появившийся на hobbes успешно мной скомпилирован не был, да и сильно в этом небыло нужды, так как он представлял из себя неполные исходные тексты проекта Medigo.

С появлением исходных текстов RTL, SPCC и IDE встал вопрос о продолжении развития Sibyl. Условно проект получил название OpenSibyl, но нигде заявлен не был. В начале 2002 года команда Netlabs подняла вопрос об переносе исходных текстов на компилятор Virtual Pascal. Причина ясна - это отсутствие исходных текстов компилятора Speed-soft Pascal. Официально проект OpenSibyl начал существовать примерно год назад.

Выбор компилятора

В данном разделе под Delphi понимается язык, а не среда. От термина Object Pascal, используемого в ранних версиях продукта Borland, было решено отказаться, так как существует стандарт языка Object Pascal. Delphi данный стандарт не поддерживает.

Первой проблемой в разработке OpenSibyl стал вопрос о компиляторе. Это повлекло за собой анализ существующих компиляторов и возможности их использования для проекта OpenSibyl. Анализировались следующие компиляторы:

• Virtual Pascal
• TMT Pascal
• Speed Pascal
• GNU Pascal
• Free Pascal

Наиболее предпочтительным претендентом на роль компилятора являлся Virtual Pascal, но долгая задержки в появлении новых версий ставила вопрос о целесообразности выбора его как основы. Базирование на явно "мертвом" продукте выглядело, по меньше мере, глупо и бесперспективно. Кроме того, в компилятор необходимо внести ряд изменений, а для этого нужна поддержка со стороны разработчика. Текущий разработчик Virtual Pascal не выразил никакого интереса к переносу SPCC и IDE, аргументировав отказ тем, что "VPC достаточен для разработки консольных приложений, а GUI приложения меня не интересуют" (цитата по памяти, не дословно). Таким образом, VPC выбыл из списка претендентов.

TMT Pascal практически не рассматривался по той простой причине, что это комерческий продукт и базировать на нем разработку open-source продукта является затруднительным, т.к. разработчики просто не смогут получить к нему доступ (не забываем, что купить за 2$ болванку с почти софтом можно только у нас).

Родной компилятор Sibyl - Speed Pascal - опять же не является альтернативой, так как язык по ряду моментов сильно отличается от языка Delphi, что создает проблемы при использовании кода, разработанного для Delphi. Кроме того, разработка выглядит остановленной.

При первом приближении GNU Pascal казался практически идеальным, но при более внимательном рассмотрении был отброшен. Разработкой непосредственно компилятора занимается небольшая команда из 2-3 человек и компилятор базируется на GNU Compiler Collection. Это вносит ряд проблем, как то проблемы с наличием той или иной версии GCC для OS/2, сложность в расширении компилятора. Однако самой главной причиной явились слабые возможности компилятора. Язык не поддерживается даже на уровне Delphi 2, говорить о таких вещах как классы, интерфейсы просто не имеет смысла. По возможностим компилятор на уровне объектной модели Turbo/Borland Pascal.

После более подробного знакомста с последним и единственным развивающимся на данный момент компилятором под OS/2, Free Pascal, решено было остановиться на нем (справедливости ради отметим возобновление шевеления разработчиков Virtual Pascal). Поддерживает практически все известные мне возможности Delphi. Активно развивается большой командой разработчиков. Имеет как текстовую IDE, в стиле Turbo/Borland Pascal, так и RAD-среду, Lazarus. Под лицензией (L)GPL. Разработчики пинаемы. Поддержкой версии OS/2 занимаются 1-4 человека (зависит от степени занятости заинтересованности).

План работ по Free Pascal

При всех преимуществах Free Pascal имеет и недостатки. Однако, все они относительно легко решаемы. До недавнего времена основным недостатком OS/2 версии являлась слабая поддержка API подсистем OS/2. На данный момент уже поддерживаются CPI, VIO, KBD, MOU, MMPM/2, REXX, PM (практически полностью). Не закончена поддержка TCP/IP (поддерживаются только WinSockets). Полностью отсутствует поддержка SOM/DSOM. Частично поддерживается WPS.

Из нереализованных для OS/2 возможностей компилятора можно отметить: создание нативных (не EMX) приложений, создание динамических библиотек (DLL), поддержка упрощенной линковки (без прописывания ординалов или имен функций), поддержка SOM/DSOM интерфейсов. Все это решается и довольно легко, требуются только временные затраты. Затруднения могут представить только интерфейсы SOM/DSOM.

Таким образом, для полноценного компилятора, обладающего всеми возможностями, присутствующими для других OS, необходимо выполнить следующие работы:

• Поддержка нативной компиляции (используя WASM, WLINK, WLIB, в будущем - встроенный линковщик FPC)
• Поддержка создания DLL
• Поддержка отладчика
• Завершение поддержки TCP/IP, PM и SOM/DSOM API
• Поддержка интерфейсов SOM/DSOM

В качестве дополнений можно назвать более широкую поддержку X11 (поддерживается XLib, GTK/GDK), баз данных и прочих библиотек. Эти работы наиболее тривиальны и не требуют больших усилий.

План работ по библиотеке классов SPCC

Наибольшее число вопросов вызывает библиотека классов SPCC. Следует ли ее использовать или использовать более новую и разработанную под FPC LCL? Следует ли вообще использовать библиотеку такого класса или использовать свою более легкую библиотеку и разработанную под OS/2? Следует ли вообще отказаться от такого под[ода, а полностью базироваться на технологии SOM?

В общем для OS/2 существует несколько типов программ:

• Драйвера (требуют отдельного runtime)
• Консольные приложения
• PM приложения
• SOM приложения

Исходя из этого целесообразно иметь несколько библиотек для каждого из случаев. Для драйверов никаких библиотек, в общем, не требуется, за исключением специфического runtime. Для консольных приложений существует Free Vision. Остаются приложения PM и приложения SOM. Использование библиотеки класса SPCC для приложений SOM вызывает отторжение и внутреннее неприятие. Слишком разная идеология.

В принципе, выплывает предложение иметь две библиотеки. Одну - для PM, и одну - для SOM. Оставим пока вопрос о SOM библиотеке и рассмотрим PM библиотеку.

На данный момент существует три совместимых с VCL библиотеки. Это LCL (плюс FCL) из проекта Lazarus, CLX фирмы Borland и SPCC от Sibyl. Все они имеют ряд недостатков. Библиотека CLX наиболее полно совместима с VCL, но она опубликована под GPL, что не позволяет использовать ее для коммерческих продуктов или продуктов с закрытым исходным текстом. В принципе, иметь ее порт под Sibyl было бы интересно и удобно с точки зрения максимальной совместимости. Другой неплохой библиотекой является LCL. Однако тоже существует ряд проблем, в частности, сильная ориентация на переносимость. Уровень интерфейса с системой основан на Win32 GDI и все остальные приводятся к нему. Библиотека SPCC на данный момент сильно устарела и совместима только с Speed Pascal. Исходя из всего этого ни одна библиотека не дает никаких преимуществ. Тянуть разработку SPCC только исходя из совместимости с существующими Sibyl программами (которых в широком использовании не больше десятка) выглядит пустой тратой сил и времени. LCL черезчур переносима, что накладывает ряд ограничений, а CLX распространяется под черезчур жесткой лицензией. Так какой метод выбрать? Переносить существующую или написать новую?

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

Мне очень интересно ваше мнение по данному вопросу.

Относительно SOM библиотеки. На данный момент я предпочитаю реализовать поддержку интерфейсов и написать emitter для SOM Compiler. Две этих вещи позволят иметь стандартную библиотеку полностью аналогичную присутствующей сейчас в OS/2 Toolkit. Плюс возможность легко получить библиотеку для XWorkplace, MM Classes (как CWMMC, так и IBMMMC) и других. На этом я бы пока закрыл вопрос о SOM

План работ по RAD

Наиболее явным методом получения RAD является портирование существующей среда. В наличии имеются исходнае тексты Sibyl SVDE и Lazarus. В результате будет получена классическая среда, обычное монолитное приложение PM. С моей точки зрения такой подход не оправдан. Не используется ни одна из предоставляемых возможностей OS/2, отсутствие модульности, расширяемости. Проблемы с настройкой под свои предпочтения и нужды. Однако, разработка такого рода IDE довольно хорошо известна и можно использовать много готовых решений.

С другой стороны, наличие SOM позволяет вести разработку на другом, более высоком уровне. Интеграция с WPS, использование возможностей EPM и REXX позволяют более гибко подходить к разработке приложений. Использование классических методов работы с WPS, таких как шаблоны, позволяет работать в привычной среде. Структурно такого типа IDE может быть довольно легко вписана в существующую WPS. Так, например, проект может быть представлен объектом класса базирующегося на WPFolder. Панель компонентов - аналог папки шаблонов (или оригинальная папка шаблонов). Перетаскивание шаблона модуля в папку проекта приводит к добавлению модуля в проект. Аналогично для форм, кнопок, списков и других компонентов.

В качестве приложения

Думая, чем завершить рассуждения на тему, я решил привести информацию о текущем состоянии дел. В основном это касается компилятора Free Pascal.

• Compiltaion targets: EMX, OS/2 (in progress), Odin32 (planned)
• DLL support: Only classic import or via .a lib
• SOM support: Planned via interfaces
• Base API: CPI, VIO, KBD, MOU, MON, PM (mostly finished)
• Extra API: TCPIP (ftpapi, pmwsock), REXX, WarpOverlay!, MMPM/2, unzip, uncgi, x11, gtk, libpng, zlib, tcl, imlib, fpgtk
• Free Vision: mostly works
• Text-mode IDE: mostly works
• Debugger: planned
• PM class library: planned
• RAD: planned

И, как всегда, приглашаю вас на обсуждение проекта и участие в разработке.

Комментарии:

dixie 2004-02-26 13:23:44	Ребята - опишите <внятно> ваткомовское дерево кодогенератора - будет вам компилятор, с исходниками ;) У меня валяется недописанный - как раз в оптимизированной генерации затык. Но Hello, OS/2 говорит умеет :) (Т.е. там парсер asm, совместимый с BP/VP, генератор LX/LE/PE есть).
Stanley 2004-02-26 16:35:35	2 Yuri P.: по поводу участия - готов поучаствовать финансово, если будет внятная перспектива.
stream 2004-02-26 16:58:14	Внятного описания нет. Все, что мы нынче имеем с гуся - "cg\doc\cgdoc.html" и исходники С-компилятора, как самого простого (см. DoCompile() в cgen2.c). Надо смотреть, как и в каком порядке backend вызывает codegen. А уж как он код генерит - это, в принципе, и не важно. Фортран работает, и паскаль сможет. А в каком виде внутреннее представление программы у твоего компилятора делается (через TREEPTR или еще как) - это по барабану, все равно в итоге ты его сам в вызовы CGxxx() разворачиваешь (см. EmitNodes()).
Igor Vaskov 2004-02-26 17:33:43	Полностью поддерживаю идею дописать Pascal к Ваткому. Очень нужный и своевременный проект. Эту идею нужно продвигать в массы. Прежде всего закардонные. Я думаю стоит обратиться с предложением о сотрудничестве к "держателям" Ваткома. IMHO Скайтех?
Yuri Prokushev 2004-02-26 18:40:40	2dixie: Попробуй обратиться с Michal Necasek (MichalN_at_prodigy.net). Он вполне пинабельный (не всегда, правда, но есть такое). Он один из активных разработчиков ваткома.. Если будет паскаль должного уровня на ваткомовских тулзах - мне нафиг не будет нужен fpc (если паскаль будет более или менее на том же уровне). Мне, на самом деле, без разницы, под какой паскаль писать эмитер. Он будет просто слегка различаться. Но писать под интерфейсы, а не под классы - это более логично и проще, т.к. интерфейсы специально создавались под COM/CORBA. Можно ведь и вообще без классов обойтись, но хотелось бы использовать нативные вещи. Кроме того, базироваться на чем-то типа VP - заранее ставить себя в зависимость от состояния данного проекта. Загнется он, загнется половина разработок. Сильно уж стали реализации паскаля отличаться. А стандарты есть только на Classic Pascal, который о-о-о-чень ограничен. (Кстати, я так понял, что без оптимизации оно уже дишит? Хачу посмотреть!) 2Stanley: Перспектив на данный момент никаких. Я пишу как мне вздумается и в направлении, каком мне вздумается. И так будет продолжаться до тех пор, пока в этом проекте участвую один только я. Будут другие участники - будем работать более четко. Как пример. В самом начале я хотел просто спортировать SPCC/SVDE под FPC/2. Как выяснилось - глухая затея (нет, реализуемая, но сильно уж трудоемкая). Проще оказалось спортировать тот же Lazarus. Но кассическая RAD-среда а-ля Delphi меня не прильщает. Есть сильное желание утянуть под OS/2 паскаль в мир SOM. С клиентской стороны это не представляет большой сложности. С серверной - нет в FPC/2 поддержки тех же DLL (ну некому было написать). Сказать четко, что получится - я не могу. Хочется нечто близкое к BlackBox. Именно поэтому говорить о финансовой стороне пока рано. Мне просто не охота брать на себя и на Netlabs ответственность. 2stream : А можешь с dixie в этом разобраться и наваять доку? Было бы полезно как минимум двум сторонам (OpenWatcom Team и dixie). Также был бы определенный интерес со стороны osFree Team, т.к. ватком там базовый компайлер. 2Igor Vaskov: С точки зрения поддержки SOM и создания SOM-based среды разработки (не только для паскаля) это монописуально. Но иметь единую среду с неконфликтующими утилитами - это однозначно большой плюс. Вообще, для меня также представляет интерес прикрутка SOM к Watcom. Правда, это выливается в клонирование SC (SOM Compiler), но весь emitter framework документирован, так что с этой стороны проблем быть не должно. Вообще, нужна не closed-source среда для разработки SOM-приложений. Watcom может им стать, если он станет практически полной заменой Toolkit.
dixie 2004-02-26 19:09:35	Не, трансляция кода пока не полностью не дышит :( Дышит только прямая трансляция asm->exe, т.е: {$NOSYSTEM} begin asm call DosPutMessage end; end;
Yuri Prokushev 2004-02-26 20:40:17	2dixie: "... не полностью не дышит..." ;)
ErOs2 2004-02-26 21:29:41	Объясните убогому - нафига нужен SOM? Он что, предоставляет какие-то полезные функции/библиотеки? Типа как например STL? Зачем приложению юзать SOM? Интеграция с WPS? Я как-то по молодости пытался писать расширитель WPS (типа XWP) но бросил это дело из-за почти абсолютной невозможности расширить существующие WPS-объекты. Я тогда тоже думал, ага, объекная ориентация, счас пару методов у фолдера переопределю... Не тут-то было... То как делает это XWorkplace - это огромная работа, Ульрих заменил же практически все классы... XWP - это один большой хак, я вообще удивляюсь как оно работает. Бимеров за такой SOM убить надо. Впрочем, их много за что убить надо. Буду рад если окажусь неправ. (Насчёт SOM, бимеров убить надо полюбому) :)
Validator 2004-02-27 04:04:18	ErOs2: надевай каску, счас бить будут ;-)
Yuri Prokushev 2004-02-27 06:34:43	2ErOs2: Бимеров убить надо за WPS. Давайте не будем путать птиц с курицами. То, что курица не летает - еще не значит, что она не птица. А теперь давайте посмотрим на такую стуацию: написал человек программу. Скомпилировал и успешно про нее забыл. Что делать дальше? Глюки, если они есть , не исправить, функциональности не добавить. Все. Конец. Явный пример - тот же Sibyl. SOM позволяет продолжать развивать такой продукт дальше. Тот же пример привел ты - WPS.. Кстати, из "хаков" там - это создание подкласса оконных функций. Действительно, с точки зрения WPS - это хак, причем грубый. По поводу замены всех классов. Ну не переписаны они. Расширены и _объекты_ заменены. Вопрос - зачем нужен SOM? Ответ - писать _компоненты_ приложения. Полезные функции? Независимость от реализации, распределенность вычислений, масштабируемость. Библиотеки? Да пожалуйста. По принципу - один написал - другой использовал. Без необходимости портирования с компилятора в компилятор, из языка в язык. Зачем юзать SOM? Чтобы обеспечивать гибкость при малых затратах. Интеграция с WPS - один из вариантов. Вообще, почему все нынешние продукты используют CORBA и ее аналоги повсеместно и широко? Накой, спрашивается, ее реализуют все, кому не лень? Я считаю, что _главное_ достоинство SOM - это расширяемость, объектность и независимость от языка. То, что именно в WPS классы не имеют методов, которые необходимы тому или иному программисту еще ничего не говорит. Любоаябиблиотека классов страдает такой ситуацией.
Yuri Prokushev 2004-02-27 06:47:17	[url] Джосеф лучше, чем я, объясняет, зачем и что есть SOM .

Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).

Ваше имя: Ваш E-Mail: CODE:
Ваш комментарий:

Для eComStation 2.0 были созданы виджеты (индикаторы разной информации) + новые элементы управления. Пользоваться системой стало еще удобнее. Что нового в eCS 2.0?