Seh' ich auch so. Aber ich weiß nicht warum, meine Aussage istJoghurt hat geschrieben:Ich glaube, wir reden hier aneinander vorbei...
doch einfach und klar.
>>Wenn du nun dein Programm für VGA Karten geschrieben hast, müsstest du es für Herculeskarten umschreiben.<<
Eben nicht. Der Treiber der Graifkkarte wäre dann so
programmiert, daß das Mainboard direkt Op*nG* oder D*r*c*X
-Kommandos an die Grafikabteilung senden könnte.
Kommt eine neue Version von D*r*c*tX heraus, wird nur der
Treiber aktualisiert, oder er tut das selber (auch nicht schwierig).
Und, wichtig: Ich will die Treiber ja nicht abschaffen. Das geht
gar nicht. Nur anders verteilt müssen sie werden: nämlich
stets in das jeweilige Gerät eingebaut.
>>Der riesen Fortschritt bei CP/M war doch, dass dieses BS als Vermittler zwischen Hardware und Software auftrat.<<
Richtig.
>>Ein CP/M Programm, das für Z80 Prozessoren geschrieben war, lief unter (fast) jedem Z80 basierten Rechner, der CP/M hatte,<<
Sicherlich in der Theorie. In der Praxis gab es verschiedene
Versionen C*/M1.4, C*/M2.2, C*/M3.0, M*/M, die nicht ganz
kompatibel waren. Dazu undokumentierte Z80-Befehle.
Ein etwas größeres Programm, das auf Rechner A geschrieben
war, auf Rechner B zum Laufen zu bringen, war schwer, schon wegen
der unterschiedlichen Floppy-Formate. Aber bei kleineren Programme
wie k*rm*t oder d*t ging es -- der Überlieferung nach -- wohl.
>>Der große Vorteil vom Schritt weg zur direkten Kommunikation zur, wie du es nennst, Treiberkommunikation ist ja, das das System einfacher zu programmieren ist und weniger fehleranfällig.<<
Daran ändert sich an meinem Konzept kein gar nichts - die Treiber
sind nur woanders gespeichert und werden dezentral verwaltet.
>>Du kannst mir glauben, zu DOS Zeiten war das nicht gerade angenehm.<<
Glaube ich Dir ja.
Im Gegenteil. Es fallen 3 oder 4 Hierarchiestufen weg, durchInkompatibel ist der Ansatz ohne OS!
die sich heute ein Systemaufruf wie "show file selector dialogue" quälen muß, und wo nichts ist, sind auch keine Kompatibilitätsprobleme.
>>Im übrigen spricht sich moderene Hardware ja schon ab.<<
Das ist das Beginn eines Trends, der genau in die Richtung zielt,
die ich beschrieben habe. Damals DIP-Schalter und handinstallierter
Treiber, heute USB und Treiber von CD und morgen Hardware mit
eingebauter Treiberverwaltung und echtem Pl*g'n'Pl*y.
>>wenn jedes Teil genau eine Funktion hat, die UNIX-Philosophie: "do only one thing, but do it right".<<
Dieses Prinzip ist großartig. Nur sollte es auch auf OS angewandt
werden, denn diese erfüllen tausend Funktionen.
Eine Festplatte mit eingebauten Dateisystem und High-Level-Ansteuerung
wäre ja die Richtung "do one thing right".
>>Deshalb gibt es z.B. unter Linux ein Programm, das ISOs brennt, ein Programm, das ISOs erstellt, und ein Programm, das eine GUI zum CD<<
Ich habe gar nichts gegen L*n*x, im Gegenteil. L*n*x hätte es
viel leichter, wenn die Treiber in die Hardware verschoben
würden, dann fiele nämlich einer der Haupttnachteile von L*n*x ggü.
W*n*o*s weg, die Treiber-Auswahl.
>>Eben, und das abstrakte Gebilde setzt sich durch, ebenso wie man heute nicht mehr unbedingt in Assembler/C programmiert, sondern in Hochsprachen,<<
Eigentlich wird heutzutage meist in C/C++ programmiert. Das ist nicht
gerade Welten entfernt von Assembler, nur eben portabel.
Grüße
