Глава 21. Проблемы переноса приложений
Перенос Windows-приложений в среду Linux
CLX как версия VCL
Отличия CLX от VCL
Команды, компоненты и другие элементы, перенос которых невозможен
Совместимости модулей Kylix и Delphi
Непереносимые возможности
Совместное использование файлов ресурсов Linux и Windows
Различие сред Linux и Windows
Написание переносимого кода
Использование специальных директив
Вывод сообщений
Перенос кода ассемблера в Linux
Сообщения и системные события
Переносимые приложения баз данных
Отличия в dbExpress
Отличия на уровне компонентов
Отличия на уровне интерфейса пользователя
Перенос приложений баз данных в Linux
Обновление данных в приложениях dbExpress
Кроссплатформенные интернет-приложения
Перенос интернет-приложений в среду Linux

Kylix предоставляет возможность разработки так называемых кроссплатформленных (межплатформенных) 32-разрядных приложений, которые могут гать как в среде Linux, так и в Windows. Для этого вы можете выбрать один из двух вариантов:
взять готовое Windows-приложение и модифицировать его с помощью средств Kylix;
создать в среде Kylix новое приложение, следуя рекомендациям, которые представлены в данной главе.

Примечание
Большинство приложений, разработанных для работы в среде Linux (если не используются специфичные для Linux вызовы API), могут после перекомпиляции работать под Windows.

Перенос Windows-приложений в среду Linux
Сложность переноса приложений из одной среды в другую зависит от сложности самого приложения. Если в приложении используются специфичные вызовы функций ядра одной из операционных систем, то перенос значительно затрудняется. Если же вы в своем приложении используете стандартные компоненты CLX, проблемы будут возникать значительно реже.
Итак, для переноса приложения из одной операционной системы в другую вы можете использовать три метода.

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

Межплатформенный перенос. Подразумевает создание кода, который будет работоспособным как в одной, так и в другой операционной системе. В результате, несмотря на достаточную трудоемкость написания кола, получается приложение с единым интерфейсом, но разным содержанием.

Эмулирование среды Windows. Данный метод является наиболее комплексным и дорогостоящим. Однако получившееся приложение для среды Linux будет выглядеть наиболее похожим на переносимое из Windows приложение. Недостатком является низкая скорость выполнения приложения при эмуляции.
Если вы переносите приложение под Linux с целью запускать его только в данной среде, вы можете удалить все специфичные для Windows команды из приложения. Если же вам нужно запускать приложение в обеих средах, вам придется модифицировать код или использовать директиву компилятора $IFDEF для указания блоков кода, специфичных для одной из сред (Linux или Windows).
Перечислим семь главных шагов, которые нужно выполнить для переноса приложения из Windows в Linux:

1. Перенесите все исходные файлы вашего Windows-приложения на компьютер с установленной средой Linux. Исходные файлы должны включать файлы модулей (pas), файл проекта (dpr) и файлы используемых пакете!! (dpk). Кроме того, необходимо перенести файлы, связанные с файлом проекта: файлы форм (dfm), файлы ресурсов (res) и файлы опций проекта (dof). Если вы хотите откомпилировать файл только из командной строки, вам необходим файл конфигурации (cfg).

2. Если вы планируете использование совместных ресурсов для приложении Windows и Linux, переименуйте dfm файлы в файлы xfm, сохранив их названия (например, переименуйте unit I.dfm в unit 1.xfm). Переименуйте ссылки на .dfm файлы в модулях приложения из
{$R .dfm} в ($R .xfm}.

Примечание
Файлы dfm работают в среде Kylix, но после изменения могут и не работать в Delphi.

3. Смените все разделы uses с указанием правильных названий модулей Kylix (см. далее в этой главе).

4. Перепишите код, использующий специфические для Windows процедуры, чтобы сделать приложение более независимым от операционной системы. Сделайте это с помощью встроенных библиотек Kylix.

5. Найдите эквиваленты для команд, которые не поддерживаются в Linux. Используйте директиву компилятора $IFDEF (умеренно) для разграничения кода под Linux и Windows
Например, вы можете для вашего межплатформенного приложения воспользоваться следующим кодом (листинг 21.1):

Листинг 21.1. Использование директивы $IFDEF
//Если среда - Windows
[$IFDEF MSWINDOWS]
IniFile.LoadfromFile('с:\x.txt');
[$ENDIF]
//Если среда - Kylix
[$IFDEF LINUX]
IniFile.LoadfromFile('/home/name/x.txt');
[$ENDIF]

6. Найдите ссылки на пути ко всем файлам проекта:
- укажите правильные пути ко всем файлам Linux;
- смените ссылки на имена дисковых накопителей (например, С:\);
- в местах, где вы указали множество путей, смените разделитель путей с точки с запятой ";" на двоеточие ":";
так как имена файлов являются в Linux чувствительными к регистру, убедитесь, что в приложении все имена файлов записаны правильно.

Примечание
Пути в Linux используют прямой слэш "/" как разделитель (например, /usr/lib). Читатели, которые не знакомы с организацией файловой системы Linux, могут обратиться за краткой информацией в Приложение 3 данной книги.

7. Откомпилируйте проект в Linux. Просмотрите список ошибок, которые укажут, что еще необходимо сделать для того, чтобы ваше приложение работало в среде Linux.

CLX как версия VCL
Kylix использует библиотеку компонентов Borland для создания кроссплатформенных приложений (Borland Component Library for Cross Platform, CLX) вместо библиотеки визуальных компонентов Delphi (Visual Component Library, VCL). В VCL многие оконные компоненты позволяли достаточно просто работать с окнами Windows. В среде Linux CLX обеспечивает доступ к Qt widgets (образовано от двух слов: window - "окно" и gadget - "приспособление") при помощи специальной библиотеки Qt. CLX очень похоже на VCL. Множество компонентов CLX имеют такие же имена, как и в VCL. Многие свойства также имеют одинаковые названия.
Компоненты CLX можно сгруппировать в части, представленные в табл. 21.1.

Таблица 21.1. Части, в которые сгруппированы компоненты CLX

В VisualCLX Widgets используется вместо оконных компонентов VCL. В CLX TWidgetControl используется как TWinControi в VCL. Другие компоненты (такие как TScroiiingwidget) имеют соответствующие имена. Вам не нужно самостоятельно изменять TWinControl на TWidgetControl. В файле ресурсов OControls.pas имеются объявления типов, такие как:

TWinControl = TWidgetControl;

которые предназначены для упрощения использования компонентов разными приложениями. Класс TWidgetControl и все его потомки имеют свойство Handle, которое представляет собой ссылку на объект Qt, а также свойство Hooks, ссылающееся на механизм обработки событий.
Названия модулей и расположение отдельных классов в CLX отличаются от VCL. Вам придется самостоятельно модифицировать разделы uses для исключения модулей, которых нет в Kylix и смены имен на имена модулей Kylix.

Отличия CLX от VCL
Хотя многое в CLX и VCL выполнено одинаково, они имеют некоторые отличия. Рассмотрим их.
Визуальная среда Linux выглядит несколько иначе, чем Windows. Внешний вид диалоговых окон может достаточно сильно отличаться, в зависимости от того, каким менеджером окон вы пользуетесь в Linux (например, KDE или Gnome).
В Linux вы можете использовать свойство TApplication. style для задания внешнего вида приложения (начертания графических элементов).
Можно оставить стиль таким, каким он установлен в Linux, но все же рекомендуется использовать свойство style.
Весь код для работы с вариантным типом данных (variant), который находился в модуле System, в CLX содержится в двух новых модулях:

Variants.pas;
VarUtils.pas .

Таким образом, если вы хотите использовать в своем приложении вариантные переменные, не забудьте добавить в раздел uses модуль variants.
Среда Linux не использует для хранения информации о текущей конфигурации системы системный реестр. Вместо него вы можете применять текстовые файлы конфигураций и переменные среды для получения такого же эффекта, как при работе с системным реестром Windows. Системные конфигурационные файлы в Linux часто находятся в каталоге /etc, например /etc/hosts. Кроме того, можно сохранять информацию в файлах инициализации ini как и в Windows. Есть лишь одно отличие: вам нужно использовать для работы с файлами инициализации объект TMeminiFile вместо TreginiFile, применяемого в Windows.
Нажатие клавиши <Enter> не имитирует событие щелчка кнопки мыши, как это происходит в Delphi.
Компонент TColorDialog не имеет свойства TColorDialog.options. Таким образом, вы не можете настроить работу и функциональность диалога выбора. Кроме того, TColorDialog не всегда является модальным (модальным называется окно, которое не позволяет пользователю работать с другими окнами, пока не будет закрыто).
Во время выполнения приложения комбинированные списки (TсоmbоВох) работают по-разному в Kylix и Delphi. В Kylix вы можете добавить строку в список, введя нужный текст строки и нажав на клавишу <Enter> для ввода комбинированного списка. Эту опцию можно отключить, установив свойство insertMode в ciNone. Также в Kylix можно добавить пустой (не содержащий строку) элемент списка в комбинированный список. Если вы нажмете и будете удерживать клавишу <> на клавиатуре управления курсором при активном комбинированном списке, то список не остановится на последней строке как в Delphi, а будет прокручиваться опять сверху вниз.
Компонент TCustomEdit не поддерживает Undo, ClearUndo и CanUndo. Но
пользователь приложения может отменить редактирование в поле для ввода TEdit во время работы приложения, нажав правую кнопку мыши над полем для ввода и выбрав в выпадающем меню пункт Undo.
Значение кода клавиши <Enter> при использовании событий onkeydown или ОnКеуup в Windows равно 13. В Linux для этой же клавиши код имеет значение 4100.

Команды, компоненты и другие элементы, перенос которых невозможен
Некоторые специфичные для Windows возможности не могут быть перенесены напрямую в среду Kylix. Такие элементы, как COM, ActiveX, OLE. BDE и ADO недоступны в среде Kylix. В табл. 21.2 перечислены элементы отличающиеся в средах Linux и Windows, а также эквивалентные элементы Kylix, если таковые имеются.

Таблица 21.2. Различие возможностей Delphi и Kylix

В Kylix эквивалентом файлов dll Windows являются файлы библиотек разделяемых объектов so, которые содержат независимый от расположения коя (position-independent code, PIC). Это приводит к следующему:

переменные, которые ссылаются на абсолютные адреса в памяти, недопустимы;
ссылки на глобальную память и вызовы внешних функций должны осуществляться через регистр ЕВХ, значение которого должно сохраняться между вызовами.

Совместимости модулей Kylix и Delphi
Все компоненты и объекты VCL и CLX определены в файлах модулей (pas). Например, вы можете найти описание объекта TObject в модуле system.pas. а описание базового класса TComponent - в модуле classes.pas. Когда вы помещаете объект на форму или используете его внутри своего приложения, имя модуля, который содержит данный компонент, помешается в раздел uses.
позволяет компилятору узнать, какие модули использует ваше приложение при работе.
В табл. 21.3 приведен список модулей Delphi и совместимых с ними модулей Cylix. Некоторые модули Delphi имеются только в новой версии Delphi - Delphi 6.

Таблица 21.3. Совместимые модули Delphi и Kylix

В Kylix имеются два модуля, эквивалентов для которых нет в Delphi. Это модули:

DirSei - отвечает за выбор каталога;
Qstyie - отвечает за графический интерфейс пользователя.

Табл. 21.4 содержит список модулей, которые не поддерживаются средой Kylix, т. к. содержат объекты, специфичные для
среды Windows.

Таблица 21.4. Модули VCL, не поддерживаемые средой Kylix

Непереносимые возможности
При создании объекта CLX с помощью палитры компонентов или написания кода, использующего метод create, компилятор создает экземпляр widget. Этот экземпляр принадлежит данному объекту CLX. Если вы вызываете метод Free для уничтожения объекта CLX или автоматически уничтожаете родительский контейнер, содержащий объект CLX, экземпляр widget данного объекта будет также уничтожен. Эта функция характерна для VCL в приложениях Windows.
Если вы создаете объект CLX с помощью метода create (AHandle), то этот объект не будет иметь в собственности Qt widget. Таким образом, при вызове метода Free будет уничтожен только объект CLX. В VCL Windows это невозможно.

Совместное использование файлов ресурсов Linux и Windows
Если вы хотите, чтобы ваше приложение успешно функционировало и в Windows и в Linux, вы можете распространять ваше приложение с ресурсными файлами, которые необходимы как для одной, так и для другой операционной системы. Для этого вы можете разместить файлы ресурсов на сервере, который является доступным для обеих систем или использовать Samba на
Linux-компьютере для обеспечения доступа к файлам через сеть Microsoft.
Файлы форм (dfm в Delphi) имеют расширение xfm в Kylix. Если вы хотите использовать один и тот же файл формы для Linux и Windows, переименуйте dfm файлы в xfm. Иначе файлы dfm будут изменены средой Linux таким образом, что они не будут функционировать в среде Windows.

Примечание
Переименование файлов принесет результат лишь в том случае, если вы используете Delphi 6, которая поддерживает CLX.

Различие сред Linux и Windows
В табл. 21.5 приводится список отличий сред Linux и Windows.

Таблица 21.5. Отличия Linux и Windows

Написание переносимого кода
Для создания кроссплатформенного приложения следуйте приведенным ниже советам:

сократите вызов специфичных функций API Win32 или Linux или откажитесь от него совсем, используйте вместо этого методы CLX;

устраните конструкции PostMessage и SendMessage внутри приложения;

используйте объект TMemlniFile вместо TreglniFile;

обращайте внимание на регистр символов при наименовании файлов или каталогов;

откажитесь от кода ассемблера TASM (ассемблер GNU не поддерживает синтаксис TASM);

попробуйте написать код, использующий платформонезависимые библиотеки и константы, находящиеся в модулях system, sysutiis и других модулях, одинаковых для обеих платформ.
Приведем пример, который позволяет использовать многобайтные символы для обеих платформ (Windows и Linux). Среда Windows традиционно сопоставляет только два байта каждому многобайтному символу. В Linux многобайтная кодировка символов может содержать намного больше байтов на один символ (до шести байтов в кодировке UTF-8). Обе платформы могут использовать одинаковую кодировку с помощью функции strNextchar, находящейся в модуле Sysutiis. В листинге 21.2 приведен код для среды Windows.

Листинг 21.2. Код для среды Windows
while р^ <> #0 do
begin
if p^ in LeadBytes then
inc(p) ;
inc(p);
end;

Этот код можно преобразовать в платформонезависимый, как показано в листинге 21.3.

Листинг 21.3. Платформонезависимый код
while р^ <> #0 do
begin
if р^ in LeadBytes then
p := StrNextChar (p)
else
inc(p);
end;

Если использование функций библиотек не приводит к работающему решению можно попробовать изолировать специфичный код в блоки SIFDEF. ОДНако постарайтесь ограничить число таких блоков.

Использование специальных директив
Пользование директивы компилятора $IFDEF является достаточно разумным путем для разделения кода Windows и Linux в вашем межплатформенных приложении. Тем не менее, использование директивы $IFDEF делает приложения более трудным для понимания, поэтому старайтесь применять эту директиву как можно реже.
Пользуясь директивой $IFDEF, следуйте нижеприведенным указаниям:

постарайтесь не применять директиву $IFDEF без крайней необходимости. Эта директива применяется в исходном файле только после компиляции;

не используйте директиву SIFDEF в файлах пакетов (dpk). Создателям компонентов нужно разработать два пакета для каждой из платформ без использования директивы SIFDEF;
применяйте директиву SIFDEF MSWINDOWS для проверки того, что приложение запушено в среде Windows. Используйте директиву $IFDEF WIN32 для определения различных Windows-платформ, например 32- и 64-бит-ную версии Windows;

используйте директиву $IFDEF LINUX для проверки того, что приложение запущено в среде Linux;

избегайте в своих приложениях комбинации $IFNDEF/$ELSE. Пользуйтесь положительными тестами ($IFDEF/$ELSE) для лучшего понимания кода;

старайтесь использовать директивы $IFDEF MSWINDOWS и SIFDEF LINUX вместо комбинаций $IFDEF LINUX/$ELSE или $IFDEF MSWINDOWS/$ELSE.
Приведем пример неосторожного обращения с директивой $IFDEFF (листинг21.4).

Листинг21.4. Неправильная работа директивы $IFDEF
{$IFDEF WIN3