IntuitionBaseadminhome
Last updated : 10th Apr 2017 Hardware entries : 395 Software entries : 665

Print options
Printable Version

IntuitionBase Lists
OS4 Commercial SW
OS4 Compatible SW
OS4 Compatible HW
OS4 SW/HW Dealers

Featured Content
Feature Articles
IRC Transcripts
Multimedia Archive
Links

Site Info
Home
About
Contact
Shop
Advertise
Search

Partner Sites
Official AOS4 Website
Official AOS4 Support Fora
Official AOS4 Docs Wiki
Amiga Future Magazine
OS4 Coding
OS4 Depot
AmiNet

New AmigaOne Systems
AmigaOne 500
-> Overview
-> Buy now!
AmigaOne X1000
-> Overview
-> Buy now!
SAM460ex
-> Overview
-> Buy now!
SAM440ep-flex
-> Overview
-> Buy now!

Used AmigaOne Systems
Introduction
Available Operating Systems
Yellow Dog Linux
FAQ
UBoot
CPU Modules
Replacing ROM
AmigaOne G3-SE
-> Overview
-> Pictures
AmigaOne XE
-> Overview
-> Pictures
-> Official Manual
Micro A1
-> Overview
-> uA1-C Specification
-> uA1-C Pictures
-> uA1-C Handbook

About AmigaOS
Introduction
Features
Screenshots
Customisation
Hints and Tips
FAQ
Install FAQ

Donations
If you appreciate this site please consider making a donation, thank you.




blank

Alte Software für AmigaOS4 neu kompilieren

Ein altes C-Program kann durchaus für den AmigaOne und AmigaOS 4 angepaßt werden. Meine Erfahrungen basieren auf SAS/C 6.5x und StormC (GCC-basiert). Um Software zu portieren sollte man sich an die folgenden Tips halten:

1. Header-Dateien

a) Clibs, Pragmas und Proto Header-Dateien
Diese Header-Dateien enthalten hauptsächlich Header für die AmigaOS Libraries usw. In einigen Programmen werden Clib und Pragma Header direkt verwendet:
#include <clib/exec_protos.h>
#include <pragmas/exec_pragmas.h>

GadtoolsBox schreibt manchmal Header in diesem Format. Diese Methode funktioniert nicht vollständig mit GCC auf AmigaOS 4. Man sollte diese Zeilen durch Proto Header ersetzen:
#include <proto/exec.h>

Diese Methode holt selbständig alle nötigen Clib und Pragma Header.

b) Inline Header-Dateien
GCC verwendet die Inline Header-Dateien, um auf die AmigaOS Libraries zuzugreifen, welche automatisch durch die Proto Header in ein Programm eingebunden werden. SAS/C verwendet die Inline Header nicht.

2. C-Functionen

a) Formatierung von Funktionen
In den frühen Tagen wurden Funktionen in C in einem anderen Format geschrieben, welches die Datentypen der Argumente des Funktionsaufrufes in separaten Zeilen definierte:

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

}

Dies entspricht nicht dem modernen ANSI-Format. Bei myFunction wird hier angenommen, daß es entweder int oder void zurückgibt und die Definitionen der Argumente sind separat. Solche Funktions-Köpfe sollten einzeilig umgeschrieben werden:

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

}

b) Prototypen
Gewöhnlich werden entweder am Anfang der C-Dateien oder in einer Header-Datei für sämtliche Funktionen Prototypen deklariert. Wenn man mehrere C-Dateien hat, kann man alle Prototypen in eine Header-Datei setzen und diese dann mittels #include in allen C-Dateien einbinden, um die Konsistenz innerhalb des ganzen Projektes sicherzustellen. Man sollte sich hier wie oben beschrieben an den ANSI-C Standard halten. z.B.
/* Prototypes */

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

c) Void
Wenn keinerlei Parameter übergeben oder zurückgegeben werden, sollte man void benutzen, wo immer es möglich ist:

void otherFunction((void)
{
}

d) Parameter und Argumente
Wenn man Daten als Argumente übergibt, sollte man sich davon überzeugen, daß der korrekte Datentyp verwendet wird. Zum Beispiel sollte man nicht "long" übergeben, wenn die Funktion "int" erwartet, da dies viele Warnungen beim kompilieren ergeben kann. Entweder setzt man den korrekten Datentyp am Anfang der betroffenen Funktion oder man wandelt den Datentyp bei allen Aufrufen um:

void otherFunction(void)
{
      long numa, numb;
      char name[30];
      myFunction(numa, numb, name); /* this will generate warnings as numa,numb are longs not ints */
}

sollte umgeschrieben werden in:

void otherFunction(void){
      int numa, numb;
      char name[30];
      myFunction(numa, numb, name); /* this is now correct */
}

Die Funktion main() sollte immer ein "int" zurückgeben, dazu schreibt man am Ende den Befehl "return 0;" um den fehlerfreien Abschluß des Programms anzuzeigen. Falls benötigt, kann man sich die Kommandozeilen-Argumente argc und argv übergeben lassen; ansonsten kann man auch "void" verwenden.

e) Kompilieren
Wenn das zu portierende Programm für SAS/C geschrieben wurde, startet man SCOPTS und ändert die Stufe der Warnhinweise ("message options") in "ANSI, STRICT". Ebenso sollte man alle Warnungen ("warnings") einschalten (falls welche ausgeschaltet sind). Nun kompiliert man neu. Das Programm verwendet evtl. alte Funktoinen, die nur auf dem SAS/C existieren. Diese existeren nicht in anderen Kompilern wie StromC oder GCC. Funktionen, die nicht mit dem GCC verwendet werden können, sind in der SAS/C-Dokumentation im "User's Guide" unter "C Library Reference" entsprechend gekennzeichnet. Alle Funktionsaufrufe, die mit "AmigaOS", "OLD", "UNIX" oder "SAS/C" gekennzeichnet sind müssen in ihre ANSI-Gegenstücke umgewandelt oder neu geschrieben werden.

Ist das Programm einmal erfolgreich neu kompiliert, kopiert man den Quellcode in ein anderes Verzeichnis und kompiliert es mit GCC/StormC. Dies sollte alle weiteren Fehler oder Warnungen aufzeigen, die weitere Aufmerksamkeit benötigen.

Nutzt man Assembler, kann man 68k-Code mit PhxAss neu kompilieren, was kompatibel mit SAS/C Assembler-Code ist, wenn man das "asm-include" Verzeichnis im Projekt includet, um die Assembler Header-Dateien einzubinden. Wenn möglich, sollte man Assembler-Code in C neu schreiben um die Portabilität auf den PowerPC zu verbessern.

Weiterhin sollte man den Code so anpassen, daß so viele Fehler und Warnungen wie möglich beim kompilieren ausgemerzt werden. So wird es einfacher später den Code zu aktualisieren und man entfernt so potentielle Bugs aus dem Code. Ebenfalls sehr wichtig ist das testen; man sollte sich gute Test-Bedingungen überlegen um alle logischen Fehler zu beseitigen, denn nicht alle diese werden vom Kompiler gefunden.

f) Makefiles
Makefiles sind nicht einfach zwischen zwei verschiedenen Kompilern übertragbar. In SAS/C kann man Makefiles mit "smake" erstellen und mit "SCOPTS" Optionen für den Prozessor-Typ, Optimierung usw erstellen. Bei StormC enthält die Projekt-Datei diese Informationen (lesbar mit einem Text-Editor). Für GCC muß man ein eigenes Makefile schreiben oder mit dem bevorzugten Tool erstellen.

g) Mit Updates experimentieren
Wenn man einfach mal loslegen möchte, kann man ein altes Amiga-Programm aus dem Aminet laden, für das der Quellcode vorliegt. Bevor man jedoch seine Änderungen veröffentlicht sollte man das Readme und die beiliegende Dokumentation lesen. Der Urheber könnte etwas dagegen haben, wenn die eigene Arbeit ohne sein Einverständnis aktualisiert oder weiterverbreitet wird. Falls man sich nicht sicher ist, sollte man besser nichts unternehmen.

h) Upgrade auf neuere GUI APIs
Der Amiga hat den Vorteil einer ganzen Auswahl von GUI-Systemen: Inituition, GadTools, MUI, ClassAct, Reaction und viele andere. Falls man es sich zutraut, kann man auch gerne ein Programm upgraden, sodaß es die neueren GUIs wie Reaction oder MUI nutzt. Beide werden von AmigaOS 4 unterstüztt. Für Reaction steht das Programm Reactor bereit, welches man auf der Amiga Developer CD 2.1 im NDK 3.5 Verzeichnis findet. Für MUI gibt es den MUIBuilder.

Geschrieben von:
Peter Hutchison
pjhutch@pcguru.plus.com
http://www.pcguru.plus.com/

Redigiert vom Intuitionbase-Team
Übersetzt von:
Philippe Bourdin

Published 1st July 2004
©2004-2015 IntuitionBase