Кроссплатформенная розробка 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 не змінюється!

Нова середу розробки Borland Delphi 6 з’явилася зовсім недавно

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

Табл. 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>

*

*