[ASH-Homepage] [Produktübersicht] [Meldungen] |
||||||
Ein Programm, aber welcher Computer? Schon lange gibt es den Traum von Programmen, die auf allen Computern funktionieren. Verschiedene Lösungsansätze hat es im Laufe der Zeit gegeben, aber wenn man ehrlich ist, dann wird man eingestehen müssen, daß alle bisher gescheitert sind. Sehen wir uns doch mal an, was es da bisher gab. P-Code Mit dem P-Code wollte man die Idee realisieren, daß ein Compiler keinen echten Code erzeugt, der direkt vom Prozessor der Maschine verstanden wird, weil das eine maschinenabhängigkeit des Programms bedeutet hätte. Daher wurde der P-Code erzeugt, eine Codierung, die relativ schnell und mehr oder weniger direkt in Maschinencode umgesetzt werden kann. Zur Komplettierung dieses Konzeptes ist es dann erforderlich, daß für die jeweiligen Zielmaschinen, auf denen die P-Code-Programme laufen sollen, Programme zur Verfügung stehen, die den P-Code in den jeweiligen Maschinencode übersetzen. Eine zeitlang war diese Idee modern und fand begeisterte Anhänger. Es gab auf verschiedenen Maschinen Compiler für die unterschiedlichsten Programmiersprachen, die P-Code erzeugten. Aber letzten Endes ist dieses Experiment im Sande verlaufen. Mit Java ist diese Idee wieder modern geworden und wer sich mit der Idee eines Netzcomputers anfreundet, der muß sich auch mit der alten Idee des P-Code wieder anfreunden. Portierbarkeit Eine bessere Idee als der P-Code repräsentieren die Konzepte von Programmiersprachen wie C oder Modula. Die Idee hinter beiden Sprachen ist die, daß ein Programm systemunabhängig codiert werden soll, also so, daß der Aufwand, um es auf einem anderen Computer zum Laufen zu bringen im wesentlichen darin besteht, das Programm auf der Zielmaschine einmal zu compilieren. Man kann sagen, daß im wesentlichen für C-Programme gilt, daß unter Unix eine Menge davon existieren, die auf den verschiedensten Unix- Maschinen durch einfaches Compilieren benutzbar werden. Dies ist jedoch weder dem normalen Anwender zuzumuten, noch wird man in allen Fällen der Hersteller den Quellcode herausgeben können. Außerdem ist diese Methode nicht unabhängig vom Betriebssystem durchführbar. Spätestens wenn man eine nette Benutzerschnittstelle einbauen will, wird man auf Funktionen des jeweiligen Betriebssystems zurückgreifen und schon wenn man ein Fenster für den Benutzer öffnen möchte, wird man feststellen, daß so ziemlich jedes Betriebssystem da was anderes macht. Unabhängige Bibliotheken Eine Erweiterung der vorangegangenen Idee ist nun die, daß man Systembibliotheken bastelt, die das Benutzer-Interface steuern und dabei die jeweiligen Eigenheiten des Betriebssystems berücksichtigen. Das bedeutet, daß man sich überlegt welche Aktionen zum öffnen eines Fensters nötig sind und dafür einen Systemaufruf in einer Bibliothek festlegt. Die Bibliothek enthält nun für allen Funktionen, die zur Steuerung der Benutzerschnittstelle und generell zur Kommunikation mit dem Betriebssystem benötigt werden, entsprechenden Code und wird auf jeder in Frage kommenden Maschine für das jeweilige Betriebssystem angepaßt. Das Ergebnis sieht so aus, daß ein Programm so geschrieben werden kann, daß es auf jeder Maschine, auf der die Systembibliothek vorhanden ist, ohne Veränderungen compiliert werden kann und dann immer wieder dasselbe Programm dabei herauskommt, nur daß es auf einem anderen Computer mit einem anderen Betriebssystem läuft. Im Grunde eine geniale Idee, nur leider haben die einzelnen Systeme verschiedene Eigenschaften, die sich nicht unter einen Hut bringen lassen. Deswegen muß man zwangsweise Kompromisse eingehen, die dazu führen, daß man Spezialitäten eines Betriebssystems möglicherweise nicht nutzen kann. Die virtuelle Maschine Alle nun geschilderten Sachverhalte laufen auf eines heraus. Am besten wäre es, wenn es nur ein Betriebssystem und vor allem auch nur auf einem Prozessor gäbe, denn dann könnte man alle Programme auf einem Computer einsetzen. Dazu wird es aber nicht so schnell kommen, denn neue Prozessoren eröffnen neue Möglichkeiten und angestaubte Konzepte verhindern echte Innovation. Wie wäre es also, wenn man Programme für eine virtuelle Maschine, also für einen Computer der nur als Gedankenmodell existiert, schreibt? Das ist bisher schon daran gescheitert, daß es sehr schwerfällt einen solchen Computer zu entwerfen. In Gedanken ist eben alles erlaubt und ob es eine realistische Basis hat, muß sich erst noch zeigen. Ferner gibt es ein ganz anderes handfestes Problem: Die Software! Wo ist die Textverarbeitung in P-Code oder Java? Gibt es nicht neue Betriebssysteme, die gerne eine stattliche Auswahl an Software böten? Wo ist die breite Palette von Software, die auf zig Maschinen läuft? Warum hat sich GEM auf PCs nie durchgesetzt? Wer ist schon bereit Programme für eine nicht existierende Maschine zu schreiben? Eben, keiner! Daher kann eine virtuelle Maschine nur durch Zufall entstehen und zwar genau dann, wenn eine bisher existente Maschine, für die es Hardware und Software in rauhen Mengen gibt, vom Markt verschwindet. Innovation durch Zufall? Das verwundert nicht so sehr, wenn man sich die Geschichte der Computer mal vor Augen führt. Die meisten scheinbar genialen Erfindungen beruhten auf Zufällen und nicht etwa auf genialer Planung. Wie stießen Jobs und Wozniak aufeinander, so daß sie Apple gründen und den ersten Personal Computer bauen konnten? Durch Zufall! Wieso wurde DOS das Betriebssystem für IBM-PCs? Durch Zufall! Es gibt ein ganzes Buch darüber mit dem Titel "Unternehmen Zufall" (nebenbei bemerkt eine empfehlenswerte Lektüre). Kommen wir zu dem Zufall, der uns im Zusammenhang mit der virtuellen Maschine interessiert. Atari fing 1985 damit an, die Computer der ST- Serie mit großem Erfolg in Deutschland zu verkaufen. Bis 1990 waren etwa eine Million davon an den Mann gebracht. Daher gab es auch eine rege Tätigkeit bei den Softwareentwicklern, die dazu führte, daß es für nahezu alle Anwendungen eine reichhaltige Auswahl an Software entstand. Vom C-Compiler bis zur Textverarbeitung alles da. Dann konnte Atari der Entwicklung des Marktes nicht mehr folgen. Der Erfolg, der sich auf die Umsetzung des Mottos "Power without the price" stützte, begann zu schwinden. Schließlich stellte man 1994 die Produktion der Computer ein. Nachbauten kamen auf den Markt, die jedoch mit demselben Problem zu kämpfen haben, nämlich dem Preis, der einfach verglichen mit den Massenprodukten anderer Hersteller zu hoch ist. Da das Arsenal an Software aber noch genauso da ist wie eine große Masse von Anwendern, denen ihre Software aus guten Gründen ans Herz gewachsen ist, folgte ein logischer Schritt: Die virtuelle Maschine wurde geboren. Mit MagiC-Mac und MagiC-PC läuft MagiC auf Apple-Macintosh-Computern bzw. auf PCs mit Windows 95 (oder Windows NT für Intel-Maschinen). Das hat einige Vorteile:
Man fragt sich natürlich wo der Haken ist. Natürlich gilt auch für MagiC das, was eingangs erläutert wurde. Die Systeme haben unterschiedliche Eigenschaften. Dafür gibt es aber jeweils einen Emulationskern, der dafür sorgt, daß beispielsweise das völlig andere Dateisystem des Mac für MagiC genauso aussieht wie das unter Windows 95 oder das eines Atari. Sicher wird man sich fragen, wie sich das alles mit der Geschwindigkeit des Computers verträgt. MagiC ist ein hochoptimiertes System und die Programme, die darauf laufen, lassen sich auch ohne weiteres auf einem Rechner mit 8 MHz 68000er-Prozessor verwenden, nämlich einem alten Atari. Die Geschwindigkeit einens solchen Rechners nachzuahmen ist mit heutigen Prozessoren sehr leicht. Daher ist MagiC-Mac zum Beispiel bis zu zehnmal schneller als auf einer solchen Maschine. Die Performance aller Anwendungsprogramme kann sich sowohl unter MagiC-Mac als auch unter MagiC-PC sehen lassen. Während die meisten Betriebssysteme immer fetter, träger und behäbiger werden, ohne wesentlich mehr zu leisten, ist MagiC nach wie vor ein gertenschlankes System, das gerne das Wirtssystem für sich schuften läßt. Ferner ist es so, daß MagiC-Programme in der Regel keine speicherfressenden Monster sind. Welche Windows-Textverarbeitung kann schon für sich in Anspruch nehmen, mit eineinhalb Megabyte RAM auszukommen, welche Windows-Datenbank könnte das? In 8 MB MagiC- Systemspeicher passen zur gleichen Zeit locker die Textverarbeitung Signum!4, das Tabellenkalkulationsprogramm Texel, die relationale Datenbank Phoenix, das Grafikprogramm Papillon und das eine oder andere Utility, wie zum Beispiel PLZ-Postfix zum Nachschlagen der Postleitzahlen. Das ganze Office also sozusagen auf einmal. Das bedeutet aber auch, daß man nicht im Zweimonatsrhytmus einen neuen Computer braucht, weil die neue Version des Betriebssystems fällig ist oder ein neues Anwendungsprogramm den Rechner fast zum Stillstand bringt. |
||