Кроссплатформенная розробка Kylix 1.0/Delphi 6

Зараз про кроссплатформенной розробці багато говориться в спеціалізованих виданнях. Це нині модно! Але давайте подивимося, що це може дати виробникові програмного забезпечення, і чого це буде йому коштувати.

По-перше, кросплатформний підхід при розробці ПЗ показує, що компанії адекватно реагують на зміни світового ринку, наприклад, зростаючу популярність 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


Це найбільш поширений випадок. Тобто вже існує розроблене ПЗ для Windows, і ви хочете його портувати на Linux. У цьому випадку необхідно впоратися з безліччю обмежень і відмінностей між платформами. Слід визначити, чи варта шкурка вичинки, може дешевше і краще створити окрему версію системи під Linux?


А якщо це дуже дорого? Що тоді робити? Це значною мірою залежить від того, які кошти розробки були використані при створенні вашого ПЗ, активно чи були використані прямі виклики Windows API, чи застосовувалися COM / DCOM / COM +, і, як наслідок цього, ActiveX, ADO і т. п.


Розглянемо засоби розробки:



У загальному випадку, якщо наявне ПЗ створено за допомогою засобів, портування з яких досить важко й дорого, можна порекомендувати замість створення окремої версії для 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.




























Windows



Linux



Windows API, VCL



Qt, glibc та інші системні бібліотеки, CLX



Компоненти COM (включаючи ActiveX)



Не доступно, але є CORBA



Windows Messaging



Qt events



Winsock



BSD Sockets



MAPI, SMTP/POP3, IMAP



Тільки SMTP/POP3, IMAP



DLL бібліотеки



". So" бібліотеки



BDE, ADO



dbExpress

<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 на Windows.


Кроссплатформенная розробка


Ось ми і розглянули основні особливості написання кроссплатформенних проектів. Підсумовуючи вищесказане, я дам короткі, але цілком достатні рекомендації з написання незалежних від платформи або легко переносних програм:



Нижче наведено список 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 Компоненти.


Висновок


Останнім часом стає очевидно, що майбутнє промислової розробки програмного забезпечення за кросплатформним проектами. Тому тим керівникам і розробникам, хто вважає за краще тримати ніс за вітром, слід вже зараз готуватися до прийдешніх змін.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*