Перекомпиляция старых программ для AmigaOS 4

Если у вас сохранились старые программы на языке Си, какие-то остатки славных дел минувших лет, вы можете легко переписать их для AmigaOne и AmigaOS 4. Большинство моих экспериментов относятся к компиляторам SAS 6.5x и Storm C (содержащем GCC). Нижеследующие советы помогут вам осуществить успешную конверсию ваших программ:

1. Файлы заголовков (headers)

а) Заголовки Clibs, Pragmas, Proto
Эти заголовочные файлы, содержат в основном описатели структур для разделяемых библиотек AmigaOS и т.п. данные. В некоторых своих исходниках, вы могли подключать файлы форматов Clib и Pragma.
Например:

#include <clib/exec_protos.h>
#include <pragmas/exec_pragmas.h>

GadtoolsBox также иногда пишет заголовочные файлы в этих форматах. Однако, они могут оказаться не полностью компилируемыми в GCC под AmigaOS 4. От вас же, может потребоваться замена подключаемых файлов на их аналоги формата proto.
Например:

#include <proto/exec.h>

Таким образом, вы сможете переопределить все имеющиеся у вас заголовочные файлы форматов clib и pragma.

б) Inline-файлы
GCC использует Inline-файлы (включая заголовочные файлы формата proto) для доступа к разделяемым библиотекам AmigaOS. Но их не умеет использовать SAS/C.

2. Функции языка Си

а) Объявление функции
Раньше, при написании функций на языке Си, некоторые программисты любили определять аргументы функций в различных строках (следствие отсутствия строгого стандарта).
Например:

myFunction(num1, num2, string1)
int num1, num2;
char *string1;
{

}

Сейчас такая запись не соответствует стандарту ANSI C. Функция myFunction (из примера), будет возвращать значения типа int или void, которые определяются по разному. Заголовки таких функций должны быть переписаны в однострочные.
Например:

int myFunction(int num1, int num2, char *string1)
{

}

б) Прототипы функций
Существует общепринятая практика объявлять прототипы всех функций в начале программы на языке Си, или в подключаемом заголовочном файле. Если вы имеете несколько файлов Си-программ: добавляйте прототипы в файл заголовка и используйте директиву #include на этот файл изо всех ваших программ. Таким образом, вы обеспечите сквозную целостность вашего проекта. Используйте запись в стандарте ANSI C (см.ниже).
Например:

/* Прототипы */

int myFunction(int num1, int num2, char *string1);

в) Ключевое слово Void
Если в вашей функции не предусмотрены параметры, или она не возвращает никакого значения, всегда используйте ключевое слово void.
Например:

void otherFunction(void)
{
}

г) Параметры и аргументы функции
Когда вы передаёте данные в/из аргументов, убедитесь лишний раз, что используются корректные типы данных. Например, не дай вам бог передать 'long' когда функция ожидает 'int' — получите перегрузку с выдачей сообщений об ошибках. Каждая функция должна предваряться корректным типом, а если тип не указан, то он предполагается целым (int).

void otherFunction(void)
{
      long numa, numb;
      char name[30];
      myFunction(numa, numb, name); /* это ошибка, т.к. numa и numb типа long вместо int */
}

Следовало написать:

void otherFunction(void){
      int numa, numb;
      char name[30];
      myFunction(numa, numb, name); /* вот сейчас - правильно */
}

Функция main() всегда может вернуть целое значение (int). Вы можете завершать её инструкцией 'return 0', показывая таким образом, что именно здесь ваша программа полностью завершается. Также, при необходимости, вы можете использовать аргументы argc и argv, в противном случае пользуйтесь ключевым словом void.

д) Компиляция
Если программа компилируется в SAS/C, запускайте утилиту SCOPTS, нажимайте кнопку 'MESSAGE OPTIONS..' и выставляйте два первых переключателя в положения 'Ansi' и 'Strict' соответственно. Не забудьте там же включить все сообщения об ошибках (если они были выключены ранее). Теперь компилируйте опять. Ваша программа могла использовать старые функции из библиотек поддерживаемых только в SAS/C и не существующих для компиляторов Storm C или GCC. В этом случае, вам придётся заглянуть в SAS/C Manual или C Library Reference, чтобы выявить вызовы функций несовместимых с GCC. Очевидно, что любой вызов функции начинающейся со слов Amigaos, OLD, UNIX или SAS/C должен быть изменён на её ANSI-эквивалент или переписан заново.

Когда ваша программа опять начнёт компилироваться в SAS/C, скопируйте её исходники в другую директорию и компилируйте их уже в GCC/Storm C. Таким образом, вы избавитесь от всех будущих ошибок или сообщений могущих потребовать вашего внимания.

Если использовался ассемблер, то можно перекомпилировать весь код 68K в Phxass, который совместим с форматом ассемблерных исходников "понимаемых" SAS/C. Убедитесь заранее, что вы подключили к вашему проекту все директории содержащие ассемблерные исходники. Если есть такая возможность, перепишите весь ассемблерный код в Си для получения портируемой (на уровне исходников) PPC-программы.

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

е) Сборочные файлы (Makefile)
Сборочные файлы нелегко портировать между компиляторами. В SAS/C вы можете создавать такие файлы используя утилиты smake и Scopts, передавая через опции тип вашего процессора, способ оптимизации и т.п. параметры. В Storm C, файл проекта уже содержит информацию необходимую для его сборки (её можно изменить в любом редакторе текстов). В GCC, вам придётся создавать сборочные файлы вручную или использовать кем-нибудь написанную утилитку для облегчения такого труда.

ё) О попытках выпуска обновлений
Едва ли вы не захотите пойти дальше. Как не скачать некоторые старые амижные программы с Aminet (многие содержат исходники в своих архивах) и не попробовать портировать их под новую систему? Внимательно прочтите файл readme и сопроводительную документацию, прежде чем приступать к такого рода работам. Автор мог возражать против дальнейших обновлений или их распространения без своего согласия. Если вы не уверены в отсутствии препятствий - лучше поищите другой объект приложения усилий.

ж) Об обновлении интерфейсов программ
Amiga предоставляет на выбор множество графических интерфейсов: Inituition, GadTools, MUI, ClassAct, Reaction и многие другие. Если у вас достаточно знаний, почему бы не обновить некоторые программы для использования наиболее развитых GUI (таких как Reaction или MUI)? И тот, и другой поддерживаются в AmigaOS 4. Для Reaction используйте дизайнер интерфейсов Reactor (искать на Amiga Developer CD 2.1 в разделе NDK 3.5). Аналогичная программа MUIBuilder существует для создания интерфейсов под MUI.

Авторские права:
Peter Hutchison
mailto:pjhutch@pcguru.plus.com
http://www.pcguru.plus.com/

Редакция: The IntuitionBase team
Перевод: team PowerAmiga

Опубликовано 30-го Июня 2004 г.


Сайт создан в системе uCoz