Die Philosophie der Amiga-konformen Software-Entwicklung

Als Hersteller des StormC-Entwicklungssystems haben wir immer die Bestrebung, alle wichtigen Amiga-Entwicklungen mit unserem Entwicklungssystem zu unterstützen. Unsere Philosophie bei unseren Umsetzungen ist es, den Entwicklern ein Werkzeug an die Hand zu geben, das es ermöglicht, mit weitgehend geringem Aufwand die beste Lösung zu erzielen. Einen ersten Schritt in diese Richtung demonstrieren wir mit unserer Entwicklung von StormWIZARD für AmigaOS und p.OS und mit der p.OS-Unterstützung durch StormC. Entwickler, die StormC und StormWIZARD nutzen, haben es sehr einfach mit geringem Aufwand für beide Plattformen ein identisches Erscheinungsbild für ihre Software zu schaffen. Wirtschaftlich betrachtet ist das ein sehr wichtiger Faktor. Aber alternative Betriebssysteme sind nur eine Entwicklungsrichtung und ein neuer Prozessortyp eine ganz andere und wesentlich komplexere Angelegenheit.

In knapp 2-jähriger Entwicklungszeit haben wir den nächsten Schritt vollzogen und eine Hardware-unabhängige PowerPC-Unterstützung fertiggestellt. Die Lösung, mit dem Namen WarpUP wurde am 26.09.97 auf unserer Homepage im Internet und am 28.09. auf dem Amiga-Treffen in Hof der Öffentlichkeit vorgestellt. Die Lösung wurde kurz zuvor, am 26.09. auch bei Phase 5 vorgeführt, denn wir waren und sind der Meinung, hiermit einen wertvollen Beitrag zur Unterstützung der PowerPC-Plattform zu leisten. Bei Phase 5 ist man jedoch offensichtlich nicht dieser Meinung und veröffentlichte am 28.09. ein sehr emotionales Schreiben, in dem die Auflösungen der Zusammenarbeit angekündigt und Lösungen wie WarpUP und StormC als unbrauchbar bezeichnet wurden.

Reaktionen wie diese von Phase 5 sind jedoch sehr unproduktiv. Sie bringen den gerade wieder neu belebten Amiga-Markt durcheinander und helfen weder den Amiga-Firmen noch den Amiga-Anwendern. Die Angriffe seitens Phase 5 gegen unser WarpUP-Paket sind unserer Meinung nach eine unüberlegte Überreaktion. Entgegen der Darstellung durch Phase 5 besteht unser Paket sowohl aus einer zur Phase 5 Lösung kompatiblen als auch aus einer alternativen Lösung. Der Anwender hat hier die Entscheidung, welche Lösung er bevorzugt. Die kompatible Lösung war bei Phase 5 immer bekannt und wurde auch geduldet, um so unverständlicher ist für uns deren angekündigte Absage einer weiteren Unterstützung und die Herstellung einer absichtlichen Inkompatibilität zu unserer Lösung.

Statt dem konsequenten Ausschluß einer Softwarelösung muß dem Anwender die Möglichkeit geboten werden, durch Ausprobieren eigene Erfahrungen zu sammeln und gemeinsam vernünftig über Vor- und Nachteile aller Möglichkeiten zu diskutieren. Wer diese Freiheit verwehrt, zeigt diktatorische Züge mit dem Hintergrund, sich vor Konkurrenz zu schützen.

Wir bieten allen interessierten Anwendern und Entwicklern Einblick in unsere Entwicklung. Das komplette Archiv mit Demoprogrammen, die auch auf einem 68K-Amiga (ab 040er) lauffähig sind und einer bereits vielfach gelobten Dokumentation, die von allen selbst beurteilt werden kann, stellen wir auf unserem FTP-Server kostenfrei zur Verfügung. Unsere Entwicklung zeigt eindrucksvoll, daß keine Notwendigkeit dazu besteht, ein neues Executable-Format oder Verfahren zur dynamischen Anbindung von Bibliotheken zu schaffen. Das Amiga-Betriebssystem bietet seit jeher alle Eigenschaften, die benötigt werden, um neue Prozessortypen zusammen mit oder ohne dem vorhandenen 68K-Prozessor zu nutzen.

Die Hinweise seitens Phase 5 zur Einführung solcher neuen Techniken für neue OS-Versionen müssen Sie als aufmerksamen Leser unverkennbar von deren Absichten überzeugen, in naher Zukunft das AmigaOS durch eine eigene Entwicklung abzulösen. Die Rechte zur Weiterentwicklung des Amiga-Betriebssystems liegen bei Amiga International, die diese mit Sicherheit nicht für eine abweichende Entwicklung aus der Hand geben werden.

Bei allen notwendigen Diskussionen zur Schaffung einer standardisierten PowerPC-Schnittstelle für das AmigaOS darf nie vergessen werden, daß es die Anwender sind, die unseren Amiga am Leben erhalten und keine einzelne Hard- oder Software-Firma. Am Ende der Diskussion muß es also heißen:

"Und die Gewinner sind: Die Amiga-Anwender".

Im folgenden Text finden Sie einen tieferen und technischeren Einblick in den Verlauf unserer Entwicklung von WarpUP und StormC für den PowerPC.

Die Entwicklungsgeschichte von WarpUP

Zur Computer 95 in Köln vor fast zwei Jahren kündigte damals noch Amiga Technologies neue Amiga Modelle auf der Basis von PowerPC-Prozessoren an. Zeitgleich veröffentlichte Phase 5 auch erste Mitteilungen über das Erscheinen von PowerPC-Turboboards für alle bereits im Markt verfügbaren Amiga-Modelle. Für uns war das die Entscheidung, auch unser Entwicklungssystem PowerPC-tauglich zu machen.

Die Entwicklung an StormC-PowerPC begann im März 1996 direkt nach der CeBit. Die Konzepte, die wir uns damals erarbeiteten, sahen vor, so nah wie möglich am Betriebssystem AmigaOS festzuhalten, was kein Problem darstellte. Wir kamen daher nie auf den Gedanken, ein verändertes Executable-Format zu nutzen, schon gar nicht ohne offizielle Entscheidung der damaligen Eigner aller Rechte am Betriebssystem. Unsere Konzeption sah auch vor, schnell auf mögliche Veränderungen im OS und dessen Applikationsschnittstelle reagieren zu können, um den Software-Entwicklern komplizierte Umarbeitungsarbeiten zu ersparen.

Leider geriet Amiga Technologies in dieser Zeit ein zweites Mal ins Straucheln, was sich auch durch die zunächst solvent präsentierte Firma Viscorp nicht veränderte. Ein Beginn der Weiterentwicklung des Betriebssystems und der Bau der lange erwarteten PowerPC-Amigas blieb aus. Ebenfalls ausgeblieben ist daher die Definition der Richtlinien der Schnittstelle für PowerPC-Amiga-Applikationen. Wir ließen uns dennoch nicht beirren und entwickelten Amiga-konform weiter, da unsere Lösung keine Veränderung des bestehenden Betriebssystems voraussetzte.

Durch die Ankündigung von Phase5, ein Dualprozessorboard mit einem 68K und einem PowerPC im parallelen Betrieb zu bauen, ergab sich die dringende Notwendigkeit sogenannte Mixed-Binaries zu unterstützen. Diese Programmform enthält in einem Programm sowohl 68K- wie auch PPC-Code.

Im optimalen Fall ist es für den Entwickler eines Programms völlig irrelevant, welche Teile des Programms in welcher Codeform vorliegen. Der Zugriff auf Daten (z.B. globale Variablen) ist problemlos durch beide Prozessoren möglich, der Wechsel von einem Prozessor auf den anderen geschieht vollautomatisch, ohne zusätzliche Programmierung.

Der Entwickler entscheidet nur, welcher Programmteil sinnvollerweise auf dem PPC arbeitet (z.B. der Raytracer-Kern oder Konvertierungsfunktionen für Graphikformate etc.) und welche Teile in 68K bleiben (z.B. die Ansteuerung der graphischen Benutzeroberfläche). Dabei sollte es auch wenig stören, wenn diese Codeteile eng verzahnt sind, d.h. gemeinsame Variablen und Datenstrukturen benutzen, Rücksprünge aus dem einen Teil in den anderen über sogenannte Funktionspointer erfolgen etc.

Zu unserer Überraschung wählte Phase5 mit der Nutzung des ELF Formats einen Weg, der diese dringend notwendigen (und von Phase5 sogar empfohlenen) Mixed-Binaries zu einer Qual für den Programmierer macht:

• Der PPC Programmteil muß manuell nachgeladen werden;
• Nutzung gemeinsamer globaler Variablen ist nicht möglich;
• Datenstrukturen werden von den gängigen 68K Compilern anders interpretiert als vom GNU-C für PPC und können deshalb nicht gemeinsam genutzt werden;
• Rücksprünge über Funktionspointer oder auch normale Wechsel von einer CPU auf die andere müssen manuell programmiert werden.

Alles in allem ist es ein sehr langer Weg, ein existierendes AmigaOS Programm auf die Phase5 Lösung zu portieren. Nicht umsonst konnte - trotz fast einjähriger Vorlaufzeit mit Hilfe der speziellen PPC-Developerboards, die an einige ausgesuchte Entwickler vergeben wurden - bislang keine größere Applikation portiert werden.

WarpOS und StormC erreichen jedoch nach nun fast 18-monatiger Entwicklungszeit genau diese optimale Strategie der Erstellung von Mixed-Binaries. Der Entwickler zerlegt sein Programm in einen 68K- und einen PowerPC-Teil, im einfachsten Fall durch Einteilung der Programmodule (C-Quelltexte) in die jeweilige Kategorie, im aufwendigsten Fall durch Zerlegung einzelner Programmodule in jeweils zwei neue (für 68K- und PPC-Code). Dann muß nur noch neu kompilieren werden und schon hat man das fertige Programm. StormC und StormLink übernehmen den ganzen Rest. Aus den 68K- und PPC-Teilen wird ein einziges Executable erzeugt, d.h. ein Nachladen der PPC-Programteile entfällt. Durch den gemeinsamen Zugriff auf globale Variablen und die kompatible Interpetation der Datenstrukturen durch den 68K- und PPC-Code muß am Quelltext nicht eine Zeile geändert werden. Kontextwechsel von einer auf die andere CPU werden vollautomatisch generiert, der Programmierer muß nicht einmal wissen, wo genau dieser Kontextwechsel stattfindet.

Mitte Oktober vergangenen Jahres war es dann soweit. Phase 5 überließ uns zwei PowerPC-Entwicklerboards und eine sehr rudimentäre Software-Schnittstelle zum PowerUP-Board. Trotz der Einfachheit der Softwareschnittstelle wich sie von unseren und damit von den Amiga-konformen Konzepten soweit ab, so daß wir bereits zu Beginn der praktischen Entwicklung mit Wissen von Phase 5 unseren eigenen Weg gehen mußten, um die Konzeption des AmigaOS aufrecht zu erhalten. Es war zwar nicht der von Phase 5 vorgeschlagene, aber ein möglicher und flexibler Weg und man hatte dagegen vorerst nichts einzuwenden.

Bereits auf der Computer 96 zeigten wir erste Entwicklungen mit StormC und StormPowerASM, die auf dem bewährten Amiga Hunkformat basierten und tadellos funktionierten.

In der Praxis stellte sich sehr schnell heraus, daß die Geschwindigkeit des PowerPCs gar nicht so deutlich zu spüren war wie wir erwartet hatten, was an den kompliziert zu handhabenden AmigaOS-Aufrufen lag, bedingt durch die Dualprozessortechnologie, die Phase 5 einsetzt. Pro Funktionsaufruf ist es nötig, einen Kontextwechsel zur 68K CPU zu machen, die 68K-Betriebssystemfunktion auszuführen und mit einem weiteren Kontextwechsel zum PowerPC-Programm zurückzukkehren. Bei jedem Wechsel ist selbstverständlich ein leeren des Daten-Cache nötig, das erneut sehr viel Zeit verschlingt. Nach unserem Verständnis wäre eine Beschleunigung des Kontextswitch mit einer Erweiterung der Hardware lösbar gewesen. Bei Phase 5 stieß unser Vorschlag jedoch auf taube Ohren, worüber wir uns nur wundern konnten. Gleichzeitig baten wir darum, tieferen Einblick in die Hardware-Eigenschaften zu bekommen, um bei der Lösung der Problematik behilflich zu sein. Diese Bitte nach der Offenlegung der Hardware-Beschreibung wurde, wie auch alle weiteren Bitten, mit dem Hinweis abgelehnt, daß durch Phase 5 jederzeit Hardware-Änderungen gemacht werden könnten, die dann nicht mehr funktionieren würden. Dann würde Software, die direkt auf die Hardware abgestimmt wäre, nicht mehr funktionieren. Lediglich bei ihrer eigens entwickelten Software wäre es garantiert, daß eine sofortige Anpassung stattfinden kann. Für uns als Software-Hersteller war das eine unbefriedigende Antwort, macht man damit lediglich klar, daß auch die Software-Seite monopolistisch überwacht werden soll, um Konkurrenten fernzuhalten.

Wir hatten bereits damals die Vermutung, daß Phase 5 dieses Argumentation nutzen wird, um ungewollte Entwicklungen diskussionslos zu verdrängen. Wir sind daher auch wenig überrascht über die diktatorischen Maßnahmen von Phase 5, die jetzt gegen unsere Entwicklung angekündigt wurden.

Noch im Dezember vergangenen Jahres erarbeitete unser Entwicklerteam, allen voran Sam Jordan und Michael Rock eine Lösung, die den Kontextwechsel gegenüber der Lösung von Phase 5 drastisch verbessern sollte. Bereits im Januar diesen Jahres hatten wir einen sehr stabilen Aufsatz zur Phase 5 Software lauffähig, der eine Kontextwechselzeit von im Schnitt 0,5 Millisekunden gegenüber 60 bis 90 Millisekunden der Phase 5 Lösung brachte.

Diese verbesserte Technik brachte für alle Applikationen, die wir nun 1:1 umsetzen konnten, eine unserer Meinung nach ausreichende Beschleunigung auf der PowerPC-Seite. Für alle Applikationen, die mehr Geschwindigkeit aus dem PowerPC herausholen sollen, ist eine spezielle Programmierung sowieso nötig. Die Entwickler müssen sich dann allerdings im klaren sein, für eine sehr kleine Zielgruppe einen enormen Aufwand treiben zu müssen, der sich auf dem Software-Markt für Dual-Prozessorboards kaum rechnen wird. Wir waren damals und sind auch heute noch der Überzeugung, daß zukünftige Amigas mit nur einem Prozessor ausgestattet sein werden, egal von welchem Hersteller diese Prozessoren kommen.

Wir verbesserten in der darauffolgenden Zeit unser Entwicklunssystem, programmierten die nötigen PowerPC nativen ANSI- und Mathematik-Bibliotheken und achteten weiterhin darauf, daß alles Amiga-konform und stabil funktionierte. Im April präsentierten wir unsere ersten Demos und das Entwicklungssystem auf der Clubmesse in Heilbronn und bei den Magischen Tagen in Trier, wo wir auch erste Informationen zur Problematik in Vorträgen veröffentlichten. Wir sprachen vor der Messe in Trier mit Wolf Dietrich und Gerald Carda von Phase 5 und baten die Wahl des Objektformates und die Konzeption der PowerPC-Schnittstelle öffentlich zur Diskussion zu stellen, was sie, wie Sie erahnen werden, abgelehnt haben. Ihre Begründung war lapidar: Wir haben das so entschieden und genau so wird es gemacht. Es gibt keine Diskussion!

Kurze Zeit nach der Messe kam dann eine neue Version der Software-Schnittstelle (PPC.Library) von Phase 5 (der Autor hatte bereits seit 3 Monaten keine neue Version mehr an uns geliefert). Wir testeten diese Lösung und wie zu erwarten, war unsere Software nicht mehr lauffähig. Die Änderungen in der PPC.Library war so tiefgreifend, daß selbst der noch wenige Monate zuvor erlaubte Weg nicht mehr nutzbar war.

Um weiteren Inkompatibilitäten zur Phase 5 Lösung vorzubeugen, stellten wir einen Anforderungenkatalog für einen Amiga-konformen Seiteneinstieg in die PPC.Library zusammen, um gemeinsam mit Phase 5 eine standardisierte Schnittstelle in ihrer PPC.Library zu schaffen. Die Liste wurde von unseren Autoren mit Herrn Carda bei Phase 5 diskutiert (der Autor der PPC.Library hatte kurzfristig abgesagt), kurz abgenickt, aber bis heute nichts umgesetzt! Bei der zeitgleichen Vorführung unserer Lösung und der Demonstration der Eigenschaften wurde sehr erstaunt zur Kenntnis genommen, daß sich unser Autor Sam Jordan in der Zwischenzeit ein PowerPC-Wissen angeeignet hatte, das die Fähigkeiten der Phase 5-Entwickler übertraf und wahrscheinlich heute noch übertrifft.

Vier Wochen nach diesem Treffen erschien eine neue Version der PPC.Library mit einigen Features, die wir zuvor in unserer Lösung präsentiert hatten. Der Verdacht des "Re-Ingeneerings" durch Phase 5 lag nahe. Auch diese Version der PPC.Library war wieder zu unserer Lösung inkompatibel, was uns ebenfalls wenig überraschte.

Als Konsequenz auf die Ignoranz von Phase 5 entschlossen wir uns, so schnell wie möglich eine Softwarelösung zu schaffen, welche die PPC.Library völlig ersetzt. Für unsere Bereitschaft zur Kooperation sollte das allerdings keinen Abbruch bedeuten. Am 5. Juni 1997 lief die erste Version unserer PowerPC- und Warp.library, nachdem zuvor die PPC.Library aus dem LIBS:-Verzeichnis entfernt wurde!

Bis zum heutigen Zeitpunkt haben wir dennoch Sorge dafür getragen, unter extremen Bedingungen eine Lösung bereitzustellen, die weiterhin mit der Phase 5 Schnittstelle zusammenarbeitet, wie sie auch durch Phase 5 geduldet wurde. Die beiden weiteren Versionen der PPC.Library von Phase 5, die bis zum heutigen Tage bei uns eintrafen, verwehrten ebenfalls unserer Software-Schnittstelle den Dienst. Immer wieder mußten Anpassungen vorgenommen und Fehler in der Phase 5-Programmierung umgangen werden.

Als Höhepunkt ist die Veränderung der Bibliothek von Ende Juli zu erwähnen. Wie wir alle wissen, hatte Phase 5 bereits zum Juni die Auslieferung der Boards angekündigt. Das verzögerte sich jedoch immer wieder von Woche zu Woche. Ende Juli wurde nun wieder eine Bibliothek von Phase 5 bereitgestellt, die es zwangsläufig notwendig machte, daß jede Software, die bereits unter PowerUP im Elf-Format entstanden war, neu kompiliert und gelinkt werden mußte, um wieder mit der aktuellen Softwareschnittstelle kompatibel zu sein. Für uns war das eine unverständliche Vorgehensweise, hatte man doch bereits Monate zuvor die Auslieferung der Boards geplant. Übrigens waren die Entwicklungen, die auf StormC basieren, nicht davon betroffen, da lediglich ein kleiner allgemeiner Programmteil der kompatiblen Bibliothek von uns neu kompiliert werden mußte, um alles wieder unter Phase5-PowerUP lauffähig zu machen.

Die letzte Version der PPC.Library erhielten wir nun zusammen mit dem PowerUP-Serienboard. Auch die erste, halbwegs vollständige Dokumentation zu dem angeblich revolutionären Messagesystem war dabei enthalten. Entwickler, die vorher planten, PowerUP-Software zu entwickeln, können demnach erst jetzt mit der Entwicklung beginnen. Ein Grund, warum es noch keine Anwendersoftware für PowerUP gibt. Wenn bereits entwickelt wurde, muß jetzt die Konzeption der Anwendersoftware neu überarbeitet und mit viel Aufwand neu programmiert werden.

Entwickler, die sich momentan dazu entschließen, Software für PowerUP mit der Phase 5-Lösung zu programmieren, müssen zwangsläufig damit rechnen, daß Ihre Software NICHT auf PowerPC-Boards anderer Hersteller und auch auf einem eventuell geplanten PowerPC-Amiga läuft. Das Statement von Phase 5 in dem von WarpUP als einem "Hacker Kernel" gesprochen wird, zeigt deren Angst vor einer möglichen Konkurrenz.

Ähnlich wie es zur Zeit gegen uns geschieht, wurde der Firma ProDAD bereits vor einem Jahr die Unterstützung durch Phase 5 verweigert. Phase 5 wird nun natürlich mit dem Hinweis kontern, daß auch ProDAD ein Entwickler-Board erhalten habe und durchaus entwickeln konnte. Was dem Anwender jedoch verschwiegen wird ist, daß Phase 5 nie die Hardwarebeschreibung offengelegt hat, was nötig ist, um eine Betriebssystem-Entwicklung für PowerUP-Boards vorzunehmen. Es sei denn es wird zu einer Entwicklung, die von Phase 5 gewünscht ist.

Lösungen und Wege

Für Sie als Anwender mag die Diskussion, die momentan entbrennt, überflüssig sein. Aber spätestens dann, wenn Sie ein Softwareprodukt einsetzen möchten, das PowerPC optimiert ist und Sie beim Kauf darauf achten müssen, ob es für das PowerPC-Board der Firma X oder Y geeignet ist, fragen Sie sich doch, warum man sich nicht rechtzeitig auf einen einheitlichen Standard geeinigt hat.

Wir als Software-Firma haben nicht die Zeit und die nötigen Ressourcen, um für jede Amiga-Hardware-Plattform neue Softwarekonzepte erarbeiten zu können. Anderen Firmen geht es genauso, weshalb zunächst eine Hardware-unabhängige Schnittstelle zwischen 68K-Betriebssystem und PowerPC-Steuersoftware definiert werden muß. Diese Definition muß so ausfallen, daß weder Hard- noch Softwarehersteller benachteiligt sind und eine Monopolstellung im Markt vermieden wird. Erfoderlich ist die Bildung eines unabhängigen Gremiums, das diese Aufgabe übernimmt.

Mit unserem Vorschlag zeigen wir einen möglichen Weg, der flexibel angepaßt werden kann. Als unabhängiger Software-Entwickler sind wir selbstverständlich Willens, unsere Lösung auch für andere Amiga-PowerPC-Plattformen umzusetzen, um die Lauffähigkeit der Amiga-PowerPC-Software zu gewährleisten. Auch eine Unterstützung des Elf-Objekt-Formates ist denkbar, wenn man ein unabhängiges Gremium von dessen Vorteil für den zukünftigen Amiga-Markt überzeugen kann. Die Argumente seitens Phase 5 können zur Zeit keinen Entwickler überzeugen, es sei denn, er plant den Ausstieg aus der Amiga-Entwicklung in Richtung A/Box. Von einem Industriestandard und einer Liste mit möglichen nutzbaren Entwicklungssystemen auf anderen und teuren Plattformen zu reden, ist lediglich Augenwischerei. Phase 5 ist vielleicht in der glücklichen Lage, sich entsprechende Entwicklungssysteme leisten zu können, aber schneller entwickeln werden sie deshalb nicht. Unserer Meinung nach sollte die Software-Entwicklung für den Amiga weiterhin auf dem Amiga stattfinden.

Vor geraumer Zeit hat die englische Firma Index, die bereits eine Lizenz für Amiga-Clones und das AmigaOS erworben hat, ebenfalls RISC-basierte Turbo-Boards angekündigt. Jeder Software-Entwickler, der diese Ankündigung gelesen hat, muß sich auch mit der Frage beschäftigen, ob Applikationen allgemein oder für jedes Board extra angepaßt werden müssen. Die Softwarelösung von Phase5 enthält - aus Sicht eines AmigaOS Entwicklers - so viele tiefgreifende Neuerungen (ELF-Format statt Hunk-Format, Dynamic linking statt Shared-Libraries), daß es für einen weiteren PowerPC-Hardware-Entwickler nahezu unmöglich ist, diese Schnittstelle ebenfalls zur Verfügung zu stellen. Und die Möglichkeit der Lizensierung bei Phase5 ist bei deren derzeitigem Verhalten fragwürdig und bislang auch nicht angekündigt.

Erst wenn ein allgemeiner Standard erarbeitet ist, können Software-Häuser beruhigt Software umsetzen, hat man doch dadurch die Gewißheit, daß sich Hersteller anderer PowerPC-Boards ebenfalls kompatibel verhalten müssen. Der Anwender kann sich dann sicher sein, daß keiner einen Alleingang realisieren kann.

Mit den PowerPC-Boards von Phase 5 ist ein erster Schritt in eine wundervolle Amiga-Zukunft getan. Wir meinen allerdings, daß dies nicht die einzige Lösung sein kann und hoffen auf weitere Hersteller, die im wieder aufblühenden Amiga-Markt einen Einstieg riskieren. Denn nur durch die notwendige Konkurrenz ist eine innovative Entwicklung gewährleistet.

Den Vorwurf von Phase 5, mit WarpUP unser Entwicklungssystem StormC für PowerPC-Applikationen favorisieren zu wollen, müssen wir entschieden zurückweisen. Jeder Hersteller von Entwicklungssystemen hat die Möglichkeit, einen PowerPC-Compiler zu erzeugen. Dieser Compiler kann wie gewohnt das Amiga-Hunk-Format schreiben. Erst der Programmierer einer Applikation (oder wie im Falle von StormC: das Laufzeitsystem) kümmert sich um die Spezialitäten des PowerPCs und benutzt dazu die PowerPC.library von WarpOS. Da es sich bei dieser Bibliothek um eine 100 % kompatible AmigaOS Shared-Library handelt, steht die Nutzung dieser Bibliothek jedem offen. So ist es durchaus denkbar, zwei verschiedene Compiler für den 68K-Teil (z.B. SAS/C bei einer bestehenden Applikation) und den PPC-Teil (z.B. StormC-PPC für die portierten Teile) in einem Mixed-Binary einzusetzen. Wir sind gerne bereit, jeder Firma, die ihren Compiler für den PowerPC umsetzen will, mit unserer, in den letzen 2 Jahren gewonnen Erfahrung zu helfen.

Wir sind sehr an einer Kooperation mit der Firma Phase 5 und allen anderen Herstellern, die PowerPC-Entwicklungen umsetzen möchten sowie an einer Zusammenarbeit mit Amiga International interessiert. Ebenso wünschen wir uns eine Koexistenz alternativer Lösungen, wenn damit sinnvolle Erweiterungen bereitgestellt werden und eine allgemeingültige Applikationenschnittstelle davon nicht ausgeschlossen wird.