Software für Intel-Macs: So konvertieren die Profis

Für Entwickler, die mit anderen Systemen als dem von Apple arbeiten, ist der Wechsel zu Intel „so etwas wie ein plötzliches Erwachen“, sagt Edwards. Auch wenn wechselnde Architekturen und Entwicklungssysteme schmerzvoll sind, „bringt es jeden auf den Stand der neuesten Entwicklungsbemühungen“.

Einer der Entwickler in dieser Position ist Peter N. Lewis von Stairways Software, der Schöpfer des legendären Interarchy-FTP-Clients (ehemals Anarchie). „Da Interarchy in Pascal geschrieben ist, hatten wir eine ganze Menge mehr Schwierigkeiten als die meisten Entwickler“, sagt er.

Stairways hat etwa ein Jahr lang mit anderen Entwicklern zusammengearbeitet, um Mac-Versionen von GNU Pascal und Free Pascal und dann Pascal-Versionen von Apples Schnittstellendateien zu erzeugen.

„Diese Arbeit ist jetzt voll funktionsfähig, und Interarchy 8 wurde von Metrowerks Pascal zu GNU Pascal portiert“, sagt Lewis. „GNU Pascal arbeitet mit dem gleichen Back-End wie GNU C, deshalb hat GNU Pascal keine Schwierigkeiten damit, auf einem PPC oder einem x86 zu laufen und entweder für Power PC oder x86 zu kompilieren.“

Damit Interarchy selbst auf Intel funktionieren konnte, musste vor allem das Problem der Bytefolge gelöst werden, wie er sagt: „In Interarchy gab es etwa ein halbes Dutzend Codestücke, die mit Bytefolgen zu tun hatten, etwa die Verarbeitung von SFTP-Paketen oder die Verarbeitung von Netzwerk-Paketen, während Netzwerktraffic gesnifft wird.“

„Normalerweise hat man es nur mit Bytefolgen zu tun, wenn man auf Dateien oder Netzwerke zugreift, daher kapselt man Code, der in Dateien oder Netzwerken liest oder schreibt, oder verwendet stattdessen gleich ein Textdatei-Format oder ein Netzwerkprotokoll, um das Problem vollständig zu umgehen“, schlägt Lewis vor.

Interarchy 8 befindet sich in der Beta-Testphase und soll als Universal Binary Ende März, Anfang April herauskommen.

Die Bedeutung der Entwicklungsumgebung

Baden Hughes, Forscher am Department of Computer Science and Software Engineering an der University of Melbourne, hat herausgefunden, dass Veränderungen in der Entwicklungsumgebung größere Auswirkungen haben als ein Austausch der CPU.

Hughes ist einer der Entwickler und Betreuer des AGTK (Annotation Graph Toolkit), einer Sammlung von Software-Komponenten zum Erstellen von Tools zum Annotieren linguistischer Signale – in einer Zeitfolge angeordnete Daten wie Audio- und Video-Daten, die jegliche Form linguistischen Verhaltens festhalten. Dieses Tool besteht aus etwa 40.000 Zeilen C/C++-Quellcode und weiterem Code in Java, Tcl/Tk und Python.

Als Hughes 2004 die Core Library und Anwendungen auf Mac OS X portierte, blieb er zunächst bei der Eclipse IDE und dem Gcc-Compiler. „Bei der Worldwide Developers Conference 2005 gelang es mir, zwischen dem Xcode Lab und dem Universal Binary Lab AGTK auf Xcode zu portieren. Darauf aufbauend konnte ich architekturübergreifende Binärdateien erzeugen“, so Hughes. „In etwa 100.000 Zeilen Code waren genau 3 Änderungen nötig, um die Kompilierung zu ermöglichen.“ Bei Code mit Altivec-Instruktionen wäre diese Aufgabe jedoch ein wenig schwieriger, da Altivec und die SSE von Intel nicht direkt miteinander kompatibel sind.

„Wenn man bereits auf Gcc (GNU Compiler Collection) basierenden Code hat, der sich außerhalb der Normen von Xcode bewegt, lohnt es, mit architekturübergreifender Kompilierung als Vorstufe zur Migration zu experimentieren“, riet Hughes anderen Entwicklern. „Im Grunde basiert die unter Xcode vorhandene Möglichkeit, universelle Binärdateien zu erzeugen, auf den Cross-Compiler-Optionen von Gcc (etwa -arch), so dass man mögliche Probleme auch unabhängig von der OS-X-Umgebung sondieren kann, indem man einfach den Cross-Compiler verwendet.“

Einige Entwickler größerer Anwendungen sehen sich ähnlichen Problemen gegenüber, jedoch in anderen Größenordnungen. Wie Stairways versuchen sie meist, die neuen Versionen als universelle Binärdateien herauszubringen, statt den bestehenden Code zu aktualisieren.

MYOB ist dabei, Accountedge von Codewarrior auf Xcode zu portieren. Nach Aussagen des Unternehmenssprechers Greg Smith stellt dieses Projekt in dreifacher Hinsicht eine Herausforderung dar: aufgrund der Größe des Programms („viele Millionen Zeilen Code in C und C++“), aufgrund seiner Komplexität und der notwendigen Trennung der Anwendungsschicht vom Code der Benutzeroberfläche sowie aufgrund der Verwendung hauseigener, plattformübergreifender Bibliotheken für Elemente der Benutzeroberfläche („einige können einfach neu kompiliert werden, andere müssen in Xcode ganz neu geschrieben werden“).

„Datei- und Netzwerk-E/A sind eine größere Herausforderung als andere Aspekte des Übergangs. Es gibt auch Probleme mit systemnahen Routinen, die Punkte und Rechtecke verwenden, was bedeutet, dass wir Teile unserer Bibliotheken möglicherweise von Grund auf neu schreiben müssen und nicht einfach den Code überarbeiten und neu kompilieren können. Zurzeit sind wir noch dabei herauszufinden, was einfach zu bewerkstelligen ist und was mehr Arbeit erfordert“, sagte Smith.

Der Übergang zu Xcode „wird es uns auf lange Sicht ermöglichen, leichter mit Apple Schritt zu halten und uns dort, wo es angebracht ist, deren OS-Innovationen zu nutzen,“ so Smith weiter.