TOS 21 - Betriebssystemstrategie für das 21.Jh.
Geschrieben von mibu am 05. Juni 1999 at 16:41:09:
Das nächste Jahrtausend wird mit einem großen Generationswechsel im Bereich der Betriebssysteme beginnen: Windows 2000 wird die veraltete Win9x-Technologie schrittweise mit WindowsNT verschmelzen, MacOS X wird, auf dem Erbe des NeXT fußend, UNIX und MacOS vereinen, Amiga wird mit dem AmigaSoft Environment 1.0 eine ganz neue Systemumgebung vorstellen, Linux wird in den Privatanwendermarkt eindringen, BeOS durch lokalisierte Versionen erheblich an Einfluß gewinnen und TOS... vielleicht ein paar neue Icons erhalten.
Die Karten werden also noch einmal gemischt und neu verteilt, doch ohne ein paar Asse im Ärmel wird TOS an diesem Spiel nicht mehr teilnehmen können.
Ich möchte deshalb unter dem Stichwort "TOS 21" dazu aufrufen, eine Betriebssystemstrategie für das TOS der nächsten Generation zu entwickeln. Hier ist wohlgemerkt nicht von einem neuen TOS 5 für den Milan die Rede, auch nicht von Erweiterungen für MagiC, es geht also nicht um kleinere Fehlerbereinigungen oder längst überfällige Anpasungen an den heutigen Standard - dies möge einem weiteren Thread vorbehalten sein. Es geht statt dessen darum, ein von Grund auf überarbeitetes, modernes, objektiv konkurrenzfähiges Betriebssystem für zukünftige TOS-kompatible Hardware zu ersinnen.
Dieses Betriebssystem muß sich von der Konkurrenz in Leistung und Bedienbarkeit soweit abheben, daß nicht nur ehemalige Atari-Fans, sondern auch potentielle PC- und Mac-Käufer für einen Einstieg in die TOS-Plattform gewonnen werden können. Zugleich muß diese Systemsoftware optimal an die zukünftige TOS-Hardwareplattform angepaßt sein, so daß TOS wieder auf den eigenen Rechnern die höchste Performance hat (und nicht auf PowerMacs) und somit Hard- und Software einen gegenseitigen Kaufanreiz bilden.
In Anbetracht der begrenzten Kräfte des TOS-Marktes ist es allerdings wichtig, daß dieses System die Weiterbenutzung alter TOS-Software erlaubt und eine möglichst einfache Portierung aktueller Software auf das neue System ermöglicht.
Neben der Abwärtskompatibilität erscheinen mir folgende Kernpunkte für ein TOS der Zukunft sinnvoll:
1) Netzwerkfähigkeit --------------------------- Ein TOS-Rechner muß sich ohne zusätzliche Software problemlos in Firmennetzwerke integrieren lassen, so daß etwa in einem DTP-Studio die auf dem Mac bearbeiteten Bilder problemlos in Calamus auf dem TOS-Rechner übernommen werden können. Für den Benutzer sollte sich die Navigation im Netzwerk nicht von der im lokalen Dateisystem unterscheiden, ebenso nahtlos einzubinden wäre der FTP-Zugriff auf das Internet. Wichtig ist auch eine rudimentäre Multiuserfähigkeit, so daß sich zumindest mehrere Benutzer einen Arbeitsrechner teilen können, mit je eigenen Zugriffsrechten und Systemeinstellungen.
2) Symmetrisches Multiprozessing ---------------------------------------- TOS 21 sollte schon auf Systemebene den Einsatz mehrerer Prozessoren unterstützen, ohne daß sich die Programme selbst um die Aufgabenverteilung kümmern müssen. Ältere, inkompatible Software würde nur einen der Prozessoren exklusiv nutzen, während auf dem anderen bereits weitere Systemaufgaben erledigt würden.
3) Einfache Systempflege ---------------------------- Auf einem einfachen Atari unter Single-TOS befindet sich das gesamte Betriebssystem im ROM und ist damit auch bei gröbster Fehlbedienung unkaputtbar. Die einzige Systemdatei, die ein unbedarfter Anwender oder ein übelwollendes Programm zerstören könnten, ist die Desktop-Einstellungsdatei, deren Fehlen den Rechner nicht unbenutzbar macht und die in wenigen Sekunden wieder neu anzulegen ist. Kleine Hilfsprogramme muß man auf diesem Rechner nicht umständlich installieren, sondern legt sie lediglich ins Wurzelverzeichnis und gibt ihnen nötigenfalls die Endung "*.ACC" und alles, was der Rechner sonst noch automatisch starten soll, kommt einfach in einen neu angelegten Ordner, den man "AUTO" nennt.
Eine derart simple, fehlertolerante Systempflege sollte auch bei der Konzeption von TOS 21 nicht aus den Augen verloren werden, wenngleich sie aufgrund höherer Funktionalität nicht mit den gleichen Mitteln zu erreichen ist. Unter TOS 21 sollte es nur noch einen Systemordner im Wurzelverzeichnis geben, in welchem sich dann Unterordner für Zeichensätze, Auto-Startprogramme und andere systemrelevante Dateien finden. Der Macintosh sollte hier - wie einst bei der Konzeption des GEM - zum Vorbild genommen werden. Möchte der Anwender einen Zeichensatz installieren, läßt er dessen Icon einfach über dem Systemordner fallen - die Einordnung in den Font-Ordner erfolgt automatisch. Kann das Betriebssystem nicht anhand der Endung erkennen, wo eine Datei einsortiert werden soll, bietet es dem User sinnvolle Möglichkeiten an. In diesem Zusammenhang ist auch die Einführung eines Desktop-Menü-Ordners sinnvoll, in dem Programme abgelegt werden, die unter dem Desktop-Menü erscheinen sollen. Die Unterscheidung von Programm und Accessory wäre damit hinfällig.
Ein weiteres Ärgernis aktueller (nicht nur) TOS-Systeme ist die Vielzahl an Zusatzdateien, die zum Betrieb eines Programmes nötig sind. Einige davon stiften im selben Ordner wie das Programm Unordnung, zum Beispiel die Ressource-Datei, manche müssen wiederum in andere Ordner kopiert werden, wie die Hilfe-Datei. Beim Weitergeben oder Umkopieren des Programmes wird dann leicht die Hälfte vergessen und zum Start muß erst der Programmordner geöffnet und das eigentliche Programm in der Iconflut gesucht werden. Ebenso ärgerlich ist die Notwendigkeit, für jedes neue Programm erst das passende Icon und die zugehörigen Dateiendungen anmelden zu müssen. Dies ist auf andern Systemen besser gelöst.
TOS 21 könnte auch hier Abhilfe schaffen: Standardmäßig sollte ein Ordner, in dem sich ein Programm befindet, noch folgende weitere Dateien enthalten:
a) die RSC-Datei mit den Benutzeroberflächen-Elementen des Programmes, bevorzugt in mehreren Sprachen, deren Auswahl sich nach den Systemeinstellungen seitens des Benutzers richtet b) Anmeldungs-Datei (enthält Angaben über die Dateiendungen, für die sich das Programm zuständig erklärt) c) Programm-Icon-Datei (evtl. mehrere für unterschiedliche Farbtiefen) d) Datei-Icon-Datei (wird automatisch für die Dateien benutzt, deren Endungen das Programm für sich angemeldet hat) e) Hilfstext-Datei (ST-Guide)
Der Ordner, der neben dem Programm all diese Dateien enthält, wird nun einfach mit der Endung "*.PRG" versehen und verhält sich dann im Desktop, als ob er selbst ein Programm wäre, d.h. bei Doppelklick wird das darin liegende Programm gestartet und nicht der Ordner geöffnet. Auf diese Weise würde die Bedienung vereinfacht und alle wichtigen programmzugehörigen Dateien zusammengehalten. Das Beriebssystem würde jeden dieser PRG-Ordner, den es zu Gesicht bekommt, sofort inspizieren und das darin befindliche Icon zu dessen Anzeige benutzen, sowie die korrekten Dateiendungen auf das Programm anmelden und auch die entsprechenden Dateien mit dem passenden Icon versehen. Neugierige könnten durch Gedrückthalten der Umschalttaste den PRG-Ordner weiterhin wie einen normalen Ordner öffnen. Ein ähnliches Prinzip ist beim Acorn RiscOS und in NeXT-Step bereits realisiert und funktioniert dort hervorragend.
4) Java / Jini --------------------- Mir persönlich ist kein sinnvolles, in Java programmiertes Programm bekannt, das darüber hinaus auch noch wirklich plattformunabhängig wäre, trotzdem wird Java-Unterstüzung von vielen als unverzichtbar erachtet, und sei es nur für Werbezwecke. Wirklich von Nutzen für TOS 21 könnte hingegen eine Jini-Implementierung sein, die eine Art universelles Plug-and-Play verspricht: Jedes Gerät teilt dem System selbst mit, was es kann, damit dessen Dienste bei Bedarf in Anspruch genommen werden können. Hierfür bedürfte es nicht einmal eines Computers, man könnte die Kaffeemaschine gleich direkt an den Radiowecker anschließen ;-). Für TOS 21 liegt der unermeßliche Vorteil dieses Prinzips darin, daß keine speziellen TOS-Treiber mehr nötig wären, um handelsübliche Geräte anzuschließen (falls sich SUNs Jini-Technologie durchsetzt).
5) Softripping auf Systemebene --------------------------------------- Die große Stärke von NeXT-Step war die durchgängige Basierung der Graphic-Engine auf Postscript: Nicht nur die Drucker wurden mit dieser Seitenbeschreibungssprache angesteuert, auch die Bildschirmdarstellung erfolgte über Display-Postscript, wodurch ein (nahezu) 100%-iges WYSIWYG möglich wurde. Im geplanten MacOS X wird Apple sich aus Linzenzgründen von DisplayPS verabschieden, aber dafür eine größtenteils selbst entwickelte neue Graphic-Engine namens Quartz einsetzen, die auf PDF und QuickDraw basiert.
Dieser geballten Power im Publishing und EBV-Bereich muß TOS 21 etwas entgegensetzen, und die Technologie hierfür ist sogar im TOS-Markt schon vorhanden: nämlich das Softripping des Calamus, welches bereits ein und diesselbe Technologie für Bildschirmdarstellung und Ausdruck einsetzt, dabei vollkommenes WYSIWYG bietet, weniger fehleranfällig als PS ist und diesem qualitativ absolut das Wasser reichen kann.
So wie die heutigen Module des Calamus im Grunde eigenständige Programme sind, die quasi nicht unter TOS, sondern unter Calamus als "Betriebssystem" laufen, würden in TOS 21 die einzelnen Programme sich der im System verankerten Softripping-Technologie für die Ausgabe in beliebiger Auflösung auf beliebigen Geräten bedienen. Dies wäre gewissermaßen eine weiterentwickelte Synthese aus NVDI und Calamus.
Die Vorteile für TOS wären, daß es hierdurch endgültig zu einer State-of-the-Art - Publishingplattform aufsteigen würde, denn Calamus würde nicht mehr isoliert dastehen, sondern durch eine Fülle weiterer, für sich eigenständiger Programme ergänzt werden, die sich der gleichen Darstellungstechnologie bedienten: zum Beispiel Notensatzprogramme oder auch einfach ein weiterentwickeltes Texel als Tabellenpublishingsystem, das dann nur durch Nutzung der neuen Graphic-Engine "mal eben" einen Zoomfaktor von 10.000 bieten könnte (wie stehts mit Excel?).
Die Vorteile für Calamus / invers lägen zum einen darin, daß man nun durch jede verkaufte TOS-Kopie Lizenzeinnahmen hätte, auch wenn gar kein Calamus auf dem Rechner eingesetzt würde. Viel wichtiger wäre jedoch, daß die Softripping-Technologie hierdurch zum unverrückbaren Standard für eine ganze Computerplattform würde und somit auf einer Stufe mit Postscript stünde. Zugleich besäße man damit eine Plattform, auf der Calamus genuin unterstützt wird und damit eine optimale Leistung entfalten kann. Der Verbund von TOS 21 und zukünftiger TOS-Hardware wäre ein besseres Verkausfsargument für die Calamus innewohnende Stärke als es der Betrieb mittles eines Emulators auf PCs oder Macs ist, denn Adobes InDesign braucht kein solches Hilfsmittel.
6) Modulkonzept ------------------------- Man könnte noch eine weitere Stärke von Calamus in das Betriebssystem übernehmen, nämlich die Modularisierung. Neben eigenständigen Programmen könnte TOS 21 auch Programm-Module (*.MDL) kennen, welche den Hauptprogrammen zusätzliche Funktionen zur Verfügung stellen. Calamus, Texel oder Papyrus wären also sogenannte "Container- Applikationen", in die sich etwa ein Rechtschreib-Modul einklinkt, um eine Korrekturfunktion anzubieten, oder eine Textrotationsfunktion, um Schrift hochkant darzustellen. Alle Module würden sich in einem gemeinsamen System-Verzeichnis befinden und dadurch nutzbar gemacht, daß man in einem Hauptprogramm den Menüpunkt "Modul laden..." aktiviert. Hierauf erschiene eine Auswahlbox mit allen Modulen, die in dem Hauptprogramm nutzbar wären und einer kleinen Beschreibung zu jedem Modul. Damit das Hauptprogramm (der "Container") weiß, ob die Nutzung eines bestimmten Moduls in ihm sinnvoll ist, enthält jedes Modul Angaben darüber, welche Art von Daten es bearbeiten kann. Aus kommerziellen Erwägungen kann die Nutzung bestimmter Module auch auf ein bestimmtes Hauptprogramm beschränkt werden (z.B. nur Calamus, nicht DA's Layout). Neben einem Button zur Aktivierung des angewählten Moduls besteht die Möglichkeit, dieses Modul gleich für alle Programme zu aktivieren, die etwas damit anfangen könnten. Beim Verlassen eines Programmes merkt dich dieses, welche Module es geladen hatte, um diese beim nächsten Start des Programmes automatisch nachzuladen.
Der Arbeitsbereich eines Moduls wäre das gerade aktivierte Objekt, etwa eine Grafik oder ein Wort, oder der aktive (Text-)Rahmen, wobei im Extremfall der gesamte Fensterinhalt als (virtueller) aktiver Rahmen behandlet wird.
Für Calamus / invers wäre der Vorteil eines systemintegrierten Modulkonzeptes die Flut neuer Module, die hierdurch hervorgerufen würde.
7) Funktionsleiste -------------------------- Passend zum Modulkonzept sollte auch die Calamus-eigene Bedienungsphilosophie in TOS 21 einfließen, denn hierin kann ganz allgemein eine Errungenschaft der TOS-Plattform gesehen werden, die sie von anderen Systemen abhebt. In vielen Programmen hat sich diese Benutzeroberfläche ohnehin bereits durchgesetzt, z.B. in DA's Layout und PixArt.
TOS 21 sollte also bereits vom AES aus eine Funktionsleiste als in jedem Programm obligatorisches Bedienelement anbieten. Diese Leiste wäre dreigeteilt: Ganz links findet man die Funktionsgruppen-Icons des gerade aktiven Programmes. Daran anschließend befinden sich die Funktionsgruppen der für dieses Programm geladenen Module. Von der rechten Seite beginnend werden schließlich alle parallel laufenden Programme aufgeführt, so daß eine zusätzliche Task-Leiste, wie etwa MultiStrip, obsolet würde.
Die Funktionsleiste würde sich in allen Programmen etwa so wie heute in Calamus verhalten: Klickt man auf ein Icon einer bestimmten Funktionsgrupppe, erscheinen die zugehörigen Funktionen in einem Werkzeug- bzw. Befehlsfenster (im AES integriert) und stehen dort solange zur Verfügung, bis man in der Funktionsleiste eine andere Funktionsgruppe anwählt.
Befindet man sich auf dem Desktop, so werden weiterhin rechts die laufenden Programme angezeigt, und sinnvolle Module mag hier ebenfalls geben, ganz links aber befinden sich Schnell-Start-Icons, mit denen sich direkt die wichtigsten Programme starten lassen.
Möchte man weitere Programmicons hinzufügen, zieht man das entsprechende Programm einfach auf die Funktionsleiste und schon ist es von dort abrufbar. Ebenso leicht läßt sich eine Datei mit einem bestimmten Programm starten, wenn man es auf dessen Icon in der Funktionsleiste zieht. Legt man aber einen Ordner in die Funktionsleiste, öffnet sich bei einem Klick auf dessen Icon ein Werkzeug-Fenster, welches die im Ordner enthaltenen Programme und/oder Dokumente zum einfachen Starten anbietet. Würde man nun einen leeren Ordner in der Funktionsleiste plazieren, öffnete sich bei einem Klick auf dessen Icon ein leeres Werkzeug-Fenster, das sich beliebig mit Programm-Icons bestücken ließe, die dann auch als Alias in den Ordner kopiert würden, in erster Linie aber als praktische "Programm-Gruppe" fungierten. Hier könnte man etwa Schnell-Start-Buttons für alle Grafikprogramme einrichten oder man füllt eine solche Gruppe mit wichtigen Dokument-Vorlagen statt Programmen.
8) ...? ------------ Soviel als erstes Gedankenspiel, nun sind Eure Vorschläge gefragt!
Michael