Thema: App-/GUI-Server

[FlashBurn]

Das ist Aufgabe des GUI-Servers, denn der hat die Hoheit über den Grafiktreiber und je nach Grafikhardware lässt sich das Zeichenzeichnen hardwareseitig beschleunigen.

Da drücke ich mich wahrscheinlich falsch aus. Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss. Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).

Diese ganze GUI-App Geschichte würde ich halt am liebsten von einem Terminal-Emulator fern halten, damit der im Textmodus und im Grafikmodus benutzt werden kann ohne das er sich darum selber kümmern muss.

Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.

Solch eine Flexibilität wäre halt net bzw. Wiederverwendbarkeit.

Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.

Deswegen ja die Anmeldesequenz des GUI-Servers. Der meldet sich beim Input-Server, dass er jetzt zuständig ist und nicht mehr der Con-Server und dem Con-Server sagt er das auch nochmal (bzw. (siehst du das dann weiter unten) "ersetzt" er den Con-Server für den Textmodus mit dem Con-Server für den Grafikmodus).

Wenn du ein Textmodus-Programm ohne stdin/stdout/stderr startest, hat es halt keine Möglichkeit, damit zu arbeiten und gut. Für Hintergrundprogramme ist das durchaus gängige Praxis (Eingaben via Konfigdateien und Ausgaben via System-Log-Mechanismen).

Ich weiß nicht wie das unter Linux läuft, aber unter Windows funktioniert es das man einfach nen Doppel-Klick auf nen Textmodus-App macht und dann öffnet sich ne Textkonsole (im Hintergrund läuft dann unter W7 conhost.exe, glaub ich).

Deswegen überlege ich halt wie ich das am besten Umsetze, da so eine Funktionalität schon nicht schlecht wäre, ich das aber auch gerne schon vorher geplant haben will, damit ich nachher nicht nen Rewrite machen muss.

Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.

(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)

In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.

Das hätte ich dann halt so lösen wollen, das der Con-Server dann (deswegen soll sich der GUI-Server beim Con-Server anmelden) für jede laufende Terminal-Emulation ein Konsolenfenster aufmacht und die Programme da drin dann einfach weiterlaufen als wäre nichts gewesen (deswegen auch Doublebuffering in Software).

Du könntest natürlich ein Dummy-stdout bereitstellen und wenn da Daten auflaufen automatisch einen Terminalemulator starten und dem das stdout der Anwendung übergeben. Das wäre praktisch.

Genau sowas wollte ich machen.

Also nochmal (nach dem ich hoffentlich geklärt habe was ich mit Fensterverwaltung meine).

Mein Problem ist einfach das ich den Con-Server gerne so gestalten würde, dass er keinen Code hat der was mit dem Grafischenmodus zu tun hat, aber ich will auch nicht das der GUI-Server sich um alles was mit nem Konsolenfenster zutun hat kümmern muss.

Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.
Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt. Das hätte auch den Vorteil, das ich dann einfach nur nen Doppel-Klick auf nen Terminal-Emulator machen muss (der so auch im Textmodus funktioniert) und der halt als Stdout ne Leitung zum Con-Server bekommt und ein neues Fenster aufgeht bzw. im Textmodus, würde dann halt ne neue virtuelle Konsole "aufgehen".

Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.

Ich könnte beim Terminal-Emulator sogar noch ums Vererben drumrum kommen, indem ich sage, der muss sich grundsätzlich erstmal beim gerade laufenden Con-Server melden und sich seine Stdout/Stdin holen.

[kevin]

Da drücke ich mich wahrscheinlich falsch aus. Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss. Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).

Was hat der Con-Server denn mit der GUI zu tun? Ist das Entgegennehmen von Tastendrücken und Mausbewegungen nicht eher Aufgabe vom Terminalemulator?

Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.

Genau. Aber für den Con-Server bleibt dann keine Aufgabe mehr, der müsste ja nur noch stdin/out an den Terminalemulator durchreichen. Das geht auch direkter.

Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist.

Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.

Das ist kaputt. Von den GUI-Nachrichten sollte die Anwendung überhaupt nichts mitbekommen. Der Terminalemulator soll daraus irgendwas vernünftiges machen, z.B. in Escapesequenzen umwandeln oder Signale schicken.

(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)

Man kann üblicherweise im Terminalemulator einstellen, welches Programm er starten soll. Und ansonsten hat ja jeder Benutzer in der /etc/passwd noch seine Defaultshell.

Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.

Das ist der Terminalemulator, ein ganz normales GUI-Programm.

Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt

Benenn das Ding um, unter Terminalemulator versteht keiner das, was du hier beschreibst. Ich sehe auch nicht, in welche Sprache dieser "Terminalemulator" übersetzen sollte. Auf der einen Seite vt100, klar, aber auf der anderen? Der Ansatz kommt mir im Moment wenig sinnvoll vor.

Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.

Wie gesagt, Con-Server für die GUI ergibt in meinen Augen keinen Sinn. Der Con-Server ist das, was im Textmodus das Terminal implementiert, in der GUI brauchst du sowas nicht.

[FlashBurn]

Genau. Aber für den Con-Server bleibt dann keine Aufgabe mehr, der müsste ja nur noch stdin/out an den Terminalemulator durchreichen. Das geht auch direkter.

Ich will mir halt "ersparen" 2mal den selben Code zu schreiben. Deswegen soll der Terminal-Emulator ja auch nur so "wenig" können.
Der Con-Server hätte halt eine allgmeine "Sprache" in die übersetzt werden muss und der Con-Server verwaltet die ganzen Konsolen, sprich er weiß welche gerade im Vordergrund ist und leitet die Daten vom Intput-Server entsprechend weiter und er macht das ganze Double-Buffering.

Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist.

Den Terminal-Emulator will ich halt da raus halten und das der den Textmodus-Grafiktreiber mit integriert hat wird unter meinem OS nicht funktionieren.

Von den GUI-Nachrichten sollte die Anwendung überhaupt nichts mitbekommen. Der Terminalemulator soll daraus irgendwas vernünftiges machen, z.B. in Escapesequenzen umwandeln oder Signale schicken.

Die Anwendung bekommt davon auch nichts mit, es ging mir alleine um den Terminal-Emulator, dass dieser wissen muss ob er gerade im Textmodus läuft oder im Grafikmodus und läuft er im Grafikmodus müsste er sich um die ganzen Fenster-Msgs kümmern.

Das ist der Terminalemulator, ein ganz normales GUI-Programm.

Und genau das will ich halt so nicht machen. Für mich soll der Terminal-Emulator immer nur eine Art Übersetzer sein, nicht mehr und nicht weniger.

Ich sehe auch nicht, in welche Sprache dieser "Terminalemulator" übersetzen sollte. Auf der einen Seite vt100, klar, aber auf der anderen? Der Ansatz kommt mir im Moment wenig sinnvoll vor.

Der Terminal-Emulator soll von z.B. vt100 in eine allgemeine vom Con-Server unterstützte "Sprache" übersetzen. So halte ich mir halt die Möglichkeit offen noch andere Sachen als vt100 zu unterstützen ohne das ich das alles in ein Programm packen müsste. Ob das sinnvoll ist sei erstmal dahin gestellt.

Wie gesagt, Con-Server für die GUI ergibt in meinen Augen keinen Sinn. Der Con-Server ist das, was im Textmodus das Terminal implementiert, in der GUI brauchst du sowas nicht.

Ok, um es anders zu sagen. Ihr habt doch bei tyndur auch nen Terminal-Emulator (vterm), oder? Wie soll das dann irgendwann mal mit einer GUI laufen? Wollt ihr dann noch nen Terminal-Emulator für die GUI schreiben oder erweitert ihr euren bisherigen?

Worauf ich hinaus will, entweder man muss mehrere Terminal-Emulatoren schreiben, einen für den Textmodus und einen für den GUI-Modus oder man erweitert sein vorhanden Textmodus mit dem Code für den Grafikmodus.

Letzteres will ich nicht, da ich im Moment so plane, das man mein OS auch einfach nur als Konsolenvariante starten kann (so wie Linux ohne GUI-Krams). Ersteres will ich auch vermeiden, weil mal davon ausgehend, dass ich wirklich (ob das je so sein wird, ist mir erstmal egal) mehrere Terminal-Emulatoren habe, dann müsste ich ja für jeden 2 Varianten schreiben und beide Varianten hätten einen Teil des gleichen Codes (der "Übersetzer") und alle Terminal-Emulatoren hätten auch den gleichen Code (die ganze Fenster-Msgs Geschichte) und ich sehe es da halt so, einfach den gemeinsamen Teil von beiden Varianten in eine Stecken und den gemeinsamen Teil aller Emulatoren in etwas anderes auslagern (Con-Server).

Ich hoffe du kannst jetzt meine Motivation für dieses "Design" nachvollziehen.

[Svenska]

Hallo,

Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss.

Was soll der Con-Server denn sein? Entweder die Benennung ist falsch oder ich kann nicht nachvollziehen, was er tun soll.

Entweder er kümmert sich um den Textmodus, oder er kümmert sich um den Textmodus und die Kommunikation mit dem GUI-Server. In letzterem Falle ist das Design kaputt. Oder soll er im Textmodus einen Textmodus-Treiber besitzen (und die Grafikkarte ansteuern und das Terminal bereitstellen und Escapesequenzen verarbeiten) und im Grafikmodus ein Terminalemulator sein (der dem GUI-Server sagt "mach ein Fenster", dadrin selbst die Zeichen malt, ein Terminal bereitstellt und die Escapesequenzen verarbeitet)?

Das ist unelegant, weil du damit den Terminalemulator auf exakt den gleichen Terminaltyp beschränkst, wie den Textmodus-eigenen und außerdem müsste dein Con-Server dann zusätzlich noch Ahnung von Grafik UND vom GUI-Server haben. Damit baust du Abhängigkeiten so zusammen, dass du später die einzelnen Module nicht mehr ersetzen kannst (was ja ein Hauptvorteil von meinem System ist). Plus: Der Con-Server wird wesentlich komplexer.

Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).

Der GUI-Server sollte sich um die Fenster kümmern, nicht der Con-Server. Außerdem sollte der Input-Server seine Daten an den Server senden, der gerade für den Bildschirm zuständig ist - also entweder den Con-Server, wenn du im Textmodus bist, oder dem GUI-Server, wenn du im Grafikmodus bist.

Diese ganze GUI-App Geschichte würde ich halt am liebsten von einem Terminal-Emulator fern halten, damit der im Textmodus und im Grafikmodus benutzt werden kann ohne das er sich darum selber kümmern muss.

Ist deine Entscheidung. Genau das würde ich anders lösen - der Terminalemulator ist eine GUI-App.

Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.

Also dein Textmodus (d.h. Con-Server) sollte garkeinen Terminalemulator besitzen, sondern direkt ANSI o.ä. implementieren. Das ist dann eine solide Basis, die auch gut auf die vorhandenen Hardwaremöglichkeiten mappt.

Im GUI sind zuviele Sachen anders, daher solltest du den Textmodus vom Grafikmodus vollständig trennen. (Du kannst ja meinetwegen eine von beiden Servern verwendete Lib bauen, die ANSI spricht.) Der Terminalemulator ist dann eine Anwendung für den Grafikmodus, der ein Terminal emuliert (daher der Name). Beide Terminaltypen (im Text- oder im Grafikmodus) sind übrigens nicht identisch: Im Grafikmodus kannst du vt100-Features wie doppeltbreite Schriftzeichen, fett, unterstrichen usw. verwenden, die du im Textmodus garnicht implementieren kannst.

Zumal dein GUI-Server sich primär um die GUI kümmern sollte und nicht um Textmodusprogramme. Das ist Aufgabe des Terminalemulators. Und dein Con-Server hat sich gefälligst um den reinen Textmodus zu kümmern und nicht um Textanwendungen, die in einem Fenster (verantwortlich: GUI-Server  fürs Fenster, Terminalemulator für den Text dadrin) laufen. Das hängt vor allem mit dem Rendering zusammen, denn rendern tun entweder die Anwendungen selbst oder aber der GUI-Server. Niemand sonst.

Solch eine Flexibilität wäre halt net bzw. Wiederverwendbarkeit.

Naja, wenn du eine ANSI-Schnittstelle implementierst, dann kannst du die an beiden Stellen verwenden.

Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.

Deswegen ja die Anmeldesequenz des GUI-Servers. Der meldet sich beim Input-Server, dass er jetzt zuständig ist und nicht mehr der Con-Server und dem Con-Server sagt er das auch nochmal (bzw. (siehst du das dann weiter unten) "ersetzt" er den Con-Server für den Textmodus mit dem Con-Server für den Grafikmodus).

Warum so kompliziert? Erstens sind dann Textmodus und Grafikmodus voneinander abhängig und zweitens muss dein Con-Server, der ja nur für den Textmodus zuständig sein sollte, auch noch Ahnung vom Grafikmodus haben. Wie willst du später TrueType-Fonts rendern - soll das auch der Con-Server machen? Da mappen dann Zeichenanzahlen nicht mehr auf Pixelbreite, was du bei jedem Textmodusprogramm aber als gegeben annehmen kannst. Du würdest den GUI-Server zur Fensterverwaltung und den Con-Server zum Rendering einsetzen, das ist doof.

Ich weiß nicht wie das unter Linux läuft, aber unter Windows funktioniert es das man einfach nen Doppel-Klick auf nen Textmodus-App macht und dann öffnet sich ne Textkonsole (im Hintergrund läuft dann unter W7 conhost.exe, glaub ich).

Unter Linux öffnet sich da nichts. stdin/stdout werden auf /dev/null gemappt, fertig. Bei Windows wird automatisch ein Terminalemulator geöffnet. Das kannst du halten, wie du möchtest.

Deswegen überlege ich halt wie ich das am besten Umsetze, da so eine Funktionalität schon nicht schlecht wäre, ich das aber auch gerne schon vorher geplant haben will, damit ich nachher nicht nen Rewrite machen muss.

Hatte ich beschrieben, du öffnest ein Fenster, wenn ein Textmodusprogramm ohne vorhandenes Fenster (also mit dummy-stdout) etwas ausgibt...

Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.

Genau das ist Aufgabe eines Terminalemulators. Er ist kein Terminal, er emuliert eins. Außerdem ist der Terminalemulator ein Grafikprogramm und funktioniert ohne Grafikmodus garnicht erst. => Eingabeaufforderung oder xterm.

(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)

Wird sie auch. Entweder es wird die Standardshell des Benutzers verwendet (steht in /etc/passwd) oder es wird im Terminalemulator eine Anwendung konfiguriert (bei xterm mit "-e").

In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.

Das hätte ich dann halt so lösen wollen, das der Con-Server dann (deswegen soll sich der GUI-Server beim Con-Server anmelden) für jede laufende Terminal-Emulation ein Konsolenfenster aufmacht und die Programme da drin dann einfach weiterlaufen als wäre nichts gewesen (deswegen auch Doublebuffering in Software).

Unhandlich, weil dann dein Con-Server (a) was von Grafik verstehen muss (b) mit dem GUI-Server kommunizieren muss.

Du könntest allerdings eine Schnittstelle definieren, über die der Con-Server bei seinem Ende sämtliche stdin/stdout/stderr-Tripel an den GUI-Server übermittelt und der sich dann darum kümmert, dass dafür neue Fenster geöffnet werden. Oder auch nicht, wenn bestimmte Programme nur im Hintergrund laufen und eh kein Fenster kriegen sollen (z.B. das Textmodus-Uhrzeit-Widget, was oben rechts die aktuelle Uhrzeit anzeigt - dafür brauchts kein Fenster).

Mein Problem ist einfach das ich den Con-Server gerne so gestalten würde, dass er keinen Code hat der was mit dem Grafischenmodus zu tun hat, aber ich will auch nicht das der GUI-Server sich um alles was mit nem Konsolenfenster zutun hat kümmern muss.

Das Konsolenfenster ist für den GUI-Server ein Fenster wie jedes andere und für das System eine Anwendung wie jede andere. Was da drin ist, ist Aufgabe des Terminalemulators. Fertig.

Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.

Wer wäre es denn für nicht-konsolen-Apps?

Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt.

Er soll also ANSI/vt100 in ... ja, in was eigentlich übersetzen? Im Textmodus in VGA-Speicherzugriffe und im Grafikmodus in Anweisungen für den GUI-Server? Würde ich trennen.

Das hätte auch den Vorteil, das ich dann einfach nur nen Doppel-Klick auf nen Terminal-Emulator machen muss (der so auch im Textmodus funktioniert) und der halt als Stdout ne Leitung zum Con-Server bekommt und ein neues Fenster aufgeht bzw. im Textmodus, würde dann halt ne neue virtuelle Konsole "aufgehen".

Definier lieber ein Protokoll zur korrekten Übergabe von Textanwendungen von einem Server zum anderen. Zumal du eh nur einen Server zu jedem Zeitpunkt aktiv hast (deine Grafikkarte kann gleichzeitig nur entweder Text oder Grafik ausgeben, außerdem ist das Umschalten bei speziellen Grafiktreibern schwierig) und du wahrscheinlich zwar viel mit Textanwendungen in Terminalemulatoren arbeitest (xterm, Eingabeaufforderung), aber eher selten gleichzeitig(!) noch mit Fullscreen-Textmodusanwendungen arbeitest (unter Windows nicht möglich, da es keinen Textmodus gibt; unter Linux wären das die 6 virtuellen Terminals auf Strg+Alt+F1-F6, auf der 7 läuft meist der X-Server).

Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.

Dann mach einen Con-Server, der ausschließlich Textmodus macht und den VGA-Textmodus-Treiber gleich integriert hat und einen GUI-Server, der sich ausschließlich um den Grafikmodus kümmert und den VGA-Grafikmodus-Treiber integriert hat und einen Terminal-Emulator, der Textmodus auf einer grafischen Oberfläche emuliert.

Was hat der Con-Server denn mit der GUI zu tun? Ist das Entgegennehmen von Tastendrücken und Mausbewegungen nicht eher Aufgabe vom Terminalemulator?

Naja, das sollte der Input-Server tun, die Ereignisse werden dann vom GUI-Server durchgekaut und an den Terminalemulator weitergereicht.

Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist.

So meinte ich das.

Ich will mir halt "ersparen" 2mal den selben Code zu schreiben. Deswegen soll der Terminal-Emulator ja auch nur so "wenig" können.

Du hast im Grafikmodus aber wesentlich mehr Möglichkeiten, die eine eigene Implementation rechtfertigen können ("unterstrichen" geht bei VGA-Karten nunmal nicht).

Der Con-Server hätte halt eine allgmeine "Sprache" in die übersetzt werden muss und der Con-Server verwaltet die ganzen Konsolen, sprich er weiß welche gerade im Vordergrund ist und leitet die Daten vom Intput-Server entsprechend weiter und er macht das ganze Double-Buffering.

Oh, eine allgemeine Sprache. Noch eine. Warum nicht ANSI? Alle Anwendungen sprechen ohnehin ANSI (oder lassen sich mit ncurses so konfigurieren) und wenn dein Terminal nur ANSI versteht, dann reicht das doch aus. Du müsstest in dem Moment nur zwei Übersetzer bauen: ANSI=>VGAText und ANSI=>Framebuffer. Das erste macht dein Con-Server, das zweite macht dein Terminalemulator (der Fensterinhalt selbst ist ja ein Framebuffer mit z.B. 200x150px). Ich bezweifle, dass du da großartig Code teilen kannst.

Das ist der Terminalemulator, ein ganz normales GUI-Programm.

Und genau das will ich halt so nicht machen. Für mich soll der Terminal-Emulator immer nur eine Art Übersetzer sein, nicht mehr und nicht weniger.

Dann nenn ihn anders. Ein Terminalemulator ist ein GUI-Programm, welches in seinem Fenster ein Terminal emuliert. Nicht weniger.

Der Terminal-Emulator soll von z.B. vt100 in eine allgemeine vom Con-Server unterstützte "Sprache" übersetzen. So halte ich mir halt die Möglichkeit offen noch andere Sachen als vt100 zu unterstützen ohne das ich das alles in ein Programm packen müsste. Ob das sinnvoll ist sei erstmal dahin gestellt.

Ist es nicht. Deine Anwendungen sprechen durch die Bank weg ANSI/vt100 und das musst du darstellen. Wenn du plötzlich Anwendungen hast, die IBM3270 sprechen, dann musst du die auch darstellen. Also schreibst du am besten einen Wrapper von IBM3270 auf ANSI (was u.U. nur mit Einschränkungen möglich ist) oder aber du verzichtest für den VGA-Textmodus/Con-Server auf diese Möglichkeit. Für den Grafikmodus schreibst du dir dann einen Terminalemulator (die App!), welcher IBM3270 in sein Fenster rendert, weil dort kannst du es komplett flexibel machen. Und es dann als App umzusetzen, ist ohnehin sinnvoller.

Bedenke, dass du außer ANSI eigentlich nichts brauchst. Alle halbwegs modernen Textmodusanwendungen sprechen ANSI und etwas Neues wird es in dem Bereich nicht mehr geben, da der Textmodus durch den Grafikmodus ersetzt wurde. Windows unterstützt bis heute nur ein halbfertiges ANSI plus eine unvollständige Implementation der VGA-Textmodusregister in den Eingabeaufforderungen.

[...]

Ich hoffe du kannst jetzt meine Motivation für dieses "Design" nachvollziehen.

Ja, und ich halte es für relativ kompliziert, mit schlecht abgesteckten Aufgabenbereichen. Und vor allem zugeschnitten auf Textanwendungen, also unflexibel.

Ich kann verstehen, dass du "alles" anders machen möchtest als der Rest, aber manche Sachen sind halt einfach sinnvoll, wie sie anderswo eingesetzt werden.

Gruß,
Svenska

[FlashBurn]

Ein Terminalemulator ist ein GUI-Programm, welches in seinem Fenster ein Terminal emuliert. Nicht weniger.

Dann hätten wir das also schonmal geklärt!

Da ich denke dich jetzt endlich verstanden zu haben, werd ich es einfach so machen, das ich nen "Terminal-Emulator" für den Textmodus schreibe (der ANSI kann) und dann viel später einen für den GUI-Server und damit fällt der Con-Server komplett weg.

Mein Textmodus-Terminal muss dann halt trotzdem ein wenig mehr können, sprich Double-Buffering und mehrere virtuelle Terminals.

Jetzt sollte ich (bzw. vorallem svenska ) doch alles schön vereinfacht haben und ihr habt dem nichts mehr hinzuzufügen, oder?

Was auf keinen Fall geht, ist dass ein Programm nen Treiber enthällt, das wiederspricht absolut dem was ich mit meinem Treibermanagement vorhabe!

[Svenska]

Hallo,

dein "Terminal-Emulator für den Textmodus" ist dein Con-Server, zumindest hatte ich das bisher so verstanden. Ob du den jetzt Terminal-Emulator nennst oder Con-Server, ist ja egal. Da der (in meiner Welt ) nur als Notnagel existiert, braucht der auch nicht viele nifty features, d.h. er lebt ausschließlich im VGA-RAM (64KB) und unterstützt (max) 6 virtuelle Terminals, je nach gewünschter Größe des Screen-Buffers, außerdem braucht er kein Double Buffering.

Was mir grad einfällt... wenn du den Terminal-Emulator als Anwendung realisierst, auch für den Textmodus, dann kannst du ihn später auch auf serielle Leitungen oder Telnet-/SSH-Verbindungen ansetzen. Diese sind ja auch "nur" Terminals (bzw. Pseudo-Terminals unter Linux). Das würde ihn auch vom VGA-Textmodus-Grafiktreiber trennen.

Andererseits hätte ich die Terminals wahrscheinlich direkt im VGA-Textmodus-Grafiktreiber erzeugt, d.h. im Textmodus läuft kein Terminalemulator, sondern der Grafiktreiber (Con-Server) IST das Terminal (bzw. die virtuellen Terminals). Das sind aber Implementierungsdetails.

Es macht Spaß, dich zu überzeugen. Besonders, wenn es auch mal klappt.

Gruß,
Svenska

[FlashBurn]

d.h. er lebt ausschließlich im VGA-RAM (64KB) und unterstützt (max) 6 virtuelle Terminals, je nach gewünschter Größe des Screen-Buffers, außerdem braucht er kein Double Buffering.

Das ist meiner Meinung nach aber nicht wirklich portabel bzw. verlangst du dann ja vom VGA-Treiber (oder sonst was Treiber z.B. seriell) das er es ermöglicht das man mehrere Screenpages hat und auch mal zurück (nach oben) scrollen kann (was ich eigentlich schon gerne drin hätte).

Was mir grad einfällt... wenn du den Terminal-Emulator als Anwendung realisierst, auch für den Textmodus, dann kannst du ihn später auch auf serielle Leitungen oder Telnet-/SSH-Verbindungen ansetzen. Diese sind ja auch "nur" Terminals (bzw. Pseudo-Terminals unter Linux).

Ich dachte mir das dann so, das man dem Programm irgendwie sagen muss welches Gerät er für die Eingabe und welches er für die Ausgabe nutzt.
Da fällt mir gerade auf, das es schwierig wird mit den mehreren virtuellen Terminals das alles in einer Anwendung zu haben. Denn es wäre ja auch net, wenn eins von den virtuellen Terminals die Ein- und Ausgabe über ne serielle Schnittstelle macht, aber da ja schon die File-Handles 0-2 vergeben sind wird das nicht so einfach.
Hast du da vllt noch eine Idee?

[kevin]

Gehst du nicht immer entweder auf ein richtiges Terminal oder auf die serielle Schnittstelle? Du brauchst doch nicht beides gleichzeitig?

Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.

[Svenska]

Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.

Das Programm darf nicht wissen müssen, auf welchem Gerät es ausgeführt wird: Terminal ist Terminal, egal ob Emulator in der GUI, Serielle oder VGA-Textkonsole.

Wenn der VGA-Treiber mehrere virtuelle Terminals bereitstellt, darf er das gerne tun. Der Treiber für die seriellen Terminals stellt halt nur ein virtuelles Terminal bereit, das heißt es gibt keine Umschaltung. Und Scrollback findet bei seriellen Leitungen immer auf der Gegenseite statt, wird also auch nicht gefordert.

Das wäre eine Abstraktion "Terminal", die auf verschiedene Basistreiber (VGA, Seriell, "Pseudo") zugreift.

Ich schrieb übrigens nichts von "nicht können dürfen", sondern eher "nichts können müssen".

Gruß ^^

[FlashBurn]

Gehst du nicht immer entweder auf ein richtiges Terminal oder auf die serielle Schnittstelle? Du brauchst doch nicht beides gleichzeitig?

Naja, ich dachte halt an die Situation, dass im virtuellen Terminal 1 ne normale Shell läuft und auf dem virtuellen Terminal 2 läuft halt irgendeine Session über die serielle Schnittstelle (wo die Ausgabe von der seriellen Schnittstelle auf dem Bildschirm erscheint und die Eingabe die du im Terminal machst wird halt ans andere Ende der seriellen Verbindung geschickt und auf dem Bildschirm gezeigt).
Genauso sollte es dann auch möglich sein mit einem Headless System (eins ohne Bildschirm oder Ausgabe auf diesem) über ne serielle Schnittstelle zu interagieren (dazu muss ja trotzdem nen Terminal laufen).

Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.

Ich weiß schon gar nicht mehr was er damit meinte, aber sowas wie Farbe und ANSI-Codes soll es schon können.

[FlashBurn]

Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.

Ich will eigentlich nicht das der serielle Treiber (als Bsp.) nen Terminal bereitstellt, sondern der soll nur Daten empfangen oder senden, nicht mehr.
Das selbe gilt für den VGA-Textmodetreiber. Solange ich mich im Textmodus befinde, soll der nur 16-bit Wörter erhalten die er dann einfach in den Hardwarebuffer kopiert. Dazu muss er noch die Möglichkeit bieten, CLS und ein paar Cursor-Sachen machen zu können, aber die Terminalverwaltung soll er nicht machen.

Die Lösung zwecks des Eingabe/Ausgabe Problems könnte folgendes sein. In jedem virtuellen Terminal läuft irgendein Programm (also auch in dem das über die serielle Schnittstelle kommuniziert). Ich würde jetzt einfach ne neue Pipe für jeweils Stdout/Stderr/Stdin aufmachen und die an den Prozess als Stdout/Stderr/Stdin weiterreichen.
So kann ich einfach die serielle Schnittstelle öffnen und die Daten in die Pipe für Stdin reinschreiben und die Daten die aus der Pipe für Stdout kommen, werden einmal auf dem Bildschirm ausgegeben und einmal an die serielle Schnittstelle geschickt (bzw. umgedreht bin da gerade etwas verwirrt).
Das gleiche mit nem normalen Terminal. So kann ich auch Double-Buffering betreiben und kann die Verwaltung übernehmen (welches Terminal die Eingabe bekommt, also im Vordergrund ist usw.) und muss das nicht in irgendeinem Treiber haben.
Das liese sich auch alles wunderbar parallelisieren (in Threads) und die Ausgabe läuft weiter ohne dass das Terminal im Vordergrund sein muss.

[Svenska]

Naja, ich dachte halt an die Situation, dass im virtuellen Terminal 1 ne normale Shell läuft und auf dem virtuellen Terminal 2 läuft halt irgendeine Session über die serielle Schnittstelle (wo die Ausgabe von der seriellen Schnittstelle auf dem Bildschirm erscheint und die Eingabe die du im Terminal machst wird halt ans andere Ende der seriellen Verbindung geschickt und auf dem Bildschirm gezeigt).

Nope, das ist Unfug. Wenn du auf deinem Rechner eine Terminalemulation möchtest, die mit der seriellen Schnittstelle agiert, dann hat das gefälligst ein Programm zu tun, was die serielle Schnittstelle und ihre Eigenheiten kennt (Baudrate konfigurieren kann, ...), zum Beispiel "minicom", ein Terminal, welches dir Tastatur und Bildschirm mit einem externen Programm verbindet. Der umgekehrte Fall (das Terminal verbindet sich mit deinem System) ist interessant.

Genauso sollte es dann auch möglich sein mit einem Headless System (eins ohne Bildschirm oder Ausgabe auf diesem) über ne serielle Schnittstelle zu interagieren (dazu muss ja trotzdem nen Terminal laufen).

Richtig, das wäre dann - um bei deiner Terminologie zu bleiben - der Seriell-Server. Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung, der GUI-Server stellt dir eine grafische Oberfläche im Zusammenspiel mit dem Input-Server zur Verfügung (er stellt dir kein Terminal zur Verfügung, das macht der Terminalemulator!), der Seriell-Server stellt dir ein Terminal auf der seriellen Leitung (ohne Input-Server) zur Verfügung.

Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.

Ich weiß schon gar nicht mehr was er damit meinte, aber sowas wie Farbe und ANSI-Codes soll es schon können.

Hauptsächlich, dass du kein Double-Buffering und beliebig viele virtuelle Terminals brauchst. (Ich nutze im Extremfall, wenn die grafische Oberfläche kaputt ist, maximal drei bis vier.) Wenn du mehr brauchst, dann benutzt man ein Spezialprogramm wie "screen", welches auf sowas zugeschnitten ist und auch Sachen wie "detach in den Hintergrund" und eine Aufteilung in mehrere Fenster erlaubt.

Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.

Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.

Ich will eigentlich nicht das der serielle Treiber (als Bsp.) nen Terminal bereitstellt, sondern der soll nur Daten empfangen oder senden, nicht mehr.

Exakt, den reinen seriellen Treiber sehe ich da getrennt, der muss wirklich nur senden/empfangen/konfigurieren/Steuerleitungen können. Schließlich möchtest du ja auch Dateiprotokolle wie Kermit verwenden können und nicht nur Login.

Das selbe gilt für den VGA-Textmodetreiber. Solange ich mich im Textmodus befinde, soll der nur 16-bit Wörter erhalten die er dann einfach in den Hardwarebuffer kopiert. Dazu muss er noch die Möglichkeit bieten, CLS und ein paar Cursor-Sachen machen zu können, aber die Terminalverwaltung soll er nicht machen.

Genau, das ist der Optimalfall. Auf diese grundlegenden Funktionen setzt du dann "das ANSI-Terminal" an.

Ich würde wahrscheinlich das Terminal trotzdem in den VGA-Textmodustreiber einbinden und es als Speziallösung betrachten.

Die Lösung zwecks des Eingabe/Ausgabe Problems könnte folgendes sein. In jedem virtuellen Terminal läuft irgendein Programm (also auch in dem das über die serielle Schnittstelle kommuniziert). Ich würde jetzt einfach ne neue Pipe für jeweils Stdout/Stderr/Stdin aufmachen und die an den Prozess als Stdout/Stderr/Stdin weiterreichen.

Klingt gut. Wenn jetzt Daten ankommen, entscheidet der Treiber des zugehörigen Terminals, was mit den Daten jetzt gemacht wird (hast du mehrere VGA-Textterminals, wird es nur angezeigt, wenn es das aktive Terminal trifft, sonst nur in einen Hintergrundpuffer - beim seriellen Terminal wird stdout an die serielle Schnittstelle weitergereicht - im GUI-Fall startest du entweder einen Terminalemulator (=Fenster) oder nutzt den schon vorhandenen).

So kann ich einfach die serielle Schnittstelle öffnen und die Daten in die Pipe für Stdin reinschreiben und die Daten die aus der Pipe für Stdout kommen, werden einmal auf dem Bildschirm ausgegeben und einmal an die serielle Schnittstelle geschickt (bzw. umgedreht bin da gerade etwas verwirrt).

Die serielle Schnittstelle als Terminal redet nur mit dem dort angeschlossenen Gerät, nicht mit Tastatur/Bildschirm.

Das gleiche mit nem normalen Terminal. So kann ich auch Double-Buffering betreiben und kann die Verwaltung übernehmen (welches Terminal die Eingabe bekommt, also im Vordergrund ist usw.) und muss das nicht in irgendeinem Treiber haben.

Die Verwaltung der einzelnen Terminals (also Eingabe/Ausgabe) obliegt im VGA-Textmodus dem Programm, welches die virtuellen Terminals (evtl. in Hardware) implementiert, in der grafischen Oberfläche dem Fensterverwalter (GUI-Server) und im seriellen Terminal dem seriellen Treiber.

Das liese sich auch alles wunderbar parallelisieren (in Threads) und die Ausgabe läuft weiter ohne dass das Terminal im Vordergrund sein muss.

Das sind (für mich) sogar unabhängige Prozesse/Tasks.

Einen für die gemeinsamen VGA-Textterminals (Con-Server, du hast nur eine VGA-Karte = nur einen Treiber = nur ein Prozess), einen für jede serielle Schnittstelle, die als Terminal dienen soll und einen Terminalemulator für jedes Konsolenfenster in der GUI.

[FlashBurn]

Um die Sache mal ein wenig zu vereinfachen lassen wir die GUI Lösung jetzt mal außen vor. Denn wir hatten uns ja geeinigt dass das ein Terminalemulator alles macht.

Wenn du auf deinem Rechner eine Terminalemulation möchtest, die mit der seriellen Schnittstelle agiert, dann hat das gefälligst ein Programm zu tun, was die serielle Schnittstelle und ihre Eigenheiten kennt (Baudrate konfigurieren kann, ...), zum Beispiel "minicom", ein Terminal, welches dir Tastatur und Bildschirm mit einem externen Programm verbindet.

Ok, vereinfacht die Sache schonmal weiter.

Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung

Mir ist ein neuer Name eingefallen, der besser passt ... TUI-Server (hat nichts mit dem Reiseunternehmen zu tun ).
Denn er emuliert ja nicht nur einfach ein Terminal, sondern viele und kümmert sich auch darum welches gerade im Vordergrund ist. Man kann sagen das es im weitesten Sinne ein WindowManager für den Textmodus ist.

Richtig, das wäre dann - um bei deiner Terminologie zu bleiben - der Seriell-Server.

Zwecks Terminologie, so lange du nicht alles in den Kernel packst kann ich mit Linux-Begriffen leben, aber ich mache nicht aus allem nen Server

In dem Fall würdest du dich beim Device-Server melden und nach einer seriellen Schnittstelle fragen und wirst dann direkt mit dem Treiber kommunizieren.

Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.

Kann sein das meine Unwissenheit mir jetzt was falsches sagt, aber ich sehe da keine Schwierigkeit und auch keine Komplexität.

Du erstellst einfach für jedes neue virtuelle Terminal nen Buffer mit der Größe 4000bytes*Anzahl der Bildschirmseiten und schreibst einmal dort alles rein und wenn das Terminal im Vordergrund ist, schickst du die Daten noch zusätzlich an den VGA-Textmodustreiber.
Genau das ist auch das was ich meinte das es sich gut parallelisieren lässt. Man hat einfach einen Thread pro virtuellem Terminal im TUI-Server. Denn so eine Pipe fasst ja auch nicht unendlich an Daten.
Kommt ein anderes Terminal in den Vordergrund "kopierst" du einfach den Buffer (die Cursorposition muss natürlich mit einbezogen werden) zum VGA-Treiber und fertig. Einfach und ausreichend schnell.

Die serielle Schnittstelle als Terminal redet nur mit dem dort angeschlossenen Gerät, nicht mit Tastatur/Bildschirm.

Ich habe sowas noch nie gemacht und daher bin ich dabei noch etwas unsicher.

Also läuft das im Prinzip so ab, das ich Stdin an die serielle Schnittstelle weiterleite und was von der seriellen Schnittstelle kommt leite ich an Stdout weiter?
So muss ich auch nichts bei mir (da wo das Terminal läuft mit Bildschirm) auf den Monitor ausgeben, was ich über die Tastatur eingegeben habe, weil das kommt ja eh von der seriellen Schnittstelle zurück und wird dann auf meinem Monitor ausgegeben.

Falls jemand schonmal so eine "Session" gemacht hat und das so läuft wie ich es oben beschrieben habe, merkt man da ein Lag (weil ja erst zum Empfänger gesendet wird und dann kommt das Zeichen wieder zurück und wird erst dann auf dem Bildschirm erscheinen)?

Einen für die gemeinsamen VGA-Textterminals (Con-Server, du hast nur eine VGA-Karte = nur einen Treiber = nur ein Prozess)

Ich hatte ja oben schon was dazu geschrieben, aber so wie du es schreibst wird es schwierig. Erstmal implementiere ich das nicht im VGA-Treiber und wenn du dann nur einen Thread für viele Terminals hast, wird das schwierig. Denn dann müsstest du ja immer der Reihe nach alle Pipes aller virtuellen Terminals (deren Stdout) abfragen ob Daten da sind und mit meiner Thread-Variante wird das wesentlich einfacher und auch sauberer.

[Svenska]

Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung

Mir ist ein neuer Name eingefallen, der besser passt ... TUI-Server (hat nichts mit dem Reiseunternehmen zu tun ).
Denn er emuliert ja nicht nur einfach ein Terminal, sondern viele und kümmert sich auch darum welches gerade im Vordergrund ist. Man kann sagen das es im weitesten Sinne ein WindowManager für den Textmodus ist.

Joa, das kann man so sehen.

Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.

Kann sein das meine Unwissenheit mir jetzt was falsches sagt, aber ich sehe da keine Schwierigkeit und auch keine Komplexität.

Naja, guck dir mal "screen" an und überlege dann, ob du das nicht einfach benutzen möchtest (es ist ein ncurses-Programm), statt alles nochmal selbst zu implementieren. Es geht mir hier um alles, was man mit 4 gleichzeitigen Textterminals nicht mehr abbilden kann.

Du erstellst einfach für jedes neue virtuelle Terminal nen Buffer mit der Größe 4000bytes*Anzahl der Bildschirmseiten und schreibst einmal dort alles rein und wenn das Terminal im Vordergrund ist, schickst du die Daten noch zusätzlich an den VGA-Textmodustreiber.

Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.

Bei einem Wechsel des Terminals sagst du der Grafikkarte die Offsetadresse im Grafikspeicher und sie stellt dann von diesem Offset bis Offset+4000 Bytes es direkt auf dem Bildschirm dar. Spart das Kopieren.

Genau das ist auch das was ich meinte das es sich gut parallelisieren lässt. Man hat einfach einen Thread pro virtuellem Terminal im TUI-Server. Denn so eine Pipe fasst ja auch nicht unendlich an Daten.
Kommt ein anderes Terminal in den Vordergrund "kopierst" du einfach den Buffer (die Cursorposition muss natürlich mit einbezogen werden) zum VGA-Treiber und fertig. Einfach und ausreichend schnell.

Speicherbandbreite ist im Textmodus kein Thema, von daher ist alles "sehr schnell". Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.

Also läuft das im Prinzip so ab, das ich Stdin an die serielle Schnittstelle weiterleite und was von der seriellen Schnittstelle kommt leite ich an Stdout weiter?

Deine Anwendung will Zeug darstellen, schreibt also nach "stdout". Das Terminal sei seriell, also leitest du "stdout" auf die Serielle weiter, dass die Zeichen gesendet werden. Die Umwandlung von ANSI auf Darstellung erledigt das Fremdgerät (DEC-Terminal oder PuTTY-Seriell oder HyperTerminal oder minicom oder...).

Wenn das Fremdgerät irgendwelche Zeichen schickt, so soll die Anwendung diese erhalten (die Umwandlung in ANSI erledigt auch hier das Fremdgerät), also leitest du eingehende Daten von der Seriellen nach stdin weiter.

So muss ich auch nichts bei mir (da wo das Terminal läuft mit Bildschirm) auf den Monitor ausgeben, was ich über die Tastatur eingegeben habe, weil das kommt ja eh von der seriellen Schnittstelle zurück und wird dann auf meinem Monitor ausgegeben.

Von welcher Seite sprichst du jetzt? Wenn du jedes Zeichen wieder zurücksendest, dann nennt man das "remote echo", das Gegenteil davon ist lokales Echo, wenn dir das Terminal die gesendeten Zeichen auch auf den Bildschirm spult. Ist konfigurierbar.

Falls jemand schonmal so eine "Session" gemacht hat und das so läuft wie ich es oben beschrieben habe, merkt man da ein Lag (weil ja erst zum Empfänger gesendet wird und dann kommt das Zeichen wieder zurück und wird erst dann auf dem Bildschirm erscheinen)?

Bei 110 Baud sicherlich. Für 9600 Baud musst du aber schon verdammt schnell tippen. Allerdings merkt man eine 9600-Baud-Leitung schon recht deutlich, wenn man viele Kontrollsequenzen übertragen muss (z.B. mc in bunt). Man kann damit aber schon arbeiten. Als Vergleich: Das Linux-/BSD-Textterminal wird meist mit 38400 Baud betrieben. (Wobei ich nicht weiß, ob das auch die reale Geschwindigkeit ist; vermute aber zumindest bei den BSDs ja.)

Ich hatte ja oben schon was dazu geschrieben, aber so wie du es schreibst wird es schwierig. Erstmal implementiere ich das nicht im VGA-Treiber und wenn du dann nur einen Thread für viele Terminals hast, wird das schwierig. Denn dann müsstest du ja immer der Reihe nach alle Pipes aller virtuellen Terminals (deren Stdout) abfragen ob Daten da sind und mit meiner Thread-Variante wird das wesentlich einfacher und auch sauberer.

Naja, du hast halt nur eine VGA-Karte mit mehreren Terminals. Entweder dein VGA-Treiber implementiert das direkt, wie von mir beschrieben, oder du legst einen Layer oben drüber. Da der Treiber aber direkt auf die Hardware (ausschließlich VGA, evtl. EGA oder früher) zugeschnitten ist und auch nur eine Funktion (Terminal bereitstellen) hat, braucht man das mMn nicht wegabstrahieren. Für alles, was höhere Funktionen angeht, nutzt du ja den GUI-Server.

Was die Pipes angeht, würde ich AIO verwenden. Dann hast du einen Thread, der aber kein busy waiting macht. Wie gesagt, ich mag Threads irgendwie nicht.

Grüßle, ich geh ins Bett.

[FlashBurn]

Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.

Ich behaupte mal was die Portabilität angeht ist meine Variante wesentlich einfacher umzusetzen! Zumal ich so auch die Anzahl der Bildschirmseiten die gebuffert werden dynamisch festlegen kann und auf jeder Plattform funktioniert alles gleich (ich meine damit das auf jeder Plattform die gleiche Anzahl an Terminals genutzt werden kann ohne ein externes Programm wie screen zu nutzen).

Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.

AIO habe ich noch nicht und steht auf meiner ToDo-Liste auch ganz weit unten. Busy-Waiting benutzen meine Pipes auch nicht (zumal meine Pipes ja ein wenig anders funktionieren als "normale" Pipes).

[Svenska]

Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.

Ich behaupte mal was die Portabilität angeht ist meine Variante wesentlich einfacher umzusetzen! Zumal ich so auch die Anzahl der Bildschirmseiten die gebuffert werden dynamisch festlegen kann und auf jeder Plattform funktioniert alles gleich (ich meine damit das auf jeder Plattform die gleiche Anzahl an Terminals genutzt werden kann ohne ein externes Programm wie screen zu nutzen).

Naja, es gibt halt zugeschnittene, weitverbreitete Programme dafuer. Und der VGA-Textmodus ist ohnehin komplett unportabel, denn den gibt es auf anderen Architekturen nicht. Dort gibt es entweder von der Firmware ein dumb-Terminal oder ausschließlich einen Framebuffer, der von deinem GUI-Server benutzt würde. In jedem Falle hast du dort nur ein Terminal, solange du nicht mehrere Terminals auf einem emulierst (und das können externe Programme eh viel besser).

Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.

AIO habe ich noch nicht und steht auf meiner ToDo-Liste auch ganz weit unten. Busy-Waiting benutzen meine Pipes auch nicht (zumal meine Pipes ja ein wenig anders funktionieren als "normale" Pipes).

Wenn kein AIO, dann eben ein Thread pro Terminal und ein Lock für den Grafikspeicher.

Der Thread bräuchte dann nur zwei Zahlen als Parameter: Den Offset im Grafikspeicher (also das wievielte Terminal er ist, erfährst du beim Starten der Threads) und die Größe des Terminalspeichers (die erwähnten 13107 Bytes bei fünf Terminals). Plus natürlich Zeiger auf stdin/stdout/stderr.

Gruß,
Svenska

[erik.vikinger]

Hallo,


ich hab mir Euren Thread jetzt mindestens 2 mal komplett durchgelesen und muss sagen das er sehr interessant und aufschlussreich ist (bis her zumindest). Aber mir ist auch aufgefallen das Ihr (FlashBurn und Svenska) recht häufig wirr aneinander vorbei geschrieben habt. Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat. Ansonsten bietet der Thread aber schon einige Denkimpulse.


@Svenska:
screen ist aber schon ein recht umfangreiches Programm vom dem ich vermute das es ne Dicke Menge an POSIX-Zeugs benutzt und daher vermute ich das es noch nicht mal auf tyndur portiert wurde und man daher davon ausgehen kann das eine Portierung entweder sehr umfangreich wird oder eben eine umfangreiche POSIX-Unterstützung voraussetzt. Ich kann gut verstehen das FlashBurn mehrere TUI-Terminals lieber mit einer eigenen Schicht anbieten möchte wobei ich auch nicht der Meinung bin dass das Umschalten ein performancekritischer Aspekt ist. Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.


Basierend auf Euren Beiträgen hab ich mir mal ein paar eigene Gedanken gemacht wie man Terminal geschickt umsetzen könnte,
ich erzähle einfach mal:

Ein Programm bekommt von seinem Ersteller immer stdin/stdout/stderr mit (vererbt) und es ist ihm grundsätzlich egal was am anderen Ende ist. Wenn ein Programm z.B. ncurses benutzt dann sollte das andere Ende in der Lage sein das sauber dar zu stellen (wie ich das mit der Umgebungsvariable machen will weiß ich noch nicht so ganz).

Fürs erste werde ich nur eine RS232-Schnittstelle haben so das mein init-Prozess ein Programm starten muss das einen RS232-Port öffnet und daraus eben stdin/stdout/stderr erstellt und damit dann eine Shell startet. Die Shell bekommt dann alles was per RS232 rein kommt auf stdin übergeben und was die Shell (oder einer der Kind-Prozesse) auf stdout/stderr ausgibt wird eben per RS232 nach draußen gesendet. Dieses Umleitungsprogramm muss sich um ANSI-Sequenzen u.ä. keine Gedanken machen, das ist Aufgabe des Terminal-Programms auf dem Client-System am anderen Ende der RS232-Leitung (z.B. minicom).

Als nächstes käme dann ein telnet-Server der einen TCP-Server-Socket erstellt und für jede ankommende Verbindung dann einen TCP-Stream bekommt und mit dem es das selbe macht wie das andere Programm mit der RS232-Verbindung (eine TCP-Verbindung ist aus dieser Sicht exakt das selbe wie eine RS232-Verbindung: eine bidirektionale volldublex Byte-Strom-Schnittstelle), also ein neues Set stdin/stdout/stderr erstellt und damit dann eine neue Shell startet. Auch dieses Programm muss sich nicht um ANSI & Co kümmern, ist dafür aber ein Multithreading-Programm das eine unbegrenzte Anzahl an Konsolen öffnen kann (eben so viele wie TCP-Verbindungen entstehen).

Falls ich jemals bis zu einer GUI komme (eine lokale TUI wie beim VGA wird es bei mir nicht geben) werde ich wohl Svenskas Vorschlag mit den Default-Pipes und einem eigenständigen Terminal-Emulator-Programm umsetzen. Diesen Terminal-Emulator kann man entweder manuell starten und muss ihm dann sagen welches Programm unter seiner Obhut laufen soll oder das GUI-System startet dieses Programm automatisch immer dann wenn ein Programm seine stdin/stdout/stderr benutzt während diese noch in einem Dummy-System hängen (also z.B. bei Konsolen-Programmen die vom graphischen Dateimanager per Mausklick gestartet werden). Dieses Terminal-Emulations-Programm wird dann ein Fenster erstellen und da drin dann die Ausgaben von stdout/stderr (vom Client-Prozess) darstellen und (wenn es den Fokus hat) Tastatureingaben an stdin (vom Client-Prozess) weiterleiten. Es ist also ein vollwertiges GUI-Programm das selber kein stdin/stdout/stderr besitzt. Für die Darstellung muss dann natürlich ANSI usw. unterstützt werden, aber dafür gibt es Librarys hab ich gesehen. Dieses Terminal-Emulations-Programm erstellt entweder selber stdin/stdout/stderr um das an einen neuen Kindprozess weiter zu geben (falls es manuell gestartet wurde) oder es bekommt stdin/stdout/stderr eines bereits existierenden Programms übergeben (falls es vom GUI-System automatisch gestartet wurde).

Was denkt ihr darüber?


Grüße
Erik

[FlashBurn]

Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat.

Oder du vergisst das mein OS auf nem PC mit Bildschirm und ohne laufen kann/wird. Ich wollte schon das ich von meinem OS aus mit meinem OS auf einem Headless-System kommuniziere!

Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.

Selbst wenn es sowas wie den Textmodus unter x86 nicht auf anderen Plattformen gibt, dann will ich nen Treiber der auch den Textmodus darstellt (auch wenn das eigentlich grafisch ist) und dieser Treiber soll nur die Zeichen die du ihm gibst, eins nach dem anderen auf dem Bildschirm ausgeben und dann halt noch so Sachen wie CLS und Cursor-Sachen.
Das sollte ziemlich portabel sein.

Die Idee das man dann über TCP auch wie über RS232 kommunizieren kann gefällt mir besonders 

[Svenska]

Hallo,

Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat.

Ja, das Gefühl habe ich auch immer wieder. Wobei das auch daran liegen kann, dass ich manchmal zu wirr antworte und es dann selbst vergesse.

screen ist aber schon ein recht umfangreiches Programm vom dem ich vermute das es ne Dicke Menge an POSIX-Zeugs benutzt und daher vermute ich das es noch nicht mal auf tyndur portiert wurde und man daher davon ausgehen kann das eine Portierung entweder sehr umfangreich wird oder eben eine umfangreiche POSIX-Unterstützung voraussetzt.

Ich benutze es nicht, daher weiß ich auch nicht, welche Funktionalität es unterstützt. Grundsätzlich kann man auch eine eingeschränkte Fassung davon (die nur virtuelle Terminals simuliert) bauen, das sollte mit einer Bildschirm-Bibliothek wie ncurses recht simpel machbar sein - und nimmt Komplexität aus dem Treiber (was mMn gut ist).

Ich kann gut verstehen das FlashBurn mehrere TUI-Terminals lieber mit einer eigenen Schicht anbieten möchte wobei ich auch nicht der Meinung bin dass das Umschalten ein performancekritischer Aspekt ist. Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.

Die Frage ist, ob es sich lohnt, TUI-Terminals zu abstrahieren. Die Schnittstelle (reinen Textmodus) gibt es ja auf anderen Architekturen nicht und in einer grafischen Umgebung gibt es mehr Möglichkeiten, die der VGA-Textmodus (an dem man sich orientieren würde) nicht bereitstellt. Wenn man mit der GUI-Variante anfängt, diese sauber abstrahiert und dann die TUI-Variante darauf aufsetzt, dürfte das die saubere Lösung sein, aber nicht leicht umsetzbar. Außerdem kann man, wenn man mit der TUI-Variante anfängt, schonmal lernen und es in der GUI-Variante dann richtig umsetzen.

Ein Programm bekommt von seinem Ersteller immer stdin/stdout/stderr mit (vererbt) und es ist ihm grundsätzlich egal was am anderen Ende ist. Wenn ein Programm z.B. ncurses benutzt dann sollte das andere Ende in der Lage sein das sauber dar zu stellen (wie ich das mit der Umgebungsvariable machen will weiß ich noch nicht so ganz).

Nur einem reines zeilenbasiertem Programm kann das egal sein. Andere Programme müssen den Terminaltyp und dessen Fähigkeiten erfahren können ("mc" verweigert auf "dumb"-Terminals den Start); das kann man allerdings auch in ncurses fest eincodieren.

Fürs erste werde ich nur eine RS232-Schnittstelle haben so das mein init-Prozess ein Programm starten muss das einen RS232-Port öffnet und daraus eben stdin/stdout/stderr erstellt und damit dann eine Shell startet. Die Shell bekommt dann alles was per RS232 rein kommt auf stdin übergeben und was die Shell (oder einer der Kind-Prozesse) auf stdout/stderr ausgibt wird eben per RS232 nach draußen gesendet. Dieses Umleitungsprogramm muss sich um ANSI-Sequenzen u.ä. keine Gedanken machen, das ist Aufgabe des Terminal-Programms auf dem Client-System am anderen Ende der RS232-Leitung (z.B. minicom).

Genau.

Als nächstes käme dann ein telnet-Server der einen TCP-Server-Socket erstellt und für jede ankommende Verbindung dann einen TCP-Stream bekommt und mit dem es das selbe macht wie das andere Programm mit der RS232-Verbindung (eine TCP-Verbindung ist aus dieser Sicht exakt das selbe wie eine RS232-Verbindung: eine bidirektionale volldublex Byte-Strom-Schnittstelle), also ein neues Set stdin/stdout/stderr erstellt und damit dann eine neue Shell startet. Auch dieses Programm muss sich nicht um ANSI & Co kümmern, ist dafür aber ein Multithreading-Programm das eine unbegrenzte Anzahl an Konsolen öffnen kann (eben so viele wie TCP-Verbindungen entstehen).

Oder es ist ein simples Singlethreading-Programm, welches für jede ankommende TCP-Verbindung extra gestartet wird - wie einfache telnetd-Implementationen. Aber: vollkommen richtig.

Falls ich jemals bis zu einer GUI komme (eine lokale TUI wie beim VGA wird es bei mir nicht geben) werde ich wohl Svenskas Vorschlag mit den Default-Pipes und einem eigenständigen Terminal-Emulator-Programm umsetzen. Diesen Terminal-Emulator kann man entweder manuell starten und muss ihm dann sagen welches Programm unter seiner Obhut laufen soll oder das GUI-System startet dieses Programm automatisch immer dann wenn ein Programm seine stdin/stdout/stderr benutzt während diese noch in einem Dummy-System hängen (also z.B. bei Konsolen-Programmen die vom graphischen Dateimanager per Mausklick gestartet werden). Dieses Terminal-Emulations-Programm wird dann ein Fenster erstellen und da drin dann die Ausgaben von stdout/stderr (vom Client-Prozess) darstellen und (wenn es den Fokus hat) Tastatureingaben an stdin (vom Client-Prozess) weiterleiten. Es ist also ein vollwertiges GUI-Programm das selber kein stdin/stdout/stderr besitzt.

Es gibt bei dieser Herangehensweise ein Problem, welches unter POSIX-Programmen auftritt. Dort gibt es keine reinen GUI-Programme, jedes Programm besitzt stdout/stderr (starte mal einen Firefox unter Linux aus einem Terminalemulator, dort erhältst du dann Debug-Ausgaben). Um eine Rekursion zu vermeiden, musst du entweder dafür sorgen, dass der Terminalemulator sein stdout/stderr nie benutzt (und damit kein neuer gestartet wird) oder du setzt ein Flag, welches das Fenster-Erzeugen verhindert. Im Textmodus ist dieses Flag auch nützlich, denn es könnte die Ausgabe komplett verhindern (und z.B. in ein syslog umleiten).

Zu stdin könnte man ja die Überlegung anstellen, dass das Dummy-stdin nur EOFs liest, solange kein Terminalemulator (GUI) gestartet ist oder wenn dieses Flag im Textmodus beim Programmstart gesetzt war.

Für die Darstellung muss dann natürlich ANSI usw. unterstützt werden, aber dafür gibt es Librarys hab ich gesehen. Dieses Terminal-Emulations-Programm erstellt entweder selber stdin/stdout/stderr um das an einen neuen Kindprozess weiter zu geben (falls es manuell gestartet wurde) oder es bekommt stdin/stdout/stderr eines bereits existierenden Programms übergeben (falls es vom GUI-System automatisch gestartet wurde).

Die ANSI-Sequenzen kann ein Programm selbst erzeugen oder nutzt eine fertige Library (eben ncurses), die auch andere Terminaltypen unterstützt.

Was denkt ihr darüber?

Das ist die meiner Meinung nach einzig sinnvolle Lösung.

Was den Terminaltypen angeht, so gibt es zwei Sachen zu beachten:
(a) die Übergabe des Terminaltypens an die Anwendung (läuft bei POSIX über das Environment)
(b) die Ermittlung des Terminaltypens

Der zweite Fall hängt von dem Prozess ab, welches das Terminal bereitstellt. Der VGA-Textmodus-Treiber hat genau einen Typen fest implementiert (z.B. ANSI), den er bereitstellt und an das System meldet. Der Telnet-Daemon stellt auch einen Typen bereit, der aber mit dem Telnet-Client aushandelbar ist und davon abhängig an die Anwendung gemeldet werden muss. Für RS232-Verbindungen gibt es keine Lösung, da müsste entweder ein Standardwert benutzt werden oder der Nutzer gefragt werden.

Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.

Selbst wenn es sowas wie den Textmodus unter x86 nicht auf anderen Plattformen gibt, dann will ich nen Treiber der auch den Textmodus darstellt (auch wenn das eigentlich grafisch ist) und dieser Treiber soll nur die Zeichen die du ihm gibst, eins nach dem anderen auf dem Bildschirm ausgeben und dann halt noch so Sachen wie CLS und Cursor-Sachen.

Der Treiber, der Textmodus darstellt, ist ein VGA-Treiber, also unportabel. Und der muss aus einem Zeichenstrom die Cursor-/Farb-/CLS-Geschichten extrahieren und den Rest darstellen.

Die eigentliche Darstellung (also das "Verstehen" der Terminalsequenzen) ist nur für den VGA-Textmodustreiber oder den Terminalemulator im GUI erforderlich, für die RS232-/Telnet-Verbindung übernimmt das die Gegenseite - also das Terminal.

Gruß,
Svenska

[FlashBurn]

Der Treiber, der Textmodus darstellt, ist ein VGA-Treiber, also unportabel. Und der muss aus einem Zeichenstrom die Cursor-/Farb-/CLS-Geschichten extrahieren und den Rest darstellen.

Das ist mir schon klar! Ich meine das ich dann einen Textmode-Treiber für die jeweilige Platform schreiben will/muss und diese Treiber stellen auf allen Platformen das selbe Interface zur Verfügung.
Ich denke einfach das ein Textmode-Treiber einfacher und schneller geschrieben ist als ein komplett grafischer Treiber. Auch das Interface will erstmal designt werden und da ich erstmal nur mit einer Text-Oberfläche plane ist das halt einfacher.