J
Jens Groh
|
Apple kündigt Teile von "Carbon" ab. So geschehen auf der WWDC2007.
Kein Spektakel in der Presse.
Und was geht uns das an?
Eine ganze Menge!
Hintergrund:
Carbon ist eine Schnittstelle für die Anwendungsprogrammierung (API), die geschaffen wurde, um den Firmen, die vor Mac OS X schon im Markt waren, den Umstieg von Mac OS 9 zu erleichtern. Deren Programmierer bekamen den alten "Stallgeruch" für das neue System, damit sie nicht revoltieren. Aber das verhinderte auch ihr Umlernen. Viele kleben noch heute notorisch an Carbon und scheuen sich, alles auf das eigentliche "Haus-API", also "Cocoa", umzuprogrammieren. Noch ein wichtiger Grund dafür ist, dass Cocoa in einer anderen Programmiersprache programmiert wird: Objective-C. Das schreckt viele Carbon-Anwender, weil sie meist C++ bevorzugen und irrtümlich annehmen, dass Objective-C ebenso kompliziert und aufwendig zu lernen sei. Tatsächlich ist es aber viel einfacher und vermeidet alle Konzeptfehler der Sprache C++.
Am leichtesten haben es seit OS X immer die Programmierer gehabt, die
- statt Altcode rumzuschleppen und immer wieder für neue Randbedingungen hinzupfriemeln, ihre Produkte komplett redesigned und sich dabei eng an Apples Empfehlungen gehalten haben: OS X sofort nutzen, mit den neuesten APIs und den mitgelieferten Tools.
- ein Softwaredesign mit extrem sauberer Systematik hatten (Abstraktionsschichten, Design Patterns...)
- oder einfach bisher NeXTStep-Programmierer waren.
Das alles gilt im Besonderen für die Audio-Programmiererszene.
Warum?
- In der OS 9-Audioszene brauchte man zum Programmieren eher Hackermanieren, weil das alte Betriebssystem für Echtzeitsachen so unzureichend ausgestattet war, dass man vieles daran vorbei programmieren musste. Deshalb gab es auch von Drittherstellern Behelfe, wie OMS und ASIO. Dinge also, die man sich auch erst wieder abgewöhnen muss, wenn die Funktionalität endlich dort ist, wo sie eigentlich hingehört: im Betriebssystem. Einige der Altprogrammierer folgen möglicherweise immer noch nur unwillig irgendwelchen "uncoolen" Apple-Vorgaben - und deshalb oft zu spät.
- Ein gescheites Audio-API für OS X (CoreAudio) kam tatsächlich erst spät, weil es beim Voläufer NeXT seit dem Wegfall der eigenen DSP-Hardware keine komfortable Audiounterstützung mehr gegeben hatte. Und CoreAudio reifte ärgerlich langsam. Sogar heute noch sind Teile noch nicht fertig spezifiziert, sondern nur in der Abteilung "Examples" zu finden.
Nun kommt also der Anfang vom Ende von Carbon: Teile davon (User-Interface im wesentlichen) werden in OS X 10.5 "Leopard" keine 64-Bit-Unterstützung bekommen.
Da ja fast jedes Carbon-Programm eine grafische Benutzeroberfläche hat, werden also die Programmierer bei ihren 32-Bit-Versionen bleiben müssen und den Leistungssprung der neueren Maschinen nicht nutzen können.
Ihr könnt euch denken, dass in Apples Carbon-Entwickler-Mailingliste die Hölle los ist. Hier ist eine Zusammenfassung.
Nun zu den Auswirkungen für den Audio-Bereich:
- 64 Bit ist für professionelle Anwender wirklich wichtig. Große Projekte stoßen heute schnell an die Grenzen des 32-Bit-Adressraums: Der entspricht nämlich nur 186 Minuten Material (mono / 96 kHz / Float)! In der Regel sind die 32-Bit-Programme da am Ende.
- Ein sehr kniffliges Problem sind die Plugins. Noch ungeklärt ist, ob überhaupt (oder wie) es möglich sein wird, 64-Bit-Hostprogramme mit 32-Bit Plugins zu mischen und umgekehrt. Ähnliche Probleme kennt man ja schon von PowerPC-Plugins in Intel-Hostprogrammen und umgekehrt. Auch keine Neuigkeit ist der Ärger, dass viele Carbon-Hostprogramme keine Cocoa-Benutzeroberfläche eines Plugins anzeigen können und umgekehrt.
Für mich war das die einzige wesentliche Neuigkeit der WWDC2007.
Ich bin gespannt auf die Reaktionen der Softwarehersteller.
Kein Spektakel in der Presse.
Und was geht uns das an?
Eine ganze Menge!
Hintergrund:
Carbon ist eine Schnittstelle für die Anwendungsprogrammierung (API), die geschaffen wurde, um den Firmen, die vor Mac OS X schon im Markt waren, den Umstieg von Mac OS 9 zu erleichtern. Deren Programmierer bekamen den alten "Stallgeruch" für das neue System, damit sie nicht revoltieren. Aber das verhinderte auch ihr Umlernen. Viele kleben noch heute notorisch an Carbon und scheuen sich, alles auf das eigentliche "Haus-API", also "Cocoa", umzuprogrammieren. Noch ein wichtiger Grund dafür ist, dass Cocoa in einer anderen Programmiersprache programmiert wird: Objective-C. Das schreckt viele Carbon-Anwender, weil sie meist C++ bevorzugen und irrtümlich annehmen, dass Objective-C ebenso kompliziert und aufwendig zu lernen sei. Tatsächlich ist es aber viel einfacher und vermeidet alle Konzeptfehler der Sprache C++.
Am leichtesten haben es seit OS X immer die Programmierer gehabt, die
- statt Altcode rumzuschleppen und immer wieder für neue Randbedingungen hinzupfriemeln, ihre Produkte komplett redesigned und sich dabei eng an Apples Empfehlungen gehalten haben: OS X sofort nutzen, mit den neuesten APIs und den mitgelieferten Tools.
- ein Softwaredesign mit extrem sauberer Systematik hatten (Abstraktionsschichten, Design Patterns...)
- oder einfach bisher NeXTStep-Programmierer waren.
Das alles gilt im Besonderen für die Audio-Programmiererszene.
Warum?
- In der OS 9-Audioszene brauchte man zum Programmieren eher Hackermanieren, weil das alte Betriebssystem für Echtzeitsachen so unzureichend ausgestattet war, dass man vieles daran vorbei programmieren musste. Deshalb gab es auch von Drittherstellern Behelfe, wie OMS und ASIO. Dinge also, die man sich auch erst wieder abgewöhnen muss, wenn die Funktionalität endlich dort ist, wo sie eigentlich hingehört: im Betriebssystem. Einige der Altprogrammierer folgen möglicherweise immer noch nur unwillig irgendwelchen "uncoolen" Apple-Vorgaben - und deshalb oft zu spät.
- Ein gescheites Audio-API für OS X (CoreAudio) kam tatsächlich erst spät, weil es beim Voläufer NeXT seit dem Wegfall der eigenen DSP-Hardware keine komfortable Audiounterstützung mehr gegeben hatte. Und CoreAudio reifte ärgerlich langsam. Sogar heute noch sind Teile noch nicht fertig spezifiziert, sondern nur in der Abteilung "Examples" zu finden.
Nun kommt also der Anfang vom Ende von Carbon: Teile davon (User-Interface im wesentlichen) werden in OS X 10.5 "Leopard" keine 64-Bit-Unterstützung bekommen.
Da ja fast jedes Carbon-Programm eine grafische Benutzeroberfläche hat, werden also die Programmierer bei ihren 32-Bit-Versionen bleiben müssen und den Leistungssprung der neueren Maschinen nicht nutzen können.
Ihr könnt euch denken, dass in Apples Carbon-Entwickler-Mailingliste die Hölle los ist. Hier ist eine Zusammenfassung.
Nun zu den Auswirkungen für den Audio-Bereich:
- 64 Bit ist für professionelle Anwender wirklich wichtig. Große Projekte stoßen heute schnell an die Grenzen des 32-Bit-Adressraums: Der entspricht nämlich nur 186 Minuten Material (mono / 96 kHz / Float)! In der Regel sind die 32-Bit-Programme da am Ende.
- Ein sehr kniffliges Problem sind die Plugins. Noch ungeklärt ist, ob überhaupt (oder wie) es möglich sein wird, 64-Bit-Hostprogramme mit 32-Bit Plugins zu mischen und umgekehrt. Ähnliche Probleme kennt man ja schon von PowerPC-Plugins in Intel-Hostprogrammen und umgekehrt. Auch keine Neuigkeit ist der Ärger, dass viele Carbon-Hostprogramme keine Cocoa-Benutzeroberfläche eines Plugins anzeigen können und umgekehrt.
Für mich war das die einzige wesentliche Neuigkeit der WWDC2007.
Ich bin gespannt auf die Reaktionen der Softwarehersteller.
