Reviews / articles about OS/2 |
Operating systems: ArcaOS, eComStation, IBM OS/2 Warp |
|
|
|
|
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, но долгая задержки в появлении новых версий ставила вопрос о целесообразности выбора его как основы. Базирование на явно "мертвом" продукте выглядело, по меньше мере, глупо и бесперспективно. Кроме того, в компилятор необходимо внести ряд изменений, а для этого нужна поддержка со стороны разработчика. Текущий разработчик 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, необходимо выполнить следующие работы:
В качестве дополнений можно назвать более широкую поддержку X11 (поддерживается XLib, GTK/GDK), баз данных и прочих библиотек. Эти работы наиболее тривиальны и не требуют больших усилий. План работ по библиотеке классов SPCCНаибольшее число вопросов вызывает библиотека классов SPCC. Следует ли ее использовать или использовать более новую и разработанную под FPC LCL? Следует ли вообще использовать библиотеку такого класса или использовать свою более легкую библиотеку и разработанную под OS/2? Следует ли вообще отказаться от такого под[ода, а полностью базироваться на технологии SOM? В общем для OS/2 существует несколько типов программ:
Исходя из этого целесообразно иметь несколько библиотек для каждого из случаев. Для драйверов никаких библиотек, в общем, не требуется, за исключением специфического 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.
И, как всегда, приглашаю вас на обсуждение проекта и участие в разработке.
Комментарии:
|
|
|||||||||||||||||||||||||||||||||
(C) OS2.GURU 2001-2021
