Sie befinden sich auf http://www.henning-thielemann.de/Programs.html.
Forsche Seite Lockere Seite english deutsch

Meine Programme

" Um aus Fehlern lernen zu können
muss man erst einmal welche machen. "

Um eins gleich klarzustellen, hier gibt es keine Softuähr für Uindouhs oder solchen Käse, sondern nur echt coole Programme , mit ordentlicher Bedienoberfläche und dergleichen. Wer damit nicht klarkommt, sollte jetzt umkehren, denn es ist die letzte Chance.

Einige meiner Werke kann man übrigens auch im Aminet abgreifen.

" Ein Programm, das nicht abstürzt,
wird nur nicht richtig benutzt "

Kommen	Sehen	Siegen
Assampler	Was soll ich denn damit? Noch nie war Klangbearbeitung so kompliziert!	Gib vorsichtshalber mal her
Assampler debug Version	Ich? Fehler suchen? Niemand ist perfekt! Wahrscheinlich nicht mal der.	Wenn's sein muss
DelfLuxe	Klingt ja komisch Schicke Klangeffekte mit der Soundkarte Delfina	Das will ich haben
DelfSetPipeMui	Ist es das, was ich denke? Schafft die richtige Verbindung zwischen den Effektmodulen auf der Delfina.	Darauf warte ich schon lange
NomenEstOmen	Wofür brauch ich denn das? Überlasst doch dem Amiga die organische Nomenklatur!	Das wollte ich schon immer!
FotoBestellung	Was ist das? Fotonummern auszählen, ausdrucken, zuordnen	Her damit!
MasterMindSolve	Kann man das essen? Verschiedene Algorithmen zum Knacken von MasterMind-Codes	Reich mal rüber!
Compare	Was soll das schon sein?! Dateien und Verzeichnisse vergleichen	Muss ich haben!
SplitFile	Kurzbeschreibung Datei auf mehrere Datenträger verteilen	Herunterladen
StripUmlauts	Kurzbeschreibung Deutsche Umlaute in ae, oe, ue usw. konvertieren	Herunterladen
StripCRLF	Kurzbeschreibung PC-typische Zeilenenden (CR+LF) durch normale LFs ersetzen	Herunterladen
MemTest	Kurzbeschreibung Speichertest	Herunterladen
TableGroup.mcc	Kurzbeschreibung Verbessertes Anordnen in MUI-Spalten-Gruppen	Herunterladen
Wheel.mcc	Kurzbeschreibung Drehregler ähnlich denen an Musik-Keyboards	Herunterladen
sound.datatype- Entwurf	Beschreibt Unterstützung von 16 Bit, stereo und HD-Edit	Zeig mal
Module für Cluster	ständig unaktuell
MUI Interface	Kurzbeschreibung	Herunterladen
Kick3.0 Interface	Kurzbeschreibung	Herunterladen
Eigene Module	Kurzbeschreibung	Herunterladen
Auswertung von Fragebögen	Kurzbeschreibung	Herunterladen

Die Programmiersprache Cluster

"Müßiggang ist aller Cluster Anfang"

oder

"Andere nennen es Faulheit, ich nenne es Effizienz."
(frei nach Dr. Armin Kramer, seines Zeichens Mathelehrer am GCG)

Wer eine Programmiersprache sucht, die flexibel und elegant ist, und wer damit leben kann, dass die dabei entstehenden Programme nicht auf jedem anderen Rechner übersetzt werden können, der ist mit Cluster ideal versorgt. Denn kleine Programme gehen mit den mitgelieferten Standardmodulen schnell von der Hand. Ob angeforderte Resourcen wirklich bereitgestellt werden konnten, muss man nicht explizit testen, weil es durch Ausnahmen angezeigt wird. Bei der Freigabe dieser Resourcen assistiert einem das Resource-Tracking. Dieses System ist etwas schlichter gestrickt als ein Garbage-Collector z.B. der von Modula-3, und kann bei unachtsamer Benutzung leider dazu führen, dass Resourcen zu früh oder mehrmals freigegeben werden. Cluster unterstützt den Programmierer in guter Modula-Tradition bei großen Projekten durch Modularisierung und Objektorientierung. Bei der Objektorientierung war Cluster sogar Vorreiter auf dem Amiga, aber das interessiert natürlich keinen mehr, seit sich auch auf dem Amiga C++ etabliert hat. Die Amiga-Programmierung wird speziell durch Shared-Libraries (bei Benutzung wie bei Eigenentwicklung) und Tags (mit statischem Typentest) unterstützt. Als gelungenes Experiment kann man die Zusammenführung von Modulas WHILE-, IF- und CASE-Konstrukten in mächtigen WHILE- und IF-Strukturen bezeichnen. Dann gibt es da noch Kleinigkeiten von großer Bedeutung, die man in anderen Sprachen vergeblich sucht: Lokale Prozeduren als Rückruf-Prozeduren (mit allen Konsequenzen), generische Module ohne Codevervielfältigung, Methoden auf Records, erweiterbare Records, umfassenderes Handling offener Typen (CLASSPTR) und und und ...

Vom Vokabular her ist Cluster ein Nachfolger von Modula-2 (der derzeitige Compiler schluckt auch puren Modula-II-Code), aber eben noch mit einigen Besonderheiten anderer Sprachen gespickt, z.B. dem Exception-Handling aus Ada. Daher auch der Name Cluster. Selbst im C-basierten Betriebssystem des Amigas findet man sich mit Cluster problemlos zurecht. Die Schnittstellen-Module für die Amiga-Bibliotheken sind doch den C-Includes an Klarheit und Übersichtlichkeit locker überlegen, oder? Das Argument der C-Verfechter, auf dem Amiga besser mit der Betriebssystem-Sprache zu programmieren, ist nur in sofern von Belang, dass man sich als Nicht-C-Programmierer selbst um die Übersetzung der Schnittstellen kümmern muss. Ansonsten braucht man in Cluster überhaupt keine Abstriche zu machen. Im Gegenteil, das meiste wird stark vereinfacht. Ich denke da nur an die Eröffnungszeremonien von Exec-Devices.

Aus heutiger Sicht (2003-10-19) muss ich trotzdem kritisch bemerken, dass in Cluster viel Zucker eingeflossen ist, der die Sprache etwas umfangreicher werden ließ, als das ebenso mächtige Modula-3. Man braucht etwas Zeit, um elegante und sparsame Sprachentwürfe schätzen zu lernen. Wer versucht C++ vollständig zu begreifen, wird vielleicht eher dahin gelangen! Außerdem verweilt Cluster noch auf dem Sicherheitsniveau von Modula-2, das heißt, dass man Programmabstürze nicht sicher ausschließen kann. In Modula-3 dagegen kann man dies tatsächlich, kann aber trotzdem effiziente Techniken unter Aufgabe dieser Sicherheit einsetzen. Dieser Spagat war nicht so einfach zu bewältigen und Modula-3 steht damit auch ziemlich alleine in der Programmiersprachenwelt da.

Hören wir nun einen Auszug aus der Promotionsarbeit von Dr. Frank Brandau mit Leerstuhl in Aachen. Ok, vergesst den Titel und den ganzen anderen Schmus. Jetzt kommt jedenfalls die Geschichte aus der Sicht eines Cluster-Programmierers erster Stunde, seit dem 1999-10-21 zusätzlich mit Korrekturen von Thomas Pfrengle, einem der Autoren von Cluster:

"Sicherlich ist C nicht so elegant wie Cluster und auch C++ bietet nicht die Möglichkeiten, die Cluster zur Verfügung stellt. Mir wurde schon einige Male von Professoren gesagt, die Dinge, die ich in Cluster mache, seien informationstechnisch unmöglich ;)"

Entwickelt wurde Cluster vom StoneWare alias Thomas Pfrengle und Ulrich Sigmund. Später sind sie auf X-Pert gestoßen und wurden gebeten, EGS zu entwickeln. Im Zusammenhang damit entstand das Viona-Team. "Dieses hat für X-Pert damals eine Graphikkarte entwickelt, die sagenumwobene Visiona. Viele halten diese Karte für ein Gerücht, wenige wissen mittlerweile etwas darüber. Da diese Karte aber in meinem Rechner läuft und sehr nette Eckdaten aufweist (Gallium-Arsenid Prozessor mit 135MHz, 4MByte VRam mit 15ns Zugriff), bin ich mir der Existenz dieser Karte sehr sicher (Kostenpunkt 4.000 DM, Anm. von Henning). Wenn man das Alter der Visiona berücksichtigt und dann daneben hält, das ein SetPixel immer noch schneller arbeitet als eine CyberVision64 (Leider fehlt ein Blitter auf der Karte, scrolling ist gnadenlos langsam), die Auflösungen eigentlich alles schlagen was vorhanden ist (z.B. 8000x4000 in s/w, nun, wer's braucht :), dann kann man sich doch vorstellen, was das Viona Team leistete. Um nun ein Betriebssystem für die Visiona zu schreiben (EGS), hat man keine geeignete Sprache im Amiga Markt gefunden. Daher hat man dort Cluster entwickelt und die Nähe zur praktischen Anwendung bedingte auch die Mächtigkeit von Cluster. Aus mir bekannten Gründen haben sich das Viona Team und X-Pert zerstritten und Viona verließ X-Pert.

Eigentlich sollte der Visiona ein EGS-Cluster beiliegen, aber die Rechte für Cluster lagen nicht bei X-Pert, nur die Visiona hat das Viona Team nicht mehr herausbekommen. Doch X-Pert hat Cluster immerhin vertrieben und kurze Zeit später war ich stolzer Besitzer der Version 1.0. X-Pert hat den Laden dann langsam in die Pleite bugsiert, Cluster wurde nicht mehr vertrieben und als ProDev die Arbeit an Merlin übernahm, war Cluster praktisch nicht mehr von Bedeutung. Die Entwicklung für GVP, die Viona dann geleistet hat, wurde aber dadurch bestimmt, dass EGS nicht mehr nur in Cluster geschrieben wurde. Allerdings hat Ulrich Sigmund weiterhin an Cluster gearbeitet und irgendwann vertrieb DTM dann Cluster 2.0. Eine reife Leistung, arbeitete Cluster doch vollständig objektorientiert, eine Neuerung, die damals praktisch unbekannt war. DTM hat allerdings so gut wie keinen Support geleistet, die Arbeit an Cluster wurde Viona überlassen, da DTM aber Hauptdistributor für GVP-Produkte war, wurde auch Cluster weiterhin im Vertriebsprogramm gehalten. Der Amiga war zu dieser Zeit noch auf dem Höhepunkt seiner Laufbahn, aber ernsthafte Anwendungen standen damals nicht im Vordergrund. So gab es nur wenige Leute, die programmieren wollten. Einsteigerprodukte waren Lattice und Aztec C, viele lernten C und Cluster wurde nur von wenigen beachtet, die schon einen ausreichenden Überblick auf die vielfältigen Programmiersprachen hatten. Als GVP anfing, sich zurückzuziehen, wurde die Finanzlage bei DTM kritisch, der abzusehende Zusammenbruch von Commodore tat sein übriges dazu. Cluster wurde dann nur noch als kleines Nebenprodukt gehandelt, was seiner Verbreitung arg geschadet hat. Modula-2 und das neue Oberon wurden an Schulen und Universitäten gelehrt, wer sich mit Wirth's Müll herumschlagen musste, nahm die Umsetzungen für seine Amiga. Professionelle Programmierer erkannten schnell die Vorteile von C und arbeiteten damit, so entwickelten sich die Bedeutungen dieser beiden Sprachstämme. Cluster geriet damit völlig ins Abseits, entwickelt als Sprache für Entwickler, die aber C benutzten, brauchbar für Informatiker, die aus Kompabilitätsgründen aber Modula oder Oberon brauchten.

Letzter Punkt dieser traurigen Entwicklung war dann M.O.M. Dort wurde der Support für EGS übernommen, da das Viona-Team faktisch nicht mehr existierte. Damit kam auch die Entwicklung von Cluster zu M.O.M. (Und ich bekam endlich einen schon lange fertigen Treiber für EGS7 für die Visiona und konnte die Karte endlich dauerhaft als WB-Emulation einsetzen). Der Programmierer bei M.O.M. war von Cluster sehr angetan, und setzte einigen Enthusiasmus in das Projekt. Daraus resultierten dann die überarbeiteten 3.0/3.1 Includes, die dies auch bitter nötig hatten. Allerdings gab es keinerlei Resonanz mehr auf EGS, es war aufgebläht und fehlerbehaftet, Gerüchte um RTG und die neue CyberGraphics-Emu haben EGS den Rest gegeben. Ebenso erging es Cluster, die Spache war zu unbekannt und nicht verbreitet. Sprachpakete wie StormC haben Cluster schon seit einiger Zeit den Rang abgelaufen."

Tja, was macht man nun mit dieser Situation? Seit ich auch mit Linux intensiver Kontakt pflege, ist auch für mich Portabilität wichtiger geworden. Cluster hat in diesem Punkt leider sehr schlechte Karten, da der Compiler ziemlich direkt übersetzt. Die Entscheidung zwischen Effizienz und Flexibilität wurde bei Cluster ganz klar zu gunsten der Effizienz gefällt. Inzwischen verspreche ich mir mehr davon, Cluster-Programme in Modula-3 zu übersetzen. Das geht allerdings nicht vollständig automatisch, auch die ähnliche Syntax hilft nicht wirklich, denn Bezeichner, Verzeichnisstruktur etc. folgen in Modula-3 anderen Konventionen. Aber mit entsprechenden Sprachanalyseprogrammen wie m3coco ließe sich die Übertragung von Cluster zu Modula-3 zumindest vereinfachen. Und falls es euch beruhigt: Modula-3 hat auf anderen Rechner die gleichen Akzeptanzprobleme wie Cluster.

Die (alte originale) Cluster-Demo könnt Ihr auch gleich eintüten. Folgende Komponenten nach Wichtigkeit sortiert gibt's:

DemoEditor.lha (177K) Den leicht gehandicapten Editor+Compiler

Modules.lha (532K) Den Grundstock an Modulen

SprachReport.lha (34K) Die Sprach-Definition

Space.lha (109K) Ein Vektorgrafik-Bei-Spiel in Cluster

Handbuch.ps.gz (1769K) druckreif Das Buch zum Film

Handbuch_2up.ps.gz (1795K) zweispaltig und druckreif

Handbuch.pdf (5267K) nicht ganz optimal
(blaue statt fetter Schrift bei Programtexten)

Screenshot of the Cluster editor

An dem mitgelieferten Editor, der die integrierte Entwicklungsumgebung darstellt, scheiden sich seither die Geister. Für Besitzer von Grafikkarten sicher keine große Freude, ist er für Amigas, die noch auf AGA/ECS angewiesen sind, eine schöne kompakte Arbeitsumgebung. Wer die Vorzüge seiner Grafikkarte nutzen möchte, kann aber mit der ARexx-Version des Compilers und seinem Lieblingseditor oder dem mitgelieferten Editor 'HiTex' (nicht so das wahre) arbeiten.

Wer sich für Cluster interessiert, interessiert sich vielleicht auch für verwandte Sprachen aus dem Pascal-Zweig, wie Modula-3 (auf Amiga nicht verfügbar), Modula und Oberon, Cyclone und der PD-Serie AMOK zu schauen. Artikel über Cluster in der c't 01/1992

Das Magic User Interface

Was gibt es zu MUI zu sagen? MUI ist ein Bedienoberflächensystem, dass den Programmierer über eine objektorientierte Schnittstelle auf etliche Betriebssystemfunktionen für die Benutzerführung zugreifen lässt. Am auffälligsten sind dabei die Fähigkeiten von MUI-Oberflächen, sich Zeichensatz- und Fenstergröße anzupassen und im Aussehen sehr frei konfigurieren zu lassen. MUI bekommt man am einfachsten im Aminet (Verzeichnis util/libs) oder auf der (lange nicht mehr aktualisierten) SASG-Seite . Dort steht auch, was MUI alles kann. Für angehende MUI-Programmierer, und alle, die glauben, es schon zu beherrschen, ist die MUI-Mailing-Liste eine unentbehrliche Anlaufstelle.

In der Grundeinstellung präsentiert sich MUI wie das originale GadTools-System. Seine ganzen Fähigkeiten stellt MUI erst in den Dienst des Benutzers, wenn dieser die Shareware-Gebühr entrichtet hat. So dachte ich, dass kein Benutzer Schwierigkeiten beim Umstieg vom Standard-GUI zu MUI haben sollte. Ich wurde eines Besseren belehrt. Es gibt doch etliche Benutzer, die sich daran stören, dass MUI stark modularisiert ist, dass man so viele Sachen konfigurieren kann, dass es so groß ist und überhaupt.

Auch einige Programmierer scheinen eine intensive Antipathie gegen Freundlichkeit gegenüber dem Benutzer als auch gegen Arbeitserleichterung für sich selbst zu verspüren. Die einen machen sich weiterhin viel Arbeit mit GadTools und dem Bestimmen der Koordinaten der einzelnen Bedienelemente, andere bauen sich eigene Routinen, um hier wenigstens auf unterschiedliche Zeichensatz-Größen reagieren zu können. Wieder andere entwickeln gleich ein komplett neues GUI-System, das sie dann natürlich auch unter die Leute bringen wollen. Überflüssig zu erwähnen, dass so ein System immer "mindestens genauso gut wie MUI" ist (wenigstens wissen diejenigen, an wem sie sich messen müssen), weil es immerhin fontsensitiv ist. So wird argumentiert, aber dabei wird gerne übersehen, dass MUI viele Kleinigkeiten anbietet (Hintergrundmuster, vielfältige Einstellungen von Farben, Element-Rahmen, Tastenkürzeln, Reaktionen auf Benutzereingaben, AmigaGuide-Hilfe, ARexx-Anbindung, Commodities-Unterstützung etc.), die zu implementieren es einfach den Aufwand nicht wert wäre, kämen sie nur in einem einzelnen Programm zur Anwendung. Außerdem sollte man kein neues Projekt initiieren, wenn man nur das machen will, was andere schon erreicht haben. Da muss man schon was durchgreifend neues anbieten, um die investierte Zeit zu rechtfertigen.

Folgende zwei Beispiele für selbstgestrickte GUI-Systeme seien hier zur Abschreckung genannt: OctaMED und GoldEd. Ich würde sicher keine Worte darüber verlieren, sondern einfach zur Konkurrenz gehen, wenn es welche gäbe. Man darf das hier also durchaus als Wunsch nach entsprechenden Applikationen mit MUI-Schnittstelle verstehen. Leider haben die beiden Kandidaten neben der zweifelhaften Oberflächen-Philosophie ziemlich gute Funktionalität zu bieten. Aber sie sind nicht alleine, die Liste der GUI-Selbststricker ist lang und wird von kommerziellen wie Hobby-Programmierern bestritten. Sie alle aufzuzählen würde mich endgültig zum Nestbeschmutzer stempeln. :-)

OctaMED
Unser erstes Beispiel wurde dereinst von Teijo Kinnunen ins Leben gerufen und hatte sich unter den vielen Trackern als einer mit systemkonformer Benutzerschnittstelle und MIDI-Unterstützung profiliert. Dennoch war es nach fast zehn Jahren Entwicklung nicht verwunderlich, dass es dann nicht mehr einfach linear weiterging. Ob der Autor jetzt keine Lust mehr hatte, oder ob er in den PC-Bereich wechseln wollte - ich weiß es nicht, jedenfalls fiel OctaMED (irgendwann 1998 muss es gewesen sein) der Kato-Developer-Group in die Hände. Die hatte erstmal nichts besseres zu tun, als das ganze Programm umzukrempeln und unter anderem ein eigenständiges GUI-System zu entwickeln (worauf die Entwickler sehr stolz sind) das C++-Klassen benutzt, was für den Programmierer eine bequeme Handhabung bedeutet, für den Benutzer allerdings sinnlose Speicherverschwendung. Denn während GUI-Systeme in Exec-Library-Ausführung von jeweils mehreren Programmen genutzt werden können (bei konstantem Speicherverbrauch, da Exec-Bibliotheken immer von "shared libraries"), ist das bei statisch gebundenen Libraries unmöglich. Für den Anwender bedeutet das, dass in jedem Programm, das dieses System benutzt, alle benötigten Teile fest in den Programmcode eingebunden sind. Sollte das System tatsächlich in die Leistungskategorie von MUI aufsteigen, und zieht man die unbenutzten GUI-Elemente aus der Rechnung wieder ab, dürfte damit jedes dieser Programme immer noch um ein halbes Megabyte größer werden, als eine entsprechende MUI-Applikation. Ein Gegenbeweis zu dieser Behauptung steht noch aus, denn es gibt auch jetzt noch kein MUI-freies Programm, dessen Bedienoberfläche MUI das Wasser reichen könnte!
Aktuell (2001-08-21) sieht es so aus, dass es um die Wiederbelebung des OctaMED äußerst still geworden ist. Würde mich nicht wundern, wenn auch dieses Projekt beim Basteln an der äußeren Hülle steckengeblieben ist.

GoldEd
Der GoldEd (mit dem ich gerade diesen Text hier tippe) von Dietmar Eilert kann inzwischen auf eine längere Geschichte zurückblicken - ich glaube aber noch nicht ganz so lange, wie der OctaMED. Die Philosophie des GoldEds besteht in der absoluten Konfigurierbarkeit und der Unterstützung von Programmierern. Dazu gehört auch, direkt vom Editor aus die Programme ansteuern zu können, die Quelltexte zu übersetzen, HTML-Seiten anzeigen, Skripte ausführen etc. Da wäre es nur konsequent, das Konfigurationswunder GoldEd auf dem Konfigurationswunder MUI aufzubauen. Das passiert aber nicht. Der Programmierer hat keine Beziehung zu MUI und Punkt. Die Einstellerfenster sind daher nicht umgrößerbar, dafür wird die Mindest-Screen-Höhe auf 400 festgelegt, auf die der Editor eisern pocht. Das dürfte einen OCS/ECS-Besitzer wenig freuen. Dafür belehrt der Autor, dass das Programm ohnehin für Entwickler mit entsprechend aktuellen Maschinen gedacht ist. Selbst die werden aber keinen Spaß an einem GUI haben, das den Platz auf ihrem vielleicht noch größeren Bildschirm nicht vernünftig ausnutzt. Aber Halt! Demnächst wird auch Vergrößerbarkeit der Fenster implementiert, lässt er uns wissen. Da haben wir's den Entwicklern von frei verfügbaren GUI-Systemen aber wieder gegeben! Nur leider wird es bis dahin weitere Klassen und Extras für MUI geben, die GoldEd-Benutzern auf lange Zeit erspart bleiben. Toll wie der GoldEd-Autor für uns mitdenkt :-(

Wenn es nur die Vergrößerbarkeit der Fenster wäre, hätte ich den Texteditor hier nicht erwähnt. Das eigentlich ärgerliche ist, dass der GoldEd-Verfasser etwa seit der Version 3 (1999-04-23 waren wir bei Nummer 5) den Flitz hat, alle möglichen Bedienelemente selbst von Grund auf neu zu programmieren, das allerdings nur sehr halbherzig (recht luftig, daher platzverschwendend, dennoch ohne grafische Besonderheiten) und der Windows95-Stil ist auch nicht sehr originell. Hier kann man im direkten Vergleich sehen, wie viele Details in den entsprechenden MUI-Klassen verwirklicht sind. Die Liste der von Dietmar Eilert unnütz programmierten Bedienelemente umfasst bereits (in MUI-Äquivalenten ausgedrückt): Listtree.mcc, Popstring.mui, BetterString.mcc, Toolbar.mcc, TearOff.mcc, Registergroup.mui, Scroller in Fensterrahmen, (Kontext-)Menüs, Iconify, BubbleHelp, AmigaGuide-Hilfe. - Dafür hat jeder registrierte GoldEd-Benutzer bezahlt und sinnlos gewartet!

Wäre es wenigstens eine primitve GadTools-Oberfläche, könnte man ihr mit Patches wie MCP (Gadtools- und Stringgadget-Patch) zu Leibe rücken. Es bestände in Zukunft vielleicht gar die Möglichkeit die Oberfläche komplett auszuwechseln, so aber entzieht sie sich hartnäckig allen Verbesserungsmöglichkeiten.

Ich denke, dass diese Zeit- und Speicherverschwendung wie in den oben genannten Beispielen wirklich nicht sein muss, insbesondere da es bereits mehrere GUI-Systeme gibt, die auch zum Teil erweiterbar sind, als da wären: Neben MUI noch ClassAct, StormWizard (wurde von Haage&Partner mit ClassAct zum neuen GUI für OS3.5 zusammengeschraubt), Triton, bgui, gtlayout und wahrscheinlich noch weitere.

Was für einen Sinn hat es überhaupt, über Geschmäcker zu streiten? Kann nicht jeder sein bevorzugtes GUI-System benutzen? Warum eigentlich nicht - wenn die Funktionalität von der Benutzerschnittstelle getrennt wäre, wäre das auch meines Erachtens nach besser. Etwas in der Art wurde zum Beispiel für den Commodore-Installer-Ersatz InstallerNG von Jens Tröger & Jens Langner entwickelt. Ich sehe nur zwei Probleme:

Da sich viele Vorbehalte gegen MUI gegen dessen geringe Effizienz richten, wird dieses Konzept erst recht keinen Zuspruch finden, denn es benötigt noch mehr Resourcen.
Wenn diese Trennung von GUI und Funktionalität nicht vom Betriebssystem unterstützt wird, wird sich kein Standard durchsetzen können.

Trotzdem würde ich diese Lösung ganz klar begrüßen.

Im Folgenden habe ich alle Vorbehalte gegen MUI zusammengetragen, die mir im Laufe der Zeit begegnet sind. Oft sind es auch gar keine Vorbehalte konkret gegen MUI, sondern Rechtfertigungen für ein selbstgestricktes GUI, sprich Vorbehalte gegen alle existierenden GUIs auf dem Amiga. Ich mache mir überhaupt keine Illusionen, auch nur einen einzigen GUI-Selbststricker "bekehren" zu können, aber ich möchte hiermit wenigstens allen Leuten sagen, dass sie nicht grundlos meckern, wenn sie neue selbstgestrickte GUIs kritisch beäugen, und dass sie mit dieser Kritik auch nicht allein dastehen. Letztlich verbirgt sich hinter meiner These "Schreibt keine neuen GUIs!" (nur wenn sie so revolutionär sind, dass sie sich mit bestehendem wirklich nicht vereinen lassen) nur der Wunsch, dass die Programmierer ihre Kraft in gemeinsamen Projekten bündeln sollen. Das ist altmodisch, ich weiß. Hier ist die versprochene schwarze Liste:

Kontra MUI ist langsam. Die Reaktion auf Benutzeraktionen ist zu langsam für Echtzeit-Anwendungen. - Wir haben es ehrlich versucht!

Pro Kann ich nicht bestätigen. Ich habe MUI bereits auf meinem Amiga benutzt, als er noch mit 68000/14MHz ausgerüstet war und es gab keinen Unterschied zu GadTools. Das Vergrößern von Fenstern dauert natürlich, es muss schließlich die gesamte Anordnung der Grafikelemente neu berechnet werden. Was bei GadTools gar nicht ging, geht hier langsam. Na und?
Für Programmierer: Es gibt Tricks, um ernste Engpässe abzufedern. Das kann man natürlich nicht wissen, wenn man es nur mal eben versucht. Für solche kniffligen Fragen ist auch der E-Mail-Verteiler da!
Möglichkeiten zur Geschwindigkeitssteigerung sind z.B. nach Häufigkeit sortierte Methoden-Verteilung im Dispatcher, auch nicht überdefinierte aber häufig gebrauchte Methoden wie Set ganz vorne in das switch-Konstrukt schreiben und sofort an die Super-Klasse weiterreichen, binäre Suche der Methoden (manche Compiler optimieren switch bereits auf diese Weise), Umgehen von zeitintensiven Methoden - Set gehört zweifellos dazu; wenn man neu eingeführte Attribute oft im Sammelpack setzen und abfragen möchte, schreibt man dafür besser eine neue Methode.

Kontra MUI-Klassen sind eierlegende Wollmilchsäue und daher langsam und speicherintensiv.

Pro Geschwindigkeit, siehe oben. Speicherverbrauch, ebenfalls siehe oben. Der Speicherverbrauch wird dadurch wett gemacht, dass mehrere Programme den gleichen Code nutzen können. Ansonsten sprechen die vielfältigen Fähigkeiten der MUI-Klassen doch eher für MUI - wäre das nicht so, hieße die Kritik wahrscheinlich, MUI sei nicht leistungsfähig genug.

Kontra MUI ist fehlerhaft und stürzt gerne ab.

Pro Ich hatte mit MUI 3.8 überhaupt keinen Absturz mehr, der durch MUI verursacht wurde. Fast immer stellte sich heraus, dass es ein Fehler beim Benutzen von MUI war. Manch andere Ungereimtheit gibt es dennoch, bisher ließen sich alle umgehen und das in jedem Falle schneller, als deswegen ein komplett neues GUI zu entwickeln. Übrigens wird MUI von sehr vielen Leuten benutzt und damit intensiv getestet. Was man von nebenbei entwickelten GUI-Systemen nicht erwarten kann, obwohl sie nicht minder fehleranfällig sind.

Kontra MUI bietet die eine oder andere Klasse nicht, die ich dringend brauche. Oder die entsprechende Klasse kann nicht das, was ich benötige. Beispiel: Seitwärts Rollen in Listen.

Pro Zum einen können bestehende Klassen um neue Fähigkeiten erweitert werden. Zum anderen kann man die Klasse immer noch durch eine komplett neue ersetzen, sollte sich ersteres nicht bewerkstelligen lassen. Die anderen MUI-Programmierer würden solch eine Klasse wahrscheinlich auch begrüßen. Jedenfalls entwickelt man deswegen nicht gleich ein völlig neues GUI.

Kontra MUI braucht soviel Platten- und Speicherplatz.

Pro Es ist klar, dass ein umfangreiches System umfangreiche Daten mitbringt. Aber ich denke die 2.5 MB Plattenplatz sind gut angelegt. MUI ist sehr schön in Bibliotheken gegliedert und was nicht gebraucht wird, wird auch nicht eingeladen und nimmt daher keinen Speicherplatz weg. Nicht vergessen werden sollte, dass sich mehrere Anwendungen automatisch MUI teilen, so dass im Prinzip nur für das erste Programm der Speicher für MUI fällig wird, alle weiteren bekommen es gratis dazu.

Kontra MUI fährt die Windows-Philosophie "Programme optimieren? Du willst wohl die Hardwareentwickler arbeitslos machen?"

Pro Was soll das? Sollten GUIs etwa in Assembler verfasst werden?
Zur Windows-Philosophie gehört auch, dass jeder sein eigenes Süppchen kocht und sich keiner nach dem anderen richtet oder mit ihm zusammenarbeitet (was bedeuten würde, sich von dessen Weiterentwicklung abhängig zu machen). Erstaunlich dass jeder glaubt, sein Standard würde sich durchsetzen (=Geld, Macht, Ruhm!), obwohl er sich kaum von den anderen unterscheidet, geschweige denn die Fähigkeiten von allen Konkurrenten in sich vereint. Aber dieser Sachverhalt ist wohl eher mit selbstgestrickten GUI-Systemen vergleichbar als mit MUI.

Kontra Man macht sich als Programmierer von MUI und dessen Fortkommen abhängig. Außerdem sind MUI Programme stark systemgebunden und lassen sich nicht portieren.

Pro Das ist richtig aber es ist nur die halbe Wahrheit. Keiner soll glauben, dass sein Programm portierbar wäre, nur weil er kein MUI benutzt. Es ist ganz klar so, dass man bei leicht portieren Programmen keine Besonderheiten der betrachteten Plattformen ansprechen kann, vielmehr muss sich das Programm mit dem Minimum der Fähigkeiten aller Plattformen abfinden. Das geht für den Benutzer immer mit Einschnitten im Komfort her. Aber wir wollen doch maximalen Komfort, ich zumindest will das, warum dann nicht die Möglichkeiten des Systems, hier also Amiga, nutzen? Indem man die AmigaOS-Routinen direkt anspricht und einen Compiler mit Amiga-spezifischen Erweiterungen benutzt, tut man das bereits, MUI sowie jedes andere Amiga-GUI-System wäre lediglich ein weiterer Schritt, eine eventuelle Portierung (ja nur eventuell, wirklich vor hat es noch nicht mal jemand) zu erschweren. Für MUI gibt es z.B. unter Windoof gar kein Äquivalent. - Dürfen wir es deswegen auch nicht haben?
Nicht zuletzt kann man auch MUI-Programme durch strikte Trennung von GUI und Hauptprogramm einigermaßen portierbar halten, MUIBase demonstriert (auch wenn man es von außen nicht sehen kann), dass es möglich ist.
Es hat übrigens etliche Ansätze gegeben, MUI auf anderen Plattformen nachzuprogrammieren. Was aus den Projekten geworden ist, weiß ich nicht, aber wem es um Portierbarkeit geht, der kann sich dort sicher auch nützlich machen.

Kontra MUI kostet Lizenzgebühren, wenn man es in einem kommerziellen Programm verwendet.

Pro Die Entwicklung eines eigenen Systems kostet wohl keine Zeit und damit Geld?

Kontra MUI ist viel zu kompliziert.

Pro Der Vorwurf sollte besser lauten: Die Dokumentation ist veraltet! Macht das das System schlechter? MUI ist sehr logisch aufgebaut, und eigentlich nicht viel komplizierter als es bei diesem Umfang sein muss. Ist es dir dennoch zu kompliziert, ist Programmieren vielleicht nicht das richtige für dich?

Kontra Eine Oberfläche, die sich der Zeichengröße anpasst, bekomme ich in ein 30 kB-Programm, welches neben vielen anderen sogar auf eine Diskette passt.

Pro Für Spezialaufgaben gibt es natürlich immer eine effizientere Lösung.

Kontra Will man ein MUI-Programm benutzen, muss man erst von allen beteiligten externen Bedienelementen die neusten Versionen installieren.

Pro Das ist leider wahr. Ich sehe aber verschiedene Lösungsmöglichkeiten:

Programmierer sollten zu ihrem MUI-Programm, die externen Klassen in den benötigten Versionen mitliefern. Installiert werden sollten die Klassen nur, wenn sie neuer sind und die Benutzer sollten gewarnt werden, dass dadurch andere Anwendungen beeinträchtigt werden könnten, obwohl es eigentlich nicht sein darf. Experten muss erlaubt werden, diesen Schritt zu überspringen.

Jemand der viel Zeit hat (zum Beispiel einer, der genug Zeit hat, an eigenen GUIs zu basteln) könnte regelmäßig aktualisierte Klassenversionen bündeln. Vielleicht lässt sich auch ein Paketesystem wie RPM unter Linux etablieren, das das Aktualisieren vieler voneinander abhängiger Komponenten erleichtert. Noch besser wäre natürlich, wenn die Klassen vor Veröffentlichung ausgiebig getestet werden würden, dann bräuchte man nicht so oft Fehlerbereinigungen nachzuschieben.

Das Problem der Aktualisierungen ist kein reines MUI-Problem, es kommt bei Datatypes, Funktionsbibliotheken und Gerätetreibern vor und bei MUI fällt es besonders auf.

Kontra MUI hat konzeptionelle Schwächen.

Pro Stimmt. Aber den Vorbehalt musste ich jetzt selbst beisteuern. ;-) Manche Entwurfsentscheidungen stellten sich zu spät als ungünstig heraus. Manche Rückruffunktionen (Callback-Hooks) hätten besser durch Vererben und Überdefinieren ersetzt werden sollen. Das Notify-System ist etwas verstümmelt, das originale BOOPSI-Notify-System ist wahrscheinlich sauberer und mächtiger, wenn auch nicht ganz so leicht anzuwenden. In MUI kann Notify immer nur auf die Änderung eines Attributes reagieren und der Mechanismus zum Verhindern von Endlosschleifen ist nicht wirklich durchschaubar. Weitere Problem resultieren daraus, dass MUI nicht direkt ins Betriebssystem integriert ist. MUI wurde zwar in MorphOS und AmigaOS 4.0 integriert, aber es wirklich integriert ist oder nur beigelegt wurde, entzieht sich meiner Kenntnis.

Kontra Wir würden ja kein eigenes System entwickeln, wenn es nicht nötig wäre.

Pro Ich danke Ihnen für dieses Gespräch!

Falls jemand noch weitere Kontra-Punkte anführen kann - immer her damit! Ansonsten betrachte ich alle bisherigen Vorbehalte als reine Vorwände und Vorurteile von Leuten, die sich nie richtig mit der Materie beschäftigt haben. - Was der Bauer nicht kennt, isst er nicht.

Fazit: Glaub niemals einem Programmierer, der behauptet, er hätte keine Zeit. Er hält sich womöglich nur bei den falschen Dingen auf.

Links für Amiga-Software-Entwickler

"Um etwas entwickeln zu können,
muss man's erst einmal einwickeln."

Aus der Not, dass Anwender und Entwickler den Amiga nach und nach verlassen, entstanden einige Tugenden, mit denen sich die Arbeit der Entwickler viel effizienter gestalten lässt. Diese Initiativen sind wirklich mit dem Ziel angetreten, dem Amiga über die Durststrecke zu helfen, bis der Name Amiga wieder für bahnbrechende Innovationen steht. Obwohl diese Projekte auch über eine Entspannung der Lage hinaus erhaltenswert sind. Hier also meine Auswahl der Angebote, die ich für besonders wichtig halte:

Amiga Idea Site Tagtäglich wird unter Programmierern das Rad neu erfunden. Auf PCs wird das Problem durch Masse kompensiert: Wenn sich von einer Million Programmierer unabhängig voneinander jeweils tausend an ähnlichen Projekten schaffen, können immer noch tausend Probleme bearbeitet werden. Auf dem Amiga muss man die wenigen noch vorhandenen Energien bündeln, auch eine Art der Resourcenschonung, wofür Amigas ja bekannt sind (oder sein sollten). Wer sich beim 1000. Tetris-Clone, der keine Neuigkeiten zu bieten hatte, oder dem 100. fontsensitiven GUI-System, das angeblich viel absturzsicherer und schneller sein soll, als das oft geschmähte MUI, ärgerte, wofür Programmierer, die nie Zeit haben, ihre Zeit vergeuden, der sollte - ganz gleich ob Benutzer oder Entwickler - diese Seite ansteuern. Hier können Benutzer ihre Traum-Programme skizzieren und Programmierer Ideen für neue Projekte holen, die dann auch mit Sicherheit von wenigstens einem gebraucht werden.

Amiga Translator Organization Damit die Sprachanpassung von Programmen z.B. mit Hilfe der locales.library auch von Programmieren, nicht 20 verchiedene Sprachen fließend schreiben können, bewältigt werden kann, haben sich in der ATO Leute zusammengefunden, die mindestens zwei Sprachen beherrschen (meist Englisch und die Muttersprache), ihre bevorzugten Programme in ihrer bevorzugten Sprache benutzen wollen und die Übersetzungen koordiniert abwickeln.

Erstellt:	1997 Henning Thielemann
Mit HSC verarbeitet seit:	2001-07-31
Zuletzt geändert:	2010-04-15, 15:44
Überwachungszustand:

Hier noch ein paar schwachsinnige E-Mail-Adressen zur Fütterung von SPAM-Adresssammlern. Die Adressen sind mit Hilfe von Markov-Ketten zufällig aus realen Namen zusammengewürfelt und existieren mit sehr großer Wahrscheinlichkeit nicht.

DemoEditor.lha (177K)		Den leicht gehandicapten Editor+Compiler
Modules.lha (532K)		Den Grundstock an Modulen
SprachReport.lha (34K)		Die Sprach-Definition
Space.lha (109K)		Ein Vektorgrafik-Bei-Spiel in Cluster
Handbuch.ps.gz (1769K)	druckreif	Das Buch zum Film
Handbuch_2up.ps.gz (1795K)	zweispaltig und druckreif
Handbuch.pdf (5267K)	nicht ganz optimal (blaue statt fetter Schrift bei Programtexten)

Kontra	MUI ist langsam. Die Reaktion auf Benutzeraktionen ist zu langsam für Echtzeit-Anwendungen. - Wir haben es ehrlich versucht!
Pro	Kann ich nicht bestätigen. Ich habe MUI bereits auf meinem Amiga benutzt, als er noch mit 68000/14MHz ausgerüstet war und es gab keinen Unterschied zu GadTools. Das Vergrößern von Fenstern dauert natürlich, es muss schließlich die gesamte Anordnung der Grafikelemente neu berechnet werden. Was bei GadTools gar nicht ging, geht hier langsam. Na und? Für Programmierer: Es gibt Tricks, um ernste Engpässe abzufedern. Das kann man natürlich nicht wissen, wenn man es nur mal eben versucht. Für solche kniffligen Fragen ist auch der E-Mail-Verteiler da! Möglichkeiten zur Geschwindigkeitssteigerung sind z.B. nach Häufigkeit sortierte Methoden-Verteilung im Dispatcher, auch nicht überdefinierte aber häufig gebrauchte Methoden wie Set ganz vorne in das switch-Konstrukt schreiben und sofort an die Super-Klasse weiterreichen, binäre Suche der Methoden (manche Compiler optimieren switch bereits auf diese Weise), Umgehen von zeitintensiven Methoden - Set gehört zweifellos dazu; wenn man neu eingeführte Attribute oft im Sammelpack setzen und abfragen möchte, schreibt man dafür besser eine neue Methode.
Kontra	MUI-Klassen sind eierlegende Wollmilchsäue und daher langsam und speicherintensiv.
Pro	Geschwindigkeit, siehe oben. Speicherverbrauch, ebenfalls siehe oben. Der Speicherverbrauch wird dadurch wett gemacht, dass mehrere Programme den gleichen Code nutzen können. Ansonsten sprechen die vielfältigen Fähigkeiten der MUI-Klassen doch eher für MUI - wäre das nicht so, hieße die Kritik wahrscheinlich, MUI sei nicht leistungsfähig genug.
Kontra	MUI ist fehlerhaft und stürzt gerne ab.
Pro	Ich hatte mit MUI 3.8 überhaupt keinen Absturz mehr, der durch MUI verursacht wurde. Fast immer stellte sich heraus, dass es ein Fehler beim Benutzen von MUI war. Manch andere Ungereimtheit gibt es dennoch, bisher ließen sich alle umgehen und das in jedem Falle schneller, als deswegen ein komplett neues GUI zu entwickeln. Übrigens wird MUI von sehr vielen Leuten benutzt und damit intensiv getestet. Was man von nebenbei entwickelten GUI-Systemen nicht erwarten kann, obwohl sie nicht minder fehleranfällig sind.
Kontra	MUI bietet die eine oder andere Klasse nicht, die ich dringend brauche. Oder die entsprechende Klasse kann nicht das, was ich benötige. Beispiel: Seitwärts Rollen in Listen.
Pro	Zum einen können bestehende Klassen um neue Fähigkeiten erweitert werden. Zum anderen kann man die Klasse immer noch durch eine komplett neue ersetzen, sollte sich ersteres nicht bewerkstelligen lassen. Die anderen MUI-Programmierer würden solch eine Klasse wahrscheinlich auch begrüßen. Jedenfalls entwickelt man deswegen nicht gleich ein völlig neues GUI.
Kontra	MUI braucht soviel Platten- und Speicherplatz.
Pro	Es ist klar, dass ein umfangreiches System umfangreiche Daten mitbringt. Aber ich denke die 2.5 MB Plattenplatz sind gut angelegt. MUI ist sehr schön in Bibliotheken gegliedert und was nicht gebraucht wird, wird auch nicht eingeladen und nimmt daher keinen Speicherplatz weg. Nicht vergessen werden sollte, dass sich mehrere Anwendungen automatisch MUI teilen, so dass im Prinzip nur für das erste Programm der Speicher für MUI fällig wird, alle weiteren bekommen es gratis dazu.
Kontra	MUI fährt die Windows-Philosophie "Programme optimieren? Du willst wohl die Hardwareentwickler arbeitslos machen?"
Pro	Was soll das? Sollten GUIs etwa in Assembler verfasst werden? Zur Windows-Philosophie gehört auch, dass jeder sein eigenes Süppchen kocht und sich keiner nach dem anderen richtet oder mit ihm zusammenarbeitet (was bedeuten würde, sich von dessen Weiterentwicklung abhängig zu machen). Erstaunlich dass jeder glaubt, sein Standard würde sich durchsetzen (=Geld, Macht, Ruhm!), obwohl er sich kaum von den anderen unterscheidet, geschweige denn die Fähigkeiten von allen Konkurrenten in sich vereint. Aber dieser Sachverhalt ist wohl eher mit selbstgestrickten GUI-Systemen vergleichbar als mit MUI.
Kontra	Man macht sich als Programmierer von MUI und dessen Fortkommen abhängig. Außerdem sind MUI Programme stark systemgebunden und lassen sich nicht portieren.
Pro	Das ist richtig aber es ist nur die halbe Wahrheit. Keiner soll glauben, dass sein Programm portierbar wäre, nur weil er kein MUI benutzt. Es ist ganz klar so, dass man bei leicht portieren Programmen keine Besonderheiten der betrachteten Plattformen ansprechen kann, vielmehr muss sich das Programm mit dem Minimum der Fähigkeiten aller Plattformen abfinden. Das geht für den Benutzer immer mit Einschnitten im Komfort her. Aber wir wollen doch maximalen Komfort, ich zumindest will das, warum dann nicht die Möglichkeiten des Systems, hier also Amiga, nutzen? Indem man die AmigaOS-Routinen direkt anspricht und einen Compiler mit Amiga-spezifischen Erweiterungen benutzt, tut man das bereits, MUI sowie jedes andere Amiga-GUI-System wäre lediglich ein weiterer Schritt, eine eventuelle Portierung (ja nur eventuell, wirklich vor hat es noch nicht mal jemand) zu erschweren. Für MUI gibt es z.B. unter Windoof gar kein Äquivalent. - Dürfen wir es deswegen auch nicht haben? Nicht zuletzt kann man auch MUI-Programme durch strikte Trennung von GUI und Hauptprogramm einigermaßen portierbar halten, MUIBase demonstriert (auch wenn man es von außen nicht sehen kann), dass es möglich ist. Es hat übrigens etliche Ansätze gegeben, MUI auf anderen Plattformen nachzuprogrammieren. Was aus den Projekten geworden ist, weiß ich nicht, aber wem es um Portierbarkeit geht, der kann sich dort sicher auch nützlich machen.
Kontra	MUI kostet Lizenzgebühren, wenn man es in einem kommerziellen Programm verwendet.
Pro	Die Entwicklung eines eigenen Systems kostet wohl keine Zeit und damit Geld?
Kontra	MUI ist viel zu kompliziert.
Pro	Der Vorwurf sollte besser lauten: Die Dokumentation ist veraltet! Macht das das System schlechter? MUI ist sehr logisch aufgebaut, und eigentlich nicht viel komplizierter als es bei diesem Umfang sein muss. Ist es dir dennoch zu kompliziert, ist Programmieren vielleicht nicht das richtige für dich?
Kontra	Eine Oberfläche, die sich der Zeichengröße anpasst, bekomme ich in ein 30 kB-Programm, welches neben vielen anderen sogar auf eine Diskette passt.
Pro	Für Spezialaufgaben gibt es natürlich immer eine effizientere Lösung.
Kontra	Will man ein MUI-Programm benutzen, muss man erst von allen beteiligten externen Bedienelementen die neusten Versionen installieren.
Pro	Das ist leider wahr. Ich sehe aber verschiedene Lösungsmöglichkeiten: Programmierer sollten zu ihrem MUI-Programm, die externen Klassen in den benötigten Versionen mitliefern. Installiert werden sollten die Klassen nur, wenn sie neuer sind und die Benutzer sollten gewarnt werden, dass dadurch andere Anwendungen beeinträchtigt werden könnten, obwohl es eigentlich nicht sein darf. Experten muss erlaubt werden, diesen Schritt zu überspringen. Jemand der viel Zeit hat (zum Beispiel einer, der genug Zeit hat, an eigenen GUIs zu basteln) könnte regelmäßig aktualisierte Klassenversionen bündeln. Vielleicht lässt sich auch ein Paketesystem wie RPM unter Linux etablieren, das das Aktualisieren vieler voneinander abhängiger Komponenten erleichtert. Noch besser wäre natürlich, wenn die Klassen vor Veröffentlichung ausgiebig getestet werden würden, dann bräuchte man nicht so oft Fehlerbereinigungen nachzuschieben. Das Problem der Aktualisierungen ist kein reines MUI-Problem, es kommt bei Datatypes, Funktionsbibliotheken und Gerätetreibern vor und bei MUI fällt es besonders auf.
Kontra	MUI hat konzeptionelle Schwächen.
Pro	Stimmt. Aber den Vorbehalt musste ich jetzt selbst beisteuern. ;-) Manche Entwurfsentscheidungen stellten sich zu spät als ungünstig heraus. Manche Rückruffunktionen (Callback-Hooks) hätten besser durch Vererben und Überdefinieren ersetzt werden sollen. Das Notify-System ist etwas verstümmelt, das originale BOOPSI-Notify-System ist wahrscheinlich sauberer und mächtiger, wenn auch nicht ganz so leicht anzuwenden. In MUI kann Notify immer nur auf die Änderung eines Attributes reagieren und der Mechanismus zum Verhindern von Endlosschleifen ist nicht wirklich durchschaubar. Weitere Problem resultieren daraus, dass MUI nicht direkt ins Betriebssystem integriert ist. MUI wurde zwar in MorphOS und AmigaOS 4.0 integriert, aber es wirklich integriert ist oder nur beigelegt wurde, entzieht sich meiner Kenntnis.
Kontra	Wir würden ja kein eigenes System entwickeln, wenn es nicht nötig wäre.
Pro	Ich danke Ihnen für dieses Gespräch!