Hello, Guest the thread was called873 times and contains 49 replays

last post from Retrofan at the

Kein File-Requester in C64-Anwendungen

  • Weil da der "Plattformbesitzer" Vorgaben gemacht hat, wie Applikationen aussehen und sich bedienen lassen sollen. Bei den textbasierten Systemen gab es solche Vorgaben (anfangs) nicht, da konnte sich jeder selbst überlegen, wie er seine Benutzeroberfläche baut ohne auf andere achten zu müssen.

    Absolut richtig. Aber es ist auch noch etwas anders. Die Meisten sind damit zufrieden, und Änderungen sind eher "anstrengend", weil man gewohntes Terrain verlassen muss. Siehe Windows. Windows ist eigentlich fruchtbar, trotzdem sind die Meisten damit "zufrieden". Es geht irgendwie. Also warum sollte man sich umorientieren? Es gibt halt eine Menge Menschen die nehmen das was da ist, und machen sich keinen großen Kopf. Und man möchte möglichst nicht das verlieren, was man sich auf dessen Grundlage aufgebaut hat. Keiner möchte gerne wieder von "Null" anfangen, oder all seine Software "umbauen". Also macht man was man macht :-) Auch als es dann Windows gab, sind die Meisten doch lange bei MS-DOS geblieben. Vor allem die Spielehersteller.


    Im Grunde ist es doch immer das Selbe, jemand kommt und krempelt den Markt um, und wenn das immer mehr Menschen annehmen (iPod, iPhone, MacOS), sieht man mit der eigenen Software schnell ganz alt aus. Erst dann bewegen sich dann (müssen) auch die Letzten in diese Richtung.


    Apple und deren Idee von einer besseren Oberfläche/System war ein großer Glücksfall. Denn hier legt MacOS bei Windows immer wieder den Finger in die Wunde, und hat bei Windows schon viel bewirkt ;-) Aber natürlich ist auch bei MacOS nicht alles Gold was glänzt (siehe Tastaturkobinationen).


    Worüber ich mich nur bei all dem selbstlobenden KI-Präsentationen wundere ist... warum fliesst das nicht in das OS + Oberfläche ein? Also mal richtig tiefgreifend. Also Spracheingabe Pflicht, und das System assoziiert schon vorher was man eigentlich möchte , stellt eine Frage und verfrachtet die Bilder automatisch von... nach. Mir fehlt das was der Markt den Menschen vorgaukeln will (KI, KI, KI), und nur klein klein bis garnicht liefert. Wenn man KI drauf hat, wo bleibt das KI-Spielzeug? Wo bleiben die vielen coolen Helfer, die alles wie von selber auf "Befehl" machen?! Wo ist das alles, was die Maus für die Meisten so gut wie überflüssig machen könnte? Alexa alleine ist keine Lösung.


    Die Antwort lautet... es braucht wieder einen Vorreiter, der alle anderen wieder alt aussehen lässt ;-) und alle anderen aus der Bequemlichkeit reißt.

  • Auch bei den Betriebssystemen hatten erst die mit GUI (also allen voran der Macintosh) File-Requester und auch andere, nicht direkt mit Grafik assoziierte Funktionen, wie Cut/Copy/Paste oder beispielsweise auch programmübergreifende Druckertreiber im Angebot. Woher kam das wohl? Im Prinzip hätten doch auch textbasierte Betriebssysteme, wie MS-DOS oder CP/M solche Funktionen bieten können.

    Nein, MS-DOS beruht vom Prinzip her auf CP/M, und CP/M war ein terminal orientiertes Betriebssystem, da zu seiner Zeit nun einmal die Rechner so aufgebaut waren. "Terminal" bedeutet jetzt nicht unbedingt, daß sich der Rechner in einem anderen Raum befand (z. B. im Keller) und man selber dann nur vor einem Bildschirm mit Tastatur saß. "Terminal" heißt auch, daß die Bildschirmausgabe damals von Geräten übernommen wurde, die von sich aus Funktionen wie Scrollen oder Cursorblinken übernahmen; es waren quasi "intelligente" Bildschirme wie z. B. das VT100. Um den Bildschirm zu löschen oder den Cursor zu setzen, mußte man bestimmte Folgen von Sonderzeichen (z. B. Escape-Sequenzen) an das Terminal schicken. Diese Steuercodes waren jedoch nicht normiert. Eine Art Standard entwickelte sich erst durch die Marktmacht von Unternehmen wie DEC. Im Grunde genommen wurde die Bildschirmausgabe genauso gehandhabt wie die Druckerausgabe, woraus sich ergibt, daß der Programmierer unter CP/M keinen direkten Zugriff auf einen Textspeicher hat, und ein freies Herumpoken oder diesen mal eben kopieren und später restaurieren ein Ding der Unmöglichkeit war.

    Folglich war es für einen Programmierer eben auch sehr schwierig, sowas wie eine Bildschirmmaske zu erstellen, die auf allen Bildschirmen funktionierte, denn der minimale Konsens bestand nur aus dem ASCII-Code für die darstellbaren Zeichen und ein paar wenigen Steuercodes wie Return. Schon bei den Codes für <Cursor-Rauf> oder <Cursor-Runter> gab es keine verbindliche Vorgaben, wie man auch noch an den Unterschieden zwischen den Homecomputern (Commodore, Apple//, CPC...) ablesen kann. Zusätzlich hatten Computer ohne Terminal nun das Problem, daß sie ein Terminal emulieren mußten, und standen vor der Frage, welches Terminal das sein soll und in welchem Umfang es nachgeahmt werden sollte. So gab es z. B. auf dem Apple// mit 80 Zeichenkarte und Z80-Modul Programme, die nicht ordungsgemäß liefen, da die Bildschirmausgabe einen bestimmten Terminaltyp voraussetzte. Auch darf man nicht vergessen, daß eine Terminalemulation wichtigen Speicherplatz belegt, der vom Arbeitsspeicher abgezogen wird. Aufgrund des geringen Speichers der damaligen Rechner bestand der Code des CP/M-Systems selbst nur aus ein paar Kilobyte, und jedes Kilobyte mehr für Bildschirmspeicher und Terminalemulation konnte bedeuten, daß ein Programm nicht mehr lief.

    obwohl all das auch ohne Bitmap-Darstellung möglich gewesen wäre

    Nein, leider war das auch mit einer textorientierten Ausgabe damals nicht so einfach möglich. Eigentlich setzt eine vernünftige Bildschirmmaske einen direkten Zugriff auf den Bildschirmspeicher voraus. Das war aber erst bei (Home)Computern der 80er gegeben.

    Im Grunde genommen macht auch das C64-Kernal nichts anderes als die Emulation eines Commodore-"Terminals". Es gibt wie bei CP/M zwei Sprungvektoren für die Ein- und Ausgabe von Zeichen, wobei die Ausgabe mit Hilfe von Steuercodes (auch in der Farbe) bestimmt werden kann. Auch hier zeigt sich ein Grundprinzip, welches bis heute in dieser oder ähnlicher Form weiterexistiert: Das System bietet "Kanäle" an, auf denen Zeichen hin- und hergeschickt werden. So gibt es da neben Ein- und Ausgabekanal z. B. noch den Fehlerkanal für Fehlermeldungen. Eine GUI hingegen bedeutet eine vollkommene Abkehr von diesem Kanalgedanken (, der damals die Rechner dominierte), denn eine GUI - auch wenn sie zeichen- und nicht bimapbasiert ist - benötigt eine komplexe Bibliothek aus mehreren Routinen. Für das Erscheinen einer GUI in den 80ern würde ich daher eher folgende Faktoren nennen:

    a) das Aufkommen günstiger Hardware (Speicher, CPU) sowie entschieden größere Datenträger,

    b) die Vorstellung einer Programmentwicklung in unabhängigen Modulen/Bibliotheken/Klassen. Dazu gehört nicht nur das spätere C++, sondern schon früher Modula-2 oder auch Smalltalk, welches rein zufällig ebenfalls bei Xerox entwickelt wurde.

    Was die Druckertreiber anbelangt, so gab es durchaus auch bei CP/M schon einen gewissen Abstraktionsgrad in der Form eines eigenen Ausgabekanals. Hierbei war es zumindest nicht mehr nötig zu wissen, auch welche Weise der Drucker hardwaremäßig mit dem Rechner verbunden war (serieller Anschluß, Parallelport...). Daß es keinen Druckertreiber im System selbst gab, lag wohl eher am kleinen Speicher. Es ging nun einmal nicht anders, als den Druckertreiber nur dann zu laden, wenn auch wirklich gedruckt werden sollte. Dieser konnte also kein Teil des BIOS sein, und das darauf aufbauende CP/M war auch nicht mehr als ein Dateiverwalter für ein bestimmtes Dateisystem. (CP/M und BIOS waren getrennt. S. BIOS bei CP/M-Computern.) Einen allgemeinen, fest eingebauten Druckertreiber konnte es also erst dann geben, als der Speicher groß genug wurde und Datenträger des Betriebssystems genügend Platz hatten, um mehrere Treiber für verschiedene Geräte mitzubringen. Nicht zuletzt mag es auch hier von Vorteil gewesen sein, daß einige Druckerhersteller eine gewisse Marktmacht erlangten, so daß sich andere Firmen nach deren Standard orientierten (s. Epsonkompatibilität).

  • DASS es so war, haben wir ja gesehen. Die Frage ging eher in die Richtung: Warum? Und zudem geht es nicht nur ums Aussehen, sondern ja auch beispielsweise um einheitliche Druckertreiber und Copy&Paste. Warum kam das alles (erst und zusammen) 1983/84 auf den Markt? Warum dachte man vorher, dass das nicht auch die Aufgabe eines mitgelieferten Betriebssystems sein könnte?

    Diese Frage lässt sich meiner Meinung nach genau so gut oder schlecht beantworten wie: "Warum wurde die Kernenergie nicht schon im Mittelalter genutzt? Es war doch alles da - Uran, natürliche Strahlung, ...". Oder die Frage, warum wir heutzutage nicht "beamen" können und keinen Warpantrieb benutzen.


    Dinge entwickeln sich und brauchen dafür Zeit. Benzin war früher ein Abfallprodukt und wurde in Apotheken zu Reinigungszwecken verkauft. Es ist müßig zu fragen, warum es nicht schon viel früher zum Antrieb von Fahrzeugen genutzt und stattdessen auf die Dampftechnik gesetzt wurde.


    Ja, ich weiß, nicht alles, was hinkt ist ein Vergleich. :D


    Man muss auch berücksichtigen: MS-DOS-Rechner kamen von IBM, IBM wollte damit ein mehr oder weniger intelligentes Terminal für seine Mainframes entwickeln. An einen eigenständigen PC dachte zumindest anfangs niemand. Und was man auch nicht vergessen darf: Der Benutzer kannte sein System. Er wusste, welche Dateien wo auf seinen Disks lagen und wie die hießen. 08/15-DAUs, die keine Ahnung haben, wo ihre Daten liegen (ich sag nur "Klaut" :rolleyes: ) gab es Anfang der 80er so gut wie keine. Das Konzept einer "strukturierten Ablage" war nicht nur im Papierbereich, sondern auch im EDV-Bereich noch sehr gängig; im Gegensatz zu heute, wo das Konzept "alles auf einen Haufen und durch die Suchmaschine jagen" lautet.


    Just my two cents.

  • Auch hier zeigt sich ein Grundprinzip, welches bis heute in dieser oder ähnlicher Form weiterexistiert: Das System bietet "Kanäle" an, auf denen Zeichen hin- und hergeschickt werden. So gibt es da neben Ein- und Ausgabekanal z. B. noch den Fehlerkanal für Fehlermeldungen.

    Dieses Grundprinzip ist auch heute noch sehr lebending als kleinster gemeinsamer Nenner für I/O. Zum Beispiel gibt die C (und auch die C++) Standardbibliothek dem Programmierer NUR darauf Zugriff, weil das eben JEDES System implementiert. Ist immer ganz lustig, wenn ein Neuling in diesen Sprachen sowas fragt wie "Wie lösche ich in C den Bildschirm?" oder "Wie bewege ich in C den Cursor?" -- und die richtige Antwort ist genaugenommen: "gar nicht". Jedenfalls nicht ohne irgendein zusätzliches (und natürlich meistens systemabhängiges) API für die Konsole. Ohne das gibt es nur die drei von dir genannten Streams, fertig.


    Zu dem inzwischen sehr erweiterten Thema gäbe es noch zu sagen: Das Aufkommen von "shared libraries" hatte damit sicher auch einiges zu tun. Denn genaugenommen wird sowas wie ein Dateidialog, oder auch ein Druckertreiber, niemals ein Bestandteil des Betriebssystems im engsten Sinn (also eines Kernels inklusive der absolut notwendigen userland tools) sein. Wohl aber einer wie auch immer gearteten "Plattform", und so etwas liefern ja z.B. Windows oder MacOS, oder auch fertig zusammengestellte Linux-Distributionen....


    Implementiert ist sowas dann aber in aller Regel in shared libraries, letztendlich ist es ja auch nur userspace code, der AUF dem Betriebssystem läuft. Das war beim AmigaOS so (z.B. intuition.library), das ist bei Windows so (COMDLG32.DLL), usw.


    Bei Druckertreibern gab es solche Verirrungen, die tatsächlich als Kernel-Treiber zu bauen, aber das war Unsinn. Drucker sind über Standard-Schnittstellen angeschlossen (für die bietet das OS natürlich Treiber), der Druckertreiber selbst ist dann eigentlich nur ein Filter, der irgendeinen Standard (oft Postscript oder PDF, auf Windows auch die Extralocke GDI) transformiert in ein Format, das der konkrete Drucker versteht.

  • Im Grunde genommen macht auch das C64-Kernal nichts anderes als die Emulation eines Commodore-"Terminals". Es gibt wie bei CP/M zwei Sprungvektoren für die Ein- und Ausgabe von Zeichen, wobei die Ausgabe mit Hilfe von Steuercodes (auch in der Farbe) bestimmt werden kann. Auch hier zeigt sich ein Grundprinzip, welches bis heute in dieser oder ähnlicher Form weiterexistiert: Das System bietet "Kanäle" an, auf denen Zeichen hin- und hergeschickt werden. So gibt es da neben Ein- und Ausgabekanal z. B. noch den Fehlerkanal für Fehlermeldungen. Eine GUI hingegen bedeutet eine vollkommene Abkehr von diesem Kanalgedanken (, der damals die Rechner dominierte), denn eine GUI - auch wenn sie zeichen- und nicht bimapbasiert ist - benötigt eine komplexe Bibliothek aus mehreren Routinen.

    Ok, das erklärt einiges.


    Für das Erscheinen einer GUI in den 80ern würde ich daher eher folgende Faktoren nennen:

    a) das Aufkommen günstiger Hardware (Speicher, CPU) sowie entschieden größere Datenträger,

    Wobei z.B. der erste Macintosh gar nicht so viel mehr Speicher besaß als einige 8-Bitter ohne grafisches Betriebssystem. 128 KB RAM (was natürlich knapp war und mit den Plus-Modell auf 512 KB angehoben wurde) und ein 400 KB Diskettenlaufwerk (von dem man sich besser gleich ein zweites zulegte, wenn man kein Diskjockey werden wollte). Auf dem Papier sah ein C128 mit 1571 kaum schlechter aus. Und die Lisa war mit ihren 5 MHz auch kein Rennpferd (auch wenn sicherlich die 16-Bit Architektur hilfreich bei der Verarbeitung diverser Betriebssystemfunktionen war).

  • Diese Frage lässt sich meiner Meinung nach genau so gut oder schlecht beantworten wie: "Warum wurde die Kernenergie nicht schon im Mittelalter genutzt? Es war doch alles da - Uran, natürliche Strahlung, ...".

    Meine Frage war vielleicht etwas ungenau. Das "Warum (nicht früher)?" war als "was haben C&P, Druckertreiber und Filerequester mit grafischen Systemen zu tun, dass sie erst und nur mit diesen zusammen auf die Menschheit losgelassen wurden" gemeint. Ich denke, M. J. konnte das ganz gut beantworten. Mit den grafischen Systemen wurde einfach sehr viel mehr über den Haufen geworfen als nur das augenscheinliche. Alle sahen damals nur die Maus und die Fenster – das wirklich Innovative lag aber eigentlich unterhalb der Oberfläche.

  • Wobei z.B. der erste Macintosh gar nicht so viel mehr Speicher besaß als einige 8-Bitter ohne grafisches Betriebssystem.

    Nur mal so als Vergleich: Der IBM PC hatte als Minimalausstattung 16 KB RAM, Modelle mit Diskettenlaufwerk (160KB Kapazität) hatten mindestens 64 KByte, was auch die Mindestanforderung für PC-DOS 1.0 war. Das BIOS in den ROMs ist gerade mal 8 KByte gross, davon ist 1KByte der Zeichensatz, der zur BIOS-Textausgabe im Grafikmodus verwendet wird. Die sonstigen Grafikfunktionen beschränken sich auf eine (IIRC recht langsame) setpixel-Funktion, ein zusätzliches Video-BIOS auf der Grafikkarte existierte damals nicht.


    Im Vergleich dazu ist selbst der ersten Mac mit 128KB RAM und 64KB ROM ziemlicher Luxus und selbst da war der Speicher knapp.

  • Hier ein Beispiel für einen File Requester auf dem PET/CBM

    Nicht, dass das hier jemand falsch "einsortiert": Die Software ist von 2004 – da hatten natürlich auch manche textbasierten Interfaces von den grafischen Systemen gelernt. Ich versuche ja auch immer bei den Softwares, an deren Entwicklung ich beteiligt bin, moderne Konzepte mit einzubringen, auch wenn die Hardware uralt ist.