IntuitionBaseadminhome
Last updated : 17th Sep 2023 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
User Groups

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
Amigans.net
OS4 Coding
OS4 Depot
AmiNet
Amiga-Look
Amiga Future Magazine

New AmigaOne Systems
AmigaOne X5000
-> Overview
AmigaOne A1222+
-> Overview
-> Specs
AmigaOne 500
-> Overview
AmigaOne X1000
-> Overview
SAM460ex
-> Overview
-> Radeon QuickGuide
-> Make bootable USB/SD QuickGuide
SAM440ep-flex
-> Overview
-> Schematics
-> AmigaOS 4.1 Installation

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
Pegasos II
-> AmigaOS 4.1 Installation
-> SmartFirmware User Manual

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

OS4depot Feed

amiarcadia.lha - emulation/gamesystem
Mar 28, 2024

losmalditosdemo.lha - game/adventure
Mar 26, 2024

libfreetype.lha - development/library/graphics
Mar 25, 2024

ign-addon-ods.lha - office/spreadsheet
Mar 25, 2024

meminfo.lha - utility/hardware
Mar 25, 2024

libsdl2_ttf.lha - development/library/graphics
Mar 24, 2024

thf.lha - game/fps
Mar 24, 2024

amigagpt.lha - network/chat
Mar 24, 2024

liba52.lha - development/library/audio
Mar 23, 2024

libsdl2_mixer.lha - development/library/audio
Mar 23, 2024


Donations
If you appreciate this site please consider to

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-2023 IntuitionBase