Entweder gestaltet man den Zeichensatz von vornherein so, daß die Zeichen dann an anderer Stelle liegen, oder die Zeichen des Dateinamens werden in einer Stringroutine "petscii_dateinamen_konvertieren" übersetzt. Ist programmtechnisch kein großes Problem. Letzteres würde ich bevorzugen, damit sich bei Sortierungsaktionen die sortierte Reihenfolge ähnlich verhält wie bei den ISO-8859 Namen.
Ja sicher, so könnte man das lösen - das ist das, was ich mit "dritte Lösung" (zusätzlich zu normalem PETSCII und proportionalem ISO) meinte. Wäre mir halt zu viel Aufwand, nur um Proportionalschrift anzeigen zu können.
Weitere Vorteile hat der Einsatz des (neuen) System-Zeichensatzes in dieser Situation ja nicht. Eher Nachteile, weil er mich bei der Wahl der zur Verfügung stehenden Zeichen einschränkt - nur die PETSCII-Zeichen, die auch in ISO vorkommen, können angezeigt/genutzt werden.
Es kommt immer darauf an, mit welchem Datenträger man arbeitet. Würde es z. B. darum gehen, weitere Inhalte eines Roms darzustellen, könnte man durchaus das Inhaltsverzeichnis modern unter Verwendung von ISO-8859 gestalten.
Mal abgesehen vom EasyFlash oder Tape-Lösungen sind C64-Laufwerke intelligente Laufwerke, auf deren Zeichensatz-Encoding ich keinerlei Einfluss habe. Macht es wirklich Sinn, in dem einen Sonderfall plötzlich neue Regeln für Dateinamen zu definieren ("Hier gehen Umlaute!")?
Vorher hattest Du angemerkt, daß bei einem Dateirequester, der PETSCII-Zeichen anzeigen soll, zusätzlich 2 kb verbraucht werden für einen Commodore-Zeichensatz. Der Witz dabei ist, daß diese 2 kb gar nicht so sehr ins Gewicht fallen, weil so ein Dateirequester mit ganz anderen Speicherproblemen zu kämpfen hat. Das Requesterprogramm an sich dürfte schon 1 kb oder mehr verschlingen, aber noch viel mehr die Speicherung der Dateinamen des Verzeichnisses. Angenommen die Dateinamen dürften 16 Bytes lang sein, und ein Verzeichnis hat maximal 256 Einträge, so kommt man schon auf 4 kb nur für die Liste der Dateinamen. Mit anderen Worten: Bei der Organisation des OS führt kein Weg daran vorbei, eine Art Speichermanagement einzurichten, welches im Bedarfsfall dafür sorgt, daß ausreichend Speicher für eine eingeschobene Aktion wie einem Dateirequester vorhanden ist.
Hilfe, schalt mal einen Gang runter - In einem Satz von "Speicher-Dialog" über "Segmentierung" zu "modernes Speicher-Management" 
Wie viele Dir-Einträge ich unterstützen will bzw. muss, lege ich vorher fest - 144 würde Sinn machen, so viel kann eine 1541 und auch meine CMD-HD konnte nicht mehr, IIRC. D.h. ich weiß auch vorher, wie viel Cache ich brauche. Cache brauche ich sowieso auch bei anderen Gelegenheiten (Bildschirminhalte zwischenspeichern) oder manchen Anwendungen (Undo-Speicher o.ä.) - also definiere ich ein oder zwei Bereiche fester Größe als Cache und definiere ein paar Rahmenbedingungen für die Nutzung durch Anwendungsentwickler.
Der Speichern-Dialog selbst verbraucht übrigens nur unwesentlich Platz. Er ist eine Kombination aus den Modulen "Verzeichnis laden", "Dialogfenster", "Listview" und "Knopfreihe" - alles Elemente, die das System bereits zur Verfügung stellt und die ständig im Speicher stehen müssen.
Das bedeutet zumindest, daß das OS in einer Art segmentierter Form vorliegen muß und nur immer bestimmte Teile geladen werden. Das könnte aber auch bedeuten, daß native Applikationen für dieses OS auf irgendeine Art segmentiert sein müssen.
Angenommen für den Requester werden 10 kb benötigt, wovon die meisten temporäre Daten sind und lediglich 1 kb aus Code besteht. Dann könnte man den Programmteil in den Bereich $c000..$cfff laden, sofern man diesen Bereich für Programmsegmente reserviert hat. Den großen Anteil der temporären Daten müßte man dann auf eine Art Stapel anlegen, d. h. Position und Lage sind nicht vorherbestimmt. Das vereinfacht die Anwendung des Segments aus einem Programm heraus. Nichtsdestoweniger kann es dazu führen, daß der Stapel überläuft und in den Code- oder Datenbereich der Applikation reinragt. Nun kann nach Beendigung des Requesters der Codeteil der Applikation durch erneutes Laden wiederhergestellt werden. Für das gezielte Laden von Einzelteilen muß die Applikation jedoch ebenfalls irgendwie segmentiert vorliegen. Oder das OS erkennt den Speicherbedarf und rettet den Speicher in ein externes Ram, wovon es anschließend wiederhergestellt wird.
Verstehe ich nicht. Es gibt X Kilobyte allgemeinen Daten-Cache, und Y Kilobyte Screen-Cache (vermutlich ein mal kompletter Bildschirminhalt). Den Screen-Cache nutzt nur das OS, wenn es Dialogfenster oder Menüs anzeigt. Der Daten-Cache wird abwechselnd vom OS oder der Anwendung genutzt, aber nie gleichzeitig: Der Anwendungsprogrammierer weiß, dass der Cache gelöscht werden könnte, wenn er irgendeine (oder einige bestimmte) OS-Routinen aufruft.
Wozu brauche ich den da Speichermanagement für den Daten-Cache? Das OS haut das Ding mit einem Directory voll, weil ich gerade einen Speichern-Dialog geöffnet habe, danach nutzt ihn die Anwendung als Undo-Speicher ("Änderungen beibehalten? J/N"), dann nutzt der Anwender ihn um das Accessory "Minesweeper" parallel zu meiner laufenden Anwendung auszuführen. Mit ein paar Einschränkungen ("Keine Laden/Speichern-Dialoge in Accessories") komme ich doch da prima ohne Speicher-Management aus?
Wenn ich das OS oder Anwendungen in einzelne Module aufteilen würde, dann definitiv nur so dass ich einen fixen Bereich definiere und dorthin Module lade. D.h. die am meisten genutzten Module liegen immer im RAM, zusammen mit einer Routine die weiteren Kram nach $MODUL_START lädt und ausführt, wenn er gebraucht wird. Ich denke das war auch das, was Retrofan im Sinn hatte mit seiner EasyFlash-Unterstützung.
KISS-Prinzip.
Auf jeden Fall ergeben sich folgende Forderungen an eine Entwicklung:
1.) Es muß festgestellt werden, wer hauptsächlich für das Speichermanagement verantwortlich ist: Applikation oder OS.
2.) Es muß festgestellt werden, wie der Speicherbedarf und die Speicherbelegung kommuniziert wird. (Welcher Speicher wurde überschrieben? Welcher Programmteil ist betroffen?)
3.) Ein Nachladen von Programmcode setzt zwingend voraus, daß entweder a) die Applikation in kleinen Segmenten auf einem Datenträger vorliegt, von wo aus sie relativ schnell restauriert werden kann. b) das OS im günstigen Fall auf einem Steckmodul-ROM vorliegt, von dem aus schnell Programmteile wie der Requester geladen werden können, c) als beste Lösung (weil transparent für die Applikation) das OS den Speicherinhalt von sich aus in ein externes Ram rettet und wiederherstellt.
Welche Fälle fallen dir denn ein, wo OS oder Anwendung den eigenen Speicherbedarf nicht fix vorhersagen können? Nur dann muss ich doch überhaupt solche Klimmzüge wie Speichermanagement machen?
Ich hätte jetzt gesagt eine Anwendung kriegt X Kilobyte freien Speicher, was sie damit macht ist ihre Sache. Eine eventuelle Segmentierung kann man ja mit entsprechenden OS-Routinen unterstützen, aber eine Notwendigkeit für Speicher-Management sehe ich einfach nicht.
Wenn du mit Windows 10 glücklich bist, ist Linux nichts für dich. Es ist anders . und hat damit von Anfang an keine Chance, da auf deiner Seite ja kein Leidensdruck herrscht.
