Сейчас о кроссплатформенной разработке много говорится в специализированных изданиях. Это нынче модно! Но давайте посмотрим, что это может дать производителю программного обеспечения, и чего это будет ему стоить.
Во-первых, кроссплатформенный подход при разработке ПО показывает, что компании адекватно реагируют на изменения мирового рынка, например, растущую популярность Unix-подобных систем. В частности Linux сейчас позиционируется как полнофункциональная операционная система для рабочих станций, и это действительно так. Например, Linux Mandrake Spring 2001 Russian Edition превосходит Microsoft Windows 2000 Advanced Server не только функционально, но иногда даже по возможностям настройки пользовательского интерфейса. Следует добавить, что в дистрибутив входит обширное серверное и клиентское ПО, софт для разработчиков, KОffice и многое другое. И все это за $14. А сколько стоит Microsoft Windows 2000 Advanced Server? "На митинском рынке все это стоит одинаково!" - возразят поклонники Windows. В последнее время руководство Microsoft относится к Linux как к серьезному конкуренту (это становится очевидным после злобных нападок Стива Балмера). Однако у Windows есть преимущество: для нее написано большинство игр.
Во-вторых, рынок ПО для Unix-систем новый для России, так что здесь существует реальная возможность захватить пальму первенства в некотором сегменте. Предприятия, использующие различные КИС, также задумываются о переносе серверной платформы с Windows на UNIX. И, естественно, они захотят иметь в своем распоряжении системы, работающие на обеих платформах.
"Сколько это будет стоить?" - вот вопрос, ответ на который может оттолкнуть тех, кто задумается о кроссплатформенной разработке. Да, она обходится дороже в 1,3-1,5 раза, а это значит, что следует либо соответственно увеличивать сроки разработки, либо нанимать новых программистов и тестеров. Однако если посмотреть на проблему под другим углом, то становится очевидно, что это дешевле, чем писать различные системы под разные платформы и затем обслуживать их по отдельности. Нельзя также не думать об увеличении числа потенциальных пользователей кроссплатформенного ПО.
Направления кроссплатформенного ПО
К кроссплатформенной разработке можно отнести 3 направления:
- ортирование с Windows на Linux;
- портирование с Linux на Windows;
- кроссплатформенная разработка с нуля.
Портирование с Windows на Linux
Это наиболее распространенный случай. То есть уже существует разработанное ПО для Windows, и вы хотите его портировать на Linux. В этом случае необходимо справиться с множеством ограничений и различий между платформами. Следует определить, стоит ли овчинка выделки, может дешевле и лучше создать отдельную версию системы под Linux?
А если это очень дорого? Что тогда делать? Это в немалой степени зависит от того, какие средства разработки были использованы при создании вашего ПО, активно ли были использованы прямые вызовы Windows API, применялись ли COM/DCOM/COM+, и, как следствие этого, ActiveX, ADO и т. п.
Рассмотрим средства разработки:
- Microsoft Visual C++. К сожалению, программы, написанные с помощью этого средства разработки, очень плохо портируются, так как они используют библиотеку MFC, а также изобилуют прямыми вызовами Windows API и обращениями к библиотеке COM. Хотя Microsoft и утверждает, что с помощью Visual C++ можно легко создавать приложения для Linux, при этом придется не только установить на ваш компьютер необходимые библиотеки, но и учесть то, что MS Visual C++ будет выступать лишь как крутой текстовый редактор. Таким образом, разработчик будет лишен визуальной среды и отброшен по удобству среды разработки на четыре года назад. К тому же, для компиляции все равно потребуются GNU-утилиты. Ведь ни для кого не секрет, что Class Wizard работает только с классами из MFC и их потомками. Кроме того, проверить откомпилированное ПО возможно будет только в системе Linux. Соответственно, возникнут проблемы с тестированием, так как каждый раз необходимо будет перезагружаться и не будет возможности пошаговой отладки. В большинстве случаев, проще создавать ПО для Linux отдельно.
- В Microsoft Visual Basic портирование невозможно, так как он полностью построен на использовании библиотеки COM.
- Microsoft Visual Java. Отличный кандидат на портирование. Следует обеспечить наличие необходимых классов (просто скопировать их) и создать класс ресурсов для KOI-8.
- Borland JBuilder. Проблем никаких, только следует создать класс ресурсов для KOI-8.
- Borland Delphi. Портирование сопряжено с рядом трудностей, но возможно. Предварительно следует конвертировать проект в шестую версию Delphi. Подробно о процессе конвертации с Borland Delphi на Kylix мы поговорим чуть позже.
В общем случае, если имеющееся ПО создано при помощи средств, портирование с которых весьма затруднительно и дорого, можно порекомендовать вместо создания отдельной версии для Linux написать следующую версию программы с нуля с использованием средств, хорошо приспособленных для данных целей, и при этом сразу вести разработку кроссплатформенно.
Портирование с Linux на Windows
В этом случае также имеется множество ограничений и различий между платформами. Но овчинка стоит выделки, так как в результате станет доступной огромная аудитория пользователей Windows. Здесь возникнут аналогичные технические проблемы. В частности, проблемы портирования с KDeveloper C++ на Microsoft Visual C++ те же, что и при обратном процессе.
Кроссплатформенная разработка с нуля
Здесь будет меньше всего трудностей. Однако необходимо строго придерживаться множества требований и ограничений. Для того чтобы обеспечить это, следует выработать четкие стандарты, которые будут оговаривать не только применяемые средства разработки, но и используемые технологии и стандарты.
К счастью, все это реально, так как уже существуют средства разработки, которые предельно облегчают такие задачи. На сегодняшний день это Borland Kylix 1.0/Delphi 6, Borland JBuilder 4 (средство визуальной разработки на Java) и Together 4.2 (средство визуального проектирования на Java и C++). Последние два продукта в данной статье рассматриваться не будут, так как даже их краткое описание требует отдельной публикации. Итак, наиболее современные средства кроссплатформенной разработки - это Borland Kylix 1.0/Delphi 6. Давайте посмотрим, какие возможности и ограничения существуют при создании проектов с их применением.
Общие проблемы и их решение
В любом проекте на Borland Kylix 1.0/Delphi 6 есть классы, которые сильно завязаны на специфику конкретной операционной системы, а есть классы, которые переносятся без проблем. Следовательно, следует локализовать платформозависимые классы и реализовать API между ними и кодом, независящим от платформы. Лучше всего реализовать этот API, используя интерфейсы, но можно обойтись и прокси-классами или набором функций. Кроме того, платформозависимый код лучше сгруппировать по отдельным модулям, которые предоставляют некоторый API. Это позволит нам не только легко переносить платформонезависимый код, но и избавить себя от его модификации при изменении зависящей от платформы части - ведь API не изменяется!
<picture = delphi6.jpg>Новая среда разработки Borland Delphi 6 появилась совсем недавно
<picture = Kylix.jpg> Kylix - это Delphi для Linux!
Еще один способ облегчить себе жизнь состоит в использовании директивы условной компиляции $IFDEF для выделения участков платформозависимого кода.
{$IFDEF MSWINDOWS}
IniFile.LoadFromFile('c:\EasyCASE.ini');
{$ENDIF}
{$IFDEF LINUX}
IniFile.LoadFromFile('/home/sergio/EasyCASE.ini');
{$ENDIF}
Особенностью является и то, что dfm-файлы в Linux имеют расширение xfm. То есть файл Unit.dfm при перенесении в среду Linux должен быть переименован в Unit.xfm, а при переносе обратно он снова должен быть переименован в Unit.dfm.
Портирование с Windows на Linux
Во-первых, следует вынести в отдельные классы (а классы - в отдельные модули) весь код, содержащий обращения к Windows API, библиотеке Microsoft COM/DCOM/COM+, реестру и т. п. Затем следует реализовать независящий от платформы API к этим модулям. Соответственно, обращаться к этим модулям следует только через реализованный вами API. В этом случае проект получается как бы разделенным на две части: легко переносимая часть и часть, зависящая от платформы, работа с которой ведется через реализованный вами переносимый API (например, через интерфейсы и/или прокси-классы). После этого остается только заново реализовать зависящую от платформы часть программы, и будет получена Linux-версия, так как остальная часть программы даже не заметит смену платформы, ведь API не менялось!
Теперь рассмотрим различия между VCL и CLX. Изменились имена многих базовых классов (например, вместо TWinControl появился TwidgetControl). Но это не значит, что придется везде в проекте переименовывать базовые классы, так как для многих классов это уже сделано (например, TWinControl=TWidgetControl). Заменить требуется только имена модулей с VCL на CLX (например, было Uses Controls, а стало Uses QControls).
Некоторые возможности, которые доступны в Windows, недоступны в Linux, другие же доступны, но через другое API. В частности COM, ActiveX, OLE, BDE, ADO не реализованы в Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<Table>Табл. 1. Альтернативные компоненты при кроссплатформенной разработке
Из таблицы видно, что при реализации некоторых возможностей придется попотеть. Кроме того, есть особенности, которые не сразу бросаются в глаза, например, реализация многобайтных кодировок. В Windows традиционно использует двухбайтную кодировку для Unicode. В Linux размер символа в многобайтной кодировке колеблется от 2 до 6 байт. Но на обеих платформах можно использовать функцию StrNextChar из модуля SysUtils. Например, у нас есть следующий код, написанный под Windows:
while p^ <> #0 do
begin
if p^ in LeadBytes then
inc(p);
inc(p);
end;
Его следует заменить на:
while p^ <> #0 do
begin
if p^ in LeadBytes then
p := StrNextChar(p)
else
inc(p);
end;
Этот код будет работать на обеих платформах с любыми кодировками. В Linux нельзя использовать абсолютную адресацию, то есть синтаксис var MyBase : Integer absolute $4067; в Kylix недопустим. Если программа активно использует COM-технологию, то придется отказаться от ее использования, но зато можно использовать технологию CORBA. Что же касается обращений к реестру Windows, то их следует заменить на работу с INI-файлами, которая доступна на обеих платформах.
Портирование с Linux на Windows
В этом случае будет гораздо меньше проблем, особенно если при разработке программного обеспечения было минимизировано использование кода, зависимого от платформы. Таким образом, рекомендации по разделению программы на две части - легко переносимую и зависящую от платформы - справедливы и здесь. Кроме того, актуальны все рекомендации, приведенные в разделе "Общие проблемы и их решение". В первую очередь следует обратить внимание на следующие моменты:
- Использование разных кодировок. Ведь для Linux стандартной кодировкой является KOI-8, а для Windows - cp1251. Простейшим решением в данной ситуации будет использование двух файлов, содержащих строковые ресурсы в соответствующих кодировках. А для их подключения в программе следует использовать директиву условной компиляции $IFDEF.
- Использование прямых вызовов библиотеки Qt. Здесь возможно только одно решение - заменить их на вызовы CLX. Что непросто из-за ее отличия от соответствующей части Windows API.
- При перенесении в среду Windows следует изменить расширение файлов с xfm на dfm.
При грамотном и продуманном подходе не будет проблем с переносом ПО с Linux на Windows.
Кроссплатформенная разработка
Вот мы и рассмотрели основные особенности написания кроссплатформенных проектов. Подытоживая вышесказанное, я дам краткие, но вполне достаточные рекомендации по написанию независящих от платформы или легко переносимых программ:
- Для Windows-программиста лучшим решением будет изначальная реализация проекта в Kylix. Хотя в этом случае он будет ограничен библиотеками, предоставляемыми Borland Kylix, в частности CLX.
- При использовании Delphi 6 для кроссплатформенной разработки нового проекта следует выбрать New / CLX Application и в дальнейшем пользоваться лишь теми компонентами и классами, которые определены в документации как независимые от платформы.
- Разработку собственных компонентов следует вести на основании лишь тех классов, которые определены в документации, как независимые от платформы, то есть классов из CLX.
Ниже приведен список CLX-компонентов, которые можно безболезненно использовать при кроссплатформенной разработке, прочие компоненты следует убрать с палитры компонентов.
[Standart] - Frames, MainMenu, PopupMenu, Label, Edit, Memo, Button, CheckBox, RadioButton, ListBox, ComboBox, ScrollBar, GroupBox, RadioGroup, Panel, ActionList.
[Additional] - BitBtn, SpeedButton, MaskEdit, StringGrid, DrawGrid, Image, Shape, Bevel, ScrollBox, CheckListBox, Splitter, ControlBar, LCDNumber, Timer, PaintBox.
[Common Controls] - abControl, PageControl, ImageList, TrackBar, ProgressBar, TreeView, ListView, HeaderControl, StatusBar, ToolBar, TextViewer, TextBrowser, SpinEdit, IconView.
[Dialogs] - OpenDialog, SaveDialog, FontDialog, ColorDialog, FindDialog, ReplaceDialog.
[Data Access] - DataSource, ClientDataSet, DataSetProvider.
[dbExpress] - SQLConnection, SQLDataSet, SQLQuery, SQLStoredProc, SQLTable, SQLMonitor, SQLClientDataSet.
[Data Controls] - DBGrid, DBNavigator, DBText, DBEdit, DBMemo, DBImage, DBListBox, DBComboBox, DBCheckBox, DBRadioGroup, DBLookupListBox, DBLookupComboBox.
[Internet] - WebDispatcher, PageProducer, DataSetTableProducer, DataSetPageProducer, SQLQueryTableProducer, TCPClient, TCPServer, UDPSocket.
Все Indy Компоненты.
Заключение
В последнее время становится очевидно, что будущее промышленной разработки ПО за кроссплатформенными проектами. Поэтому тем руководителям и разработчикам, кто предпочитает держать нос по ветру, следует уже сейчас готовиться к грядущим переменам.