von Michael Christoph
Das rund 43 MByte große Download-Archiv kann von registrierten Benutzern auf der Webseite von Hyperion Entertainment heruntergeladen werden. Zur Installation wird der »NewInstaller« verwendet, bei dem zuerst die zu installierenden Pakete auszuwählen sind. Weitere Infos gibt es im Kasten »Komponenten im SDK«. Neben dem Basis-Paket, stehen noch weiteres Zubehör für den Compiler und Beispiele zur Verfügung. Für die komplette Installation werden rund 100 MByte auf der Festplatte benötigt. Nach fünf Minuten sind alle Dateien an ihrem Platz und es kann mit dem Compilieren begonnen werden. Es ist auch ein großes SDK-Paket geplant, bei dem noch weitere 3rd-Party-Bibliotheken und Sourcen mit enthalten sein werden. Dieser Artikel wirft einen Blick auf die Version 51.18 des SDK, die ziemlich genau der Auslieferungsversion entsprechen soll. Lediglich die Contributions, also die zusätzlichen Bibliotheken und Includes von Fremdentwicklern standen uns für diesen Bericht noch nicht zur Verfügung. Compiler und Versionen Alle Includes wurden in Hinsicht auf CONST und UBYTE/BYTE/STRPTR überarbeitet. Damit kommt es beim gcc zu keinen Warnungen mehr hinsichtlich unterschiedlicher Datentypen für Zeichenketten. Die Includes haben den aktuellen Stand, der mit dem Preview4-Update von »AmigaOS 4« installiert wurde. Eine Änderung der Versionsnummer hat allerdings bei dem SDK-Update nicht stattgefunden. Hier hilft nur eine Abfrage der version.library, um eine installierte Pre4-Version erkennen zu können. Die Versionsnummer lautet 51.4, während sie bei der Pre3 noch mit 51.1 versehen war. Beim Einsatz ganz neuer Funktionen ist Vorsicht geboten. Alle anderen Entwickler können als Minimalversion die 51 bei OpenLibrary voraussetzen, bzw. deren Vorhandensein zur Laufzeit prüfen. Informationen über das SDK, die Installation und erste Compilierungen finden sich in der Datei »AmigaOS 4.0 SDK«, die im PDF-Format im Downloadarchiv vorhanden ist. Die Datei ist nach der Installation auch im SDK-Basisverzeichnis abgelegt. Recompilieren der alten Sourcen Die Zeit ist aber bei der Standardisierung nicht stehen geblieben und auch neue Techniken sind in die Entwicklung eingeflossen. Diese werden vom gcc sehr streng berücksichtigt. Besonders im Zusamenhang mit Strings kommt es zu Warnungen bei der Verwendung von UBYTE [], STRPTR und char *. Strings sind in der aktuellen Definition von C als char * festgelegt. Hierbei handelt es sich um einen eigenständigen Datentypen, der nicht signed char * und auch nicht unsigned char * ist. Wer hier auf die Commodore-Beispiele als Vorlage vertraut hat, bekommt im aktuellen SDK eine Compiler-Warnung serviert: »pointer targets in initialization differ in signedness«. Wenn Sie als Compiler-Option -signed-char angegeben haben, verschwinden dieses Warnungen – wenigstens teilweise. Schlimmer trifft es aber Programme die in C++ entwicklet wurden. Hier wird statt einer Warnung sofort ein Fehler angezeigt: »invalid conversion from UBYTE*‘ to ‚char*«. In diesem Falle hilft auch keine Option mehr weiter. Hier ist zusätzliche Nachbearbeitung des Codes angesagt, bevor der gcc ein Programm übersetzt.
In Zukunft sollte daher für Text-Arrays der Datentype TEXT verwendet werden. Diesen gibt es zwar schon eine ganze Weile – er wurde in der exec/types.h aber bisher eher stiefmütterlich behandelt. Der Datentype von TEXT stimmt immer mit dem Zeigertyp STRPTR überein und die Zuweisungen lassen sich problemlos vornehmen. Unter C++ wird auch der neue char-Datentyp verwendet, sodass auch hier keine Probleme mehr mit Zuweisungen und Funktionsaufrufen auftreten können. Positiv hervorzuheben ist in diesem Zusammenhang die komplette Überarbeitung der Strukturen und Prototypen im SDK. Hier wird man keine Inkompatibilitäten mehr zwischen UBYTE*, BYTE* und STRPTR finden. Problematisch wird es lediglich, wenn ANSI-C-String-Funktionen mit ins Spiel kommen. Hier kommt char * zum Einsatz, während im normalen C-Modus beim Amiga weiterhin unsigned char * herauskommt. Hier sind Programmierer, die in C++ entwickeln im Vorteil, da STRPTR in den korrekten char *-Typ umgesetzt wird. Zur Sicherheit den Code nachprüfen Wenn es trotzdem zu einem Laufzeitfehler kommt, werden beim Compilieren mit der Option -ggdb viele Informationen (wie Funktionsnamen) in den Code eingebaut. Dieser lässt sich vom Debugger »GDB« auswerten und anzeigen – dazu klickt man einfach im »Grim Reaper« auf den GDB-Knopf. Dort wird auch der Stack angezeigt, also woher der Funktionseinsprung erfolgte. So lässt sich ein Laufzeitfehler recht schnell eingrenzen. Bevor man ein Programm ausliefert, sollte man daran denken, diese Option auszuschalten und stattdessen einen »strip« auf das PPC-Executable auszuführen. Dadurch werden alle unnötigen Daten aus dem Programm entfernt und die Datei wird wesentlich kleiner. lb Informationen: Hyperion Entertainment |
|
Kommentare, Fragen, Korrekturen und Kritik bitte an Webmaster
AMIGA schicken.
Zuletzt aktualisiert am 30.4.2006.