Thema: App-/GUI-Server

[FlashBurn]

Um endlich mal wieder voran zu kommen wollte ich mein OS jetzt so gestalten das entweder nur eine Konsole (im Textmodus) oder ne richtige GUI geladen wird.

Ansich war es map geplant, das mein App-Server sich um die ganze GUI Geschichte kümmert, aber so würde ich jetzt nen App-Server und nen GUI-Server machen.

Problem ist mir will kein Grund einfallen wozu ich noch nen App-Server brauche

Das einzige wäre vielleicht, wenn ich den App-Server die Konsolen verwalten lasse, so dass die Programme dann später (in 10 Jahren ) auch problemlos auf der GUI laufen.

Was würde euch noch einfallen, was der App-Server machen müsste/sollte?

[kevin]

Hm, was soll denn ein App-Server überhaupt sein?

[FlashBurn]

Hm, was soll denn ein App-Server überhaupt sein?

Naja, es war geplant das der das ganze GUI-Zeugs übernimmt (eventuell sowas wie nen WindowManager?), aber bei der jetzigen Planung brauche ich ja etwas was die Ausgabe auf dem Bildschirm übernimmt (Textmodus), aber so aufgebaut ist, dass das ganze auch unter einer GUI funktioniert.
Unter ner GUI würde ich das dann praktisch an den GUI-Server weiterleiten bzw. der App-Server übernimmt die Darstellung und Verwaltung der Konsolen in einem Fenster.

[kevin]

Warum wendet sich das Programm nicht direkt an den richtigen Server statt dass die Anfragen erst weitergeleitet werden müssen?

Standardein-/ausgabe sind ja wahrscheinlich sowieso nur zwei Pipes, bei denen es dem Programm egal sein kann, wer das andere Ende hat. Und irgendwelche speziellen GUI-Funktionen tun im Textmodus eh nicht.

[FlashBurn]

Standardein-/ausgabe sind ja wahrscheinlich sowieso nur zwei Pipes, bei denen es dem Programm egal sein kann, wer das andere Ende hat.

Alle Dateien die per Libc geöffnet werden, werden bei mir wahrscheinlich über Pipes laufen.

Warum wendet sich das Programm nicht direkt an den richtigen Server statt dass die Anfragen erst weitergeleitet werden müssen?

Das Programm soll sich darum im Endeffekt nicht kümmern müssen bzw. soll die Daten immer an die gleiche Stelle schicken.

Es geht ja auch nur um die Initialisierung danach läuft alles über Pipes und wie du schon sagtest ist es dann egal wo die ankommen.
Es muss sich halt nur jemand finden der die Ausgabe übernimmt und am einfachsten ist es halt einen "Server" (weil der ja nicht wirklich viel macht) für die Konsole zu nutzen und einen für die GUI. Sprich intern würde ne Standardausgabe über den App-Server (Konsole) laufen und alles was etwas mit GUI zu tun hat würde über den GUI-Server laufen.

Ich dachte dann daran, das sich der GUI-Server, wenn er gestartet wurde, beim App-Server meldet und dieser dann die Daten nicht mehr ausgibt (Textmodus) sondern sie an den GUI-Server weiterreicht.
Die Performance sollte darunter nicht leiden.

Edit::

Laut dem C-Standard kann man ja eh nicht viel auf der Konsole machen, aber wie sollte man Funktionen zur Verfügung stellen um z.B. die Vorder- und Hintergrundfarbe zu ändern oder solche Sachen wie Midnight Commander zu ermöglichen?

[kevin]

Es geht ja auch nur um die Initialisierung danach läuft alles über Pipes und wie du schon sagtest ist es dann egal wo die ankommen.

Hm, wenn ich jetzt sage, der Aufrufer soll halt seine Deskriptoren vererben, mache ich mich unbeliebt, oder?

Es muss sich halt nur jemand finden der die Ausgabe übernimmt und am einfachsten ist es halt einen "Server" (weil der ja nicht wirklich viel macht) für die Konsole zu nutzen und einen für die GUI. Sprich intern würde ne Standardausgabe über den App-Server (Konsole) laufen und alles was etwas mit GUI zu tun hat würde über den GUI-Server laufen.

Wenn der App-Server das sein sollte, was unter tyndur vterm ist, also die Implementierung der Textkonsole, dann stimme ich dir zu. Dann muss der aber nichts weiterleiten, sondern Programme verbinden entweder zum App-Server oder zur GUI, aber nicht beides.

Laut dem C-Standard kann man ja eh nicht viel auf der Konsole machen, aber wie sollte man Funktionen zur Verfügung stellen um z.B. die Vorder- und Hintergrundfarbe zu ändern oder solche Sachen wie Midnight Commander zu ermöglichen?

vt100-Escapesequenzen?

[FlashBurn]

Hm, wenn ich jetzt sage, der Aufrufer soll halt seine Deskriptoren vererben, mache ich mich unbeliebt, oder?

Nope. Mit der Vererbung habe ich mich inzwischen abgefunden Problem wird nur noch sein, wie ich das mit dem Vererben der Pipes mache, weil ja immer nur einer lesen und nur einer schreiben kann/darf.

Dann muss der aber nichts weiterleiten, sondern Programme verbinden entweder zum App-Server oder zur GUI, aber nicht beides.

Und genau letzteres soll halt nicht passieren, weil die App soll nicht wissen müssen ob der GUI-Server läuft oder nicht und wie würdest du es denn machen wenn du auf einer Konsole nen Programm laufen hast (meinet wegen nen Skript was gerade tyndur kompiliert) und auf ner anderen startes du den GUI-Server? Problem wäre ja dass alles was vom Skript gestartet wird, über die Konsole läuft, aber diese soll ja deiner Meinung nach die Daten nicht zum GUI-Server schicken.

vt100-Escapesequenzen?

Noch nie von gehört, muss ich doch direkt mal googlen.

[Svenska]

Suche mal nach $TERM, vt100/vt102 (s/w) und vt200/vt220 (farbe) oder auch ANSI-Escape-Codesequenzen. Da wirst du hinreichend geholfen; eine ANSI-Implementation sollte hinreichen.

Du könntest natürlich auch direkt einen (primitiven) Grafiktreiber in deinen Kernel einbauen und deine Textkonsole direkt darauf aufbauen... ähnlich Linux-Framebuffer und KMS (Kernel Mode Setting). Dann sparst du dir den App-Server als Entscheidungsinstanz zwischen TUI und GUI. Wenn dein langfristiges Ziel Grafik ist, dann ist das eventuell ein gangbarer Weg.

Mit der Shadow-FB-Technik kann man übrigens auch VESA-Modi hinreichend schnell machen, ein paar zusätzliche MB RAM vorausgesetzt.

Gruß

[FlashBurn]

Ich habe mir nochmal ein paar Gedanken gemacht und werde wahrscheinlich (wenn ihr mich nicht vom Gegenteil überzeugen könnt ) nen Con-Server (oder auch Console-Server) und nen GUI-Server haben.

Ich werde, aber nicht vt100 und solche Sachen im Con-Server implementieren, sondern das muss die Shell machen (ist das unter POSIX nicht auch so?). Ich muss mir dann "nur" Gedanken machen, was ich alles zur Verfügung stellen will (Farbe setzen, Position setzen usw.).

Ich habe mir das dann so vorgestellt, das die Shell (egal welche) immer ne Pipe created und diese als Stdout für den Prozess "weitergibt". Der Prozess kann dann halt die Eigenheiten der Shell nutzen (z.B. ne vt100 Emulation) und die Shell "übersetzt" das ganze dann in "Aufrufe" für den Con-Server. So ist es möglich das ich mich weder um die Emulation (vt100) kümmern muss, noch das ich mich auf eine festlegen müsste.

Desweiter dachte ich dann daran, dass der GUI-Server sich beim Con-Server anmeldet und sagt "jetzt wird alles grafisch dargestellt" und der Con-Server kümmert sich dann um die ganze Fenster-Geschichte. So merkt das TUI-App gar nicht wo es gerade läuft, ob Text- oder Grafikmodus.

Das einzige was ich mir noch nicht überlegt habe, wie ich das dann mit der Eingabe mache, ob ich die auch über den Con-Server laufen lassen (wäre wahrscheinlich einfacher), weil sich ja im Grafikmodus auch ein wenig ändert. Da laufen ja nicht mehr nur Shell-Prozesse wo sich der Con-Server darum kümmert wer gerade im Vordergrund/Aktiv ist.

Wie groß sollte man eigentlich den Screenbuffer bei der Konsole wählen oder wie groß ist der allgemein?

[Svenska]

Ich habe mir nochmal ein paar Gedanken gemacht und werde wahrscheinlich (wenn ihr mich nicht vom Gegenteil überzeugen könnt ) nen Con-Server (oder auch Console-Server) und nen GUI-Server haben.

Ist auch ne Lösung, funktioniert so unter Linux, *BSD und anderen (konkret: deine GUI ist getrennt von der TUI).

Ich werde, aber nicht vt100 und solche Sachen im Con-Server implementieren, sondern das muss die Shell machen (ist das unter POSIX nicht auch so?). Ich muss mir dann "nur" Gedanken machen, was ich alles zur Verfügung stellen will (Farbe setzen, Position setzen usw.).

Nein, darum heißt die Variable auch $TERM - sie wird vom Terminal erzeugt und funktioniert daher für alle Anwendungen, die nicht Shell sind. Alternativ kannst du auch deine zur Verfügung gestellten Funktionen direkt exportieren und somit deinen eigenen Terminaltyp definieren. Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig. Die Shell hat damit garnichts zu tun, schließlich soll die Shell ja kein Fullscreen-Bunt-TUI-Programm sein, sondern der "mc". Es sei denn, du willst für JEDEN interaktiven Prozess immer die Hintergrundshell im Speicher haben...

Ich habe mir das dann so vorgestellt, das die Shell (egal welche) immer ne Pipe created und diese als Stdout für den Prozess "weitergibt". Der Prozess kann dann halt die Eigenheiten der Shell nutzen (z.B. ne vt100 Emulation) und die Shell "übersetzt" das ganze dann in "Aufrufe" für den Con-Server. So ist es möglich das ich mich weder um die Emulation (vt100) kümmern muss, noch das ich mich auf eine festlegen müsste.

Warum so kompliziert? Dein Con-Server stellt ein Terminal zur Verfügung, also sollte er auch brav announcen, von welchem Typ dieses Terminal ist. Im einfachsten Falle implementierst du deinen Con-Server so, dass er die grundlegenden ANSI/vt220-Sequenzen versteht und sparst dir den Rest der Arbeit.

Du musst ohnehin in jedem Falle Sachen wie Cursorpositition/Farbe/CLS/... implementieren und aus dem Characterstrom extrahieren. Ob die Steuerzeichen nun zu irgendwas kompatibel sind oder nicht, spielt keine Rolle.

Beachte übrigens auch, dass du nicht unbegrenzt viel Arbeit vom Kernel auf die Shell verlagern kannst oder auch solltest, schließlich möchtest du vielleicht irgendwann mal eine andere Shell haben als die erste (z.B. eine ash-Portierung)...

Desweiter dachte ich dann daran, dass der GUI-Server sich beim Con-Server anmeldet und sagt "jetzt wird alles grafisch dargestellt" und der Con-Server kümmert sich dann um die ganze Fenster-Geschichte. So merkt das TUI-App gar nicht wo es gerade läuft, ob Text- oder Grafikmodus.

Naja, wenn du virtuelle Terminals (wäre wohl ein eigener, kleiner Server bei dir) implementierst, kannst du ja jedes virtuelle Terminal entweder mit dem Con- oder dem GUI-Server verbinden. Weil: Was passiert, wenn dein GUI-Server ein Textprogramm oder ein Con-Server ein Grafikprogramm ausführen soll? Die Anwendungen sollten das schon wissen können, schließlich gibt es ja auch Anwendungen, die beides können (z.B. REGEDIT.EXE)...

Beim Umschalten des virtuellen Terminals werden dann Con- oder GUI-Server angewiesen, die Grafikhardware entsprechend so zu programmieren, dass Text- oder Grafikmodus dargestellt werden.

Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.

Das einzige was ich mir noch nicht überlegt habe, wie ich das dann mit der Eingabe mache, ob ich die auch über den Con-Server laufen lassen (wäre wahrscheinlich einfacher), weil sich ja im Grafikmodus auch ein wenig ändert. Da laufen ja nicht mehr nur Shell-Prozesse wo sich der Con-Server darum kümmert wer gerade im Vordergrund/Aktiv ist.

Wenn dein Con-Server sich um den Textmodus kümmert, hat er gefälligst im Grafikmodus die Finger von den Eingaben zu lassen. Denn dort gibt es so nette Erfindungen wie Fokus.

Die Eingaben solltest du bevorzugt über einen Eingabe-Server/-Multiplexer machen, denn du kannst ja auch Eingabegeräte jenseits der Tastatur anschließen (Joystick, Maus, Touchscreen, USB-Zweittastatur). Die sollten sich für das System nicht voneinander und von Tastaturen unterscheiden. Wenn du da eine gute Abstraktion einbaust, kannst du außerdem quasi-kostenlos eine Bildschirmtastatur implementieren, die dann nur in die Input-Queue injiziert.

Wie groß sollte man eigentlich den Screenbuffer bei der Konsole wählen oder wie groß ist der allgemein?

Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.

Gruß,
Sebastian

[FlashBurn]

Es sei denn, du willst für JEDEN interaktiven Prozess immer die Hintergrundshell im Speicher haben...

Sehr gutes Argument. Natürlich nicht.

Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig.

ncurses ist im Endeffekt genau sowas was ich gesucht habe, nur auf die schnelle konnte ich nichts finden wie das funktioniert. Ich meine damit woher weiß ncurses was es wie benutzen kann? Oder anders wenn ich bestimmte Excape-Sequenzen habe, dachte ich immer das hängt mit der benutzten Shell (deswegen mein Gedanke alles über die Shell machen zu lassen) zusammen ob da was sinnvolles am Monitor erscheint oder nicht.

Beachte übrigens auch, dass du nicht unbegrenzt viel Arbeit vom Kernel auf die Shell verlagern kannst oder auch solltest

Mit dem Kernel hat das alles rein gar nichts zu tun, aber du meinst bestimmt meinen Con-Server?!

Was passiert, wenn dein GUI-Server ein Textprogramm oder ein Con-Server ein Grafikprogramm ausführen soll?

Ich vermute mal das ist wieder zu Linux-haft gedacht

Weder GUI- noch Con-Server führen ein Programm aus. Was ich meine ist, das ein Programm sich nicht darum kümmern brauchen soll, ob gerade der GUI-Server läuft oder nicht.
Ist es ein grafisches App "verbindet" es sich mit dem GUI-Server (oder gibt ne Fehlermeldung aus, das kein GUI-Server läuft) und ist es ein TUI-App verbindet es sich mit dem Con-Server, bzw. wird halt einfach alles über Stdout gemacht. Ich möchte aber nicht, das ein App sich darum kümmern muss, ob sie (sozusagen) die Ausgabe über den Con-Server oder über den GUI-Server machen soll (wenn es nur Stdout betrifft).

Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.

Anders gefragt, warum soll ich mir die Arbeit machen nen Grafiktreiber zu entwickeln, wenn ich erstmal nur Text habe, wenn das alles auch ohne Grafiktreiber läuft.
Mit Textmodus meine ich eigentlich das du nen Buffer hast wo du deine Zeichen und die Flags (Farben usw.) reinschreibst und das erscheint dann auf dem Bildschirm.
Gibt es das nicht auch auf anderen Plattformen?

Die Eingaben solltest du bevorzugt über einen Eingabe-Server/-Multiplexer machen, denn du kannst ja auch Eingabegeräte jenseits der Tastatur anschließen (Joystick, Maus, Touchscreen, USB-Zweittastatur). Die sollten sich für das System nicht voneinander und von Tastaturen unterscheiden. Wenn du da eine gute Abstraktion einbaust, kannst du außerdem quasi-kostenlos eine Bildschirmtastatur implementieren, die dann nur in die Input-Queue injiziert.

Genau so habe ich mir das vorgestellt. Allerdings hatte ich vorhin irgendwie nicht daran gedacht, wie man halt die Daten vom Input-Server zum richtigen Programm bekommt und daher wollte ich das über den entsprechenden Server leiten (Con oder GUI), weil der ja weiß welches "Fenster" gerade den Fokus hat.

Es wäre aber auch möglich einfach jedes Mal dem Input-Server mitzuteilen welches App gerade den Fokus hat, so spart man sich das umleiten.

Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.

Ich denke mal du hast mich falsch verstanden. Ich meine den Softwarebuffer, sprich egal wie groß der Hardwarebuffer ist (z.B. nur eine Bildschirmseite) buffere ich das ja in Software nochmal. So dass ich dann immer, keine Ahnung vielleicht 4 Seiten habe?

Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.

[erik.vikinger]

Hallo,

ist es ein TUI-App verbindet es sich mit dem Con-Server, bzw. wird halt einfach alles über Stdout gemacht. Ich möchte aber nicht, das ein App sich darum kümmern muss, ob sie (sozusagen) die Ausgabe über den Con-Server oder über den GUI-Server machen soll (wenn es nur Stdout betrifft).

Die App erbt stdin/stdout/stderr und muss sich deswegen nicht darum kümmern woher das kommt (das trifft auch auf die Shell zu).

Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.

Das ist ein Feature das Dein "Con-Server" bieten muss. Wenn er will erstellt er eine neue Console (oder öffnet z.B. ne Serielle-Schnittstelle) und dazu neue stdin/stdout/stderr und startet dann einen Prozess für diese Console (üblicherweise ne Shell) welcher dann die 3 Streams erbt.
Also immer schön hierarchisch denken und das erben nicht vergessen.


Grüße
Erik

[FlashBurn]

Also immer schön hierarchisch denken und das erben nicht vergessen.

Was ich meine ist, ob man einfach ne Tastenkombination dafür nutzt oder ob man die Shell manuel starten muss (z.B. "/bin/bash").
Unter Windows z.B. bringt es dir gar nichts wenn du cmd.exe in der Aufgabeaufforderung aufrufst. Denn es wird kein neues Fenster erzeugt und unter Mingw bash/sh das gleiche.

[erik.vikinger]

Hallo,

Was ich meine ist, ob man einfach ne Tastenkombination dafür nutzt oder ob man die Shell manuel starten muss (z.B. "/bin/bash").

Hä, ich verstehe nicht was Du meinst.

Unter Windows z.B. bringt es dir gar nichts wenn du cmd.exe in der Aufgabeaufforderung aufrufst. Denn es wird kein neues Fenster erzeugt und unter Mingw bash/sh das gleiche.

Ist ja auch logisch, in der Eingabeaufforderung läuft bereits ne Shell (cmd.exe) und die hat stdin/stdout/stderr selber von dem Fenster geerbt bekommen (wie das ganz genau funktioniert weiß ich auch nicht aber die Doku zur WIN32-API sollte dieses Geheimnis lüften können, such dort einfach mal nach "CreateConsoleWindow" oder was ähnlichem) und vererbt das einfach an den neuen Prozess weiter. Das der neue Prozess wieder ne cmd.exe ist interessiert dabei nicht.


Grüße
Erik

[FlashBurn]

Hä, ich verstehe nicht was Du meinst.

Ok, mein OS ist fertig gestartet und man findet sich in/auf einer Shell wieder. Jetzt will man aber noch eine Shell/"Fenster" öffnen. Wie man das lösen soll, das weiß ich halt noch nicht.
Ob man z.B. ne Tastenkombination nimmt (z.B. STRG+N) oder was mir lieber wäre, das man nen Programm aufruft und dem vllt die neue Shell als Parameter übergibt (so dass man auch verschiedene Shells starten kann).

[Svenska]

Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig.

ncurses ist im Endeffekt genau sowas was ich gesucht habe, nur auf die schnelle konnte ich nichts finden wie das funktioniert. Ich meine damit woher weiß ncurses was es wie benutzen kann? Oder anders wenn ich bestimmte Excape-Sequenzen habe, dachte ich immer das hängt mit der benutzten Shell (deswegen mein Gedanke alles über die Shell machen zu lassen) zusammen ob da was sinnvolles am Monitor erscheint oder nicht.

Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.

Weder GUI- noch Con-Server führen ein Programm aus. Was ich meine ist, das ein Programm sich nicht darum kümmern brauchen soll, ob gerade der GUI-Server läuft oder nicht.

Wieso? Wird doch eh von oberhalb vererbt.

Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.

Anders gefragt, warum soll ich mir die Arbeit machen nen Grafiktreiber zu entwickeln, wenn ich erstmal nur Text habe, wenn das alles auch ohne Grafiktreiber läuft.

Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler. Außerdem, wenn du ohnehin später eine GUI möchtest, profitieren deine Textanwendungen direkt von dessen Entwicklungen mit.

Mit Textmodus meine ich eigentlich das du nen Buffer hast wo du deine Zeichen und die Flags (Farben usw.) reinschreibst und das erscheint dann auf dem Bildschirm.
Gibt es das nicht auch auf anderen Plattformen?

Nein, die meisten Plattformen stellen dir nur einen dummen Framebuffer bereit, auf den du selbst zeichnen darfst. Oder die dortige Firmware stellt dir Funktionen zur Textausgabe bereit (oft auch für RS232). Einen VGA-ähnlichen Textmodus gibt es da normalerweise nicht.

Es wäre aber auch möglich einfach jedes Mal dem Input-Server mitzuteilen welches App gerade den Fokus hat, so spart man sich das umleiten.

Nö. Du möchtest auch systemweite Kürzel (z.B. SysRq oder virtuelles-terminal-wechseln) implementieren können, die direkt die grafische Oberfläche (den GUI-Server) betreffen. Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)

Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.

Ich denke mal du hast mich falsch verstanden. Ich meine den Softwarebuffer, sprich egal wie groß der Hardwarebuffer ist (z.B. nur eine Bildschirmseite) buffere ich das ja in Software nochmal. So dass ich dann immer, keine Ahnung vielleicht 4 Seiten habe?

Da gibt es keine Grenzen. Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.

Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.

Also die Anzahl der virtuellen Terminals kannst du auch unabhängig vom Video-RAM machen, wird dann halt nur langsamer.

Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.

Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.

In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...

Ok, mein OS ist fertig gestartet und man findet sich in/auf einer Shell wieder. Jetzt will man aber noch eine Shell/"Fenster" öffnen. Wie man das lösen soll, das weiß ich halt noch nicht.

"man screen" ?

Ob man z.B. ne Tastenkombination nimmt (z.B. STRG+N) oder was mir lieber wäre, das man nen Programm aufruft und dem vllt die neue Shell als Parameter übergibt (so dass man auch verschiedene Shells starten kann).

Oder halt ein virtuelles Terminal (STRG+Links oder STRG+Rechts), wo du dich erneut einloggen kannst. Mittels "exec" ersetzt du die Shell dann durch dein Wunschprogramm (Posix-spezifisch).

Gruß

[FlashBurn]

Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.

Jetzt hast du mich komplett verwirrt

Kann man unter Terminal nun eine Shell oder meinen Con-Server verstehen? Ich vermute mal eher letzteres.

Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler.

Ich gehe mal davon aus, das selbst Linux verdammt lange einfach nur die Ausgabe im "Textmodus" gemacht hat, weil es einfacher und schneller ist. Das ein guter Textmodus-Treiber flexibler ist, ist logisch und Portabilität steht im Moment ganz ganz weit unten auf meiner ToDo-Liste

Nö. Du möchtest auch systemweite Kürzel (z.B. SysRq oder virtuelles-terminal-wechseln) implementieren können, die direkt die grafische Oberfläche (den GUI-Server) betreffen. Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)

Wenn ich dich richtig verstehe, würdest du also die Eingabe an den Con-Server und den GUI-Server (sofern dieser läuft) weiterleiten und diese sehen dann was sie damit machen, um eventuell die Daten an eine entsprechende App weiterzuleiten?

Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.

Also ganz ehrlich, wieso sollte ich mich auf den Hardwarebuffer beschränken, das wäre ja quatsch (im Textmodus)? Wir reden hier davon 80*25*2= 4000bytes von einem Buffer irgendwo im RAM in den Hardwarebuffer zu kopieren und das sollte selbst auf nem P75 (kleinster unterstützter Pentium von mir) so schnell sein, das es nicht spürbar ist!
Was den Grafikspeicher angeht das selbe. Denn du kannst ja nicht sagen, tut mir leid noch eine Anwendung kann nicht gestartet werden, weil nicht genügend Grafikspeicher vorhanden ist, aber RAM habe ich noch verdammt viel frei!

In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...

So ähnlich dachte ich mir das (letzteres). Nämlich das man immer Stdout/Stderr/Stdin mir gültigen Pipes versieht und der Con-Server macht erst nen neues Konsolenfenster auf, wenn auch was auf Stdout/Stderr ausgegeben wird (wird unter Windows auch gemacht, möchte ich meinen).

An das Vererben habe ich allerdings in diesem Fall wirklich nicht gedacht. Nur finde ich es einfacher wenn sich der Con-Server dann im grafischen Modus um die ganze Fenstergeschichte kümmert, als wenn ich das dann auch noch im GUI-Server machen müsste bzw. so könnte man dann auch andere Terminal-Emulationen ermöglichen ohne das ich das im GUI-Server habe.

Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.

Auf der einen Seite wäre es ein Server, aber ich würde es jetzt mal Programm nennen und die Idee gefällt mir, damit habe ich wieder alles aus dem Con-Server raus und in einem externen Programm drin. Somit könnte ich wieder mehrere Terminal-Emulationen zur Verfügung stellen ohne das alles an einem zentralen Ort sein müsste.

Ich weiß nicht ob es zuviel verlangt wäre, wenn ihr mir helfen könntet nen Interface bzw. die Funktionen die man benötigt (für den Con-Server, der allgemein bleiben muss um die Terminal-Emulationen zu ermöglichen) zu entwerfen?!

[Svenska]

Hallo,

wieder etwas länger jetzt.

Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.

Jetzt hast du mich komplett verwirrt

Kann man unter Terminal nun eine Shell oder meinen Con-Server verstehen? Ich vermute mal eher letzteres.

Ein Terminal abstrahiert dir Tastatur und zeichenorientierten Bildschirm (guck dir ein Original DEC VT100 an, das ist ein "Terminal"). Wenn dein Con-Server das sein soll, dann abstrahiert er ein Terminal (oder mehrere). Ein Terminalemulator (z.B. xterm, rxvt, Eingabeaufforderung) stellt dir auch ein Terminal zur Verfügung. (Könnte man noch weiter ausführen, der Unterschied zwischen TTY [reales Terminal] und PTY [Pseudoterminal], aber tue ich jetzt nicht.)

Wie dieses Terminal funktioniert, meldet derjenige, der das Terminal erzeugt, an das System. Unter DOS ist das der Treiber CON (der ist dumm, es sei denn, du installierst ANSI.SYS o.ä.), unter POSIX wird dies im lokalen Environment automatisch angegeben (die Variable $TERM) - bei frühen Unixen wurde nach dem Login danach gefragt.

Die Shell ist eine Anwendung, die erstmal nur stdin/stdout/stderr kennt (also ein dummes Terminal z.B. Drucker, $TERM="dumb"). Interessant wird es erst, wenn du Programme startest, die mehr Zugriff auf den Bildschirm wollen (Cursorposition, Funktionstasten, Farbe und Attribute). Allein diese müssen nämlich mehr Informationen über den Terminaltypen bekommen - und den bekommen sie aus $TERM.

Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler.

Ich gehe mal davon aus, das selbst Linux verdammt lange einfach nur die Ausgabe im "Textmodus" gemacht hat, weil es einfacher und schneller ist. Das ein guter Textmodus-Treiber flexibler ist, ist logisch und Portabilität steht im Moment ganz ganz weit unten auf meiner ToDo-Liste

Naja, inzwischen wird KMS eingeführt, weil man damit einmal einen moduswechselfreien Boot bis zur grafischen Oberfläche bekommt, außerdem kann man damit auch gleich die Kommunikation mit der Grafikkarte einbeziehen, da die unter Linux ohnehin über den Kernel läuft und Hardware-spezifisch ist.

Und es ist ein Zeichen, dass der Textmodus langsam überholt ist. Du findest so gut wie kein Linux, auf dem keine grafische Oberfläche installiert ist, sofern Tastatur und Bildschirm angeschlossen sind (d.h. reine Server mal ausgenommen).

Richtig ist, dass der Textmodus schneller ist, v.a. weil er weniger Speicher (und ~bandbreite frisst und Scrolling in Hardware funktioniert. Allerdings sind die Speicherbandbreiten stark gewachsen, die Grafikkarten haben genug Speicher und System-RAM ist auch genug da, dass man Double Buffering tun kann. Dann ist selbst ein VESA-Treiber hinreichend schnell. (Die meisten heutigen generischen VESA-Treiber machen kein Double Buffering, das gilt für den Windows-Standardtreiber und auch für 'vesa'. Darum sind die so langsam, vgl. hier.)

Außerdem schrieb ich, dass der Grafiktreiber flexibler ist als der Textmodustreiber, denn der kann Grafik und andere Fonts und vernünftige Auflösungen. Schließlich ist 80x50 auch nicht das Ende der Geschichte gewesen.

Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)

Wenn ich dich richtig verstehe, würdest du also die Eingabe an den Con-Server und den GUI-Server (sofern dieser läuft) weiterleiten und diese sehen dann was sie damit machen, um eventuell die Daten an eine entsprechende App weiterzuleiten?

Jein, wenn dein Con-Server und dein GUI-Server gleichzeitig laufen, muss klar erkennbar sein, welcher jetzt gerade aktiv ist. Nur an den darf weitergeleitet werden. Ansonsten: exakt.

Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.

Also ganz ehrlich, wieso sollte ich mich auf den Hardwarebuffer beschränken, das wäre ja quatsch (im Textmodus)? Wir reden hier davon 80*25*2= 4000bytes von einem Buffer irgendwo im RAM in den Hardwarebuffer zu kopieren und das sollte selbst auf nem P75 (kleinster unterstützter Pentium von mir) so schnell sein, das es nicht spürbar ist!

Korrekt, aber das wird dann umständlicher.

Was den Grafikspeicher angeht das selbe. Denn du kannst ja nicht sagen, tut mir leid noch eine Anwendung kann nicht gestartet werden, weil nicht genügend Grafikspeicher vorhanden ist, aber RAM habe ich noch verdammt viel frei!

Willst du also beliebig viele virtuelle Terminals installieren? Das wäre meiner Meinung nach überflüssig, denn (a) gibt es Programme wie "screen", welche dir auf einem virtuellen Terminal mehrere Terminals simulieren und per Tastendruck OS-unabhängig umschalten und diverse andere Magie machen, (b) brauchst du eigentlich nur 3-4 virtuelle Text-Terminals und ein GUI-Terminal und (c) werden sämtliche Text-Terminals überflüssig, wenn du eine Terminalemulation unter einer GUI laufen hast [und dadrin kannst du wieder "screen" aufrufen].

Der Textmodus ist eigentlich schon immer eine Krücke gewesen, seit es gebrauchbare 2D-Beschleuniger gibt.

In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...

So ähnlich dachte ich mir das (letzteres). Nämlich das man immer Stdout/Stderr/Stdin mir gültigen Pipes versieht und der Con-Server macht erst nen neues Konsolenfenster auf, wenn auch was auf Stdout/Stderr ausgegeben wird (wird unter Windows auch gemacht, möchte ich meinen).

Der Con-Server sollte keine Fenster öffnen, sondern der GUI-Server. Der Con-Server könnte höchstens ein neues virtuelles Terminal öffnen, aber das fände ich etwas übertrieben. Textanwendungen haben ihr Terminal ja bereits.

An das Vererben habe ich allerdings in diesem Fall wirklich nicht gedacht. Nur finde ich es einfacher wenn sich der Con-Server dann im grafischen Modus um die ganze Fenstergeschichte kümmert, als wenn ich das dann auch noch im GUI-Server machen müsste bzw. so könnte man dann auch andere Terminal-Emulationen ermöglichen ohne das ich das im GUI-Server habe.

Ähm... der Con-Server hat sich aus der grafischen Umgebung rauszuhalten. Da gelten andere Konzepte. Der GUI-Server wiederum sollte keine Terminalemulation bieten, das ist Aufgabe einer Terminalemulator-Anwendung, die für den GUI-Server ein Fenster mit Fokus ist, für die Anwendung darunter ein (Pseudo-)Terminal.

Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.

Auf der einen Seite wäre es ein Server, aber ich würde es jetzt mal Programm nennen und die Idee gefällt mir, damit habe ich wieder alles aus dem Con-Server raus und in einem externen Programm drin. Somit könnte ich wieder mehrere Terminal-Emulationen zur Verfügung stellen ohne das alles an einem zentralen Ort sein müsste.

Löse dich von den verschiedenen Terminalemulationen. Die brauchst du nicht. Das betrifft einmal nur Textprogramme mit Bildschirmzugriff, und die nutzen entweder ncurses oder termcap oder sowas. Konfigurierst du einmal, tun alle Programme. Außerdem sind die bekannten Terminalemulationen größtenteils kompatibel zueinander. Implementiere ANSI (vgl. ANSI.SYS unter DOS, das Linuxterminal ist etwa kompatibel) oder vt220 (*BSD) im Kernel/Con-Server und gut ist. Alle anderen, nie benutzten Terminalemulationen implementierst du in einem Terminalemulator, der dann unter der grafischen Oberfläche läuft. (Dann kannst du auch erst was mit Textcodierungen anfangen, die z.B. Japanisch oder so darstellen, denn die passen so schlecht in den Standard-VGA-Font...)

Ich weiß nicht ob es zuviel verlangt wäre, wenn ihr mir helfen könntet nen Interface bzw. die Funktionen die man benötigt (für den Con-Server, der allgemein bleiben muss um die Terminal-Emulationen zu ermöglichen) zu entwerfen?!

Ich würde dir die ANSI-Escape-Codesequenzen ans Herz legen. Das ist hinreichend vollständig.
Soweit ich informiert bin, setzen alle Vollbild-Textmodusprogramme nur ein "CLS" voraus, und nutzen "Curserposition setzen"-Funktionen sehr extensiv aus, wenn diese vorhanden sind.

Wichtig ist, dass du dir eine Schnittstelle ausdenkst, wie du die Informationen über das Terminal an die darunterliegende Anwendung übergibst. Linux hat $TERM, aber auch $COLUMNS und $LINES für die Größenangaben, außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.

Gruß,
Svenska

[FlashBurn]

Und es ist ein Zeichen, dass der Textmodus langsam überholt ist. Du findest so gut wie kein Linux, auf dem keine grafische Oberfläche installiert ist, sofern Tastatur und Bildschirm angeschlossen sind (d.h. reine Server mal ausgenommen).

Bitte nicht vergessen, das wir hier über ein Hobby-OS reden, das irgendwann mal auch nen GUI haben möchte und auf allem laufen soll ab P75 (mit ein paar Ausnahmen).
Von daher ist der Textmodus bzw. max grafischer Textmodus fürs erste das höchste der Gefühle (auch wenn man bei einem OS am liebsten mit der GUI anfangen würde ).

Jein, wenn dein Con-Server und dein GUI-Server gleichzeitig laufen, muss klar erkennbar sein, welcher jetzt gerade aktiv ist. Nur an den darf weitergeleitet werden. Ansonsten: exakt.

Ok, sprich der GUI-Server meldet sich nicht nur beim Con-Server an, sondern auch beim Input-Server und dieser schickt alle Daten an den GUI-Server, welcher die Daten entsprechend weiterleitet.

Der Con-Server sollte keine Fenster öffnen, sondern der GUI-Server. Der Con-Server könnte höchstens ein neues virtuelles Terminal öffnen, aber das fände ich etwas übertrieben. Textanwendungen haben ihr Terminal ja bereits.

Das ist jetzt der Punkt wo ich schwanke. Auf der einen Seite wäre es schön, wenn ich sage das der Con-Server sich um die komplette Fensterverwaltung kümmert (damit meine ich nicht das er das Fenster "erstellen" soll, sondern er "zeichnet" sozusagen die Zeichen in das Fenster). Auf der anderen Seite, könnte ich den Con-Server komplett beenden wenn der GUI-Server erstmal läuft. Nur wird es dann auch schwieriger andere Dinge als Zeichen auszugeben (oder könnte man Funktionen wie CLS oder Cursor-Sachen auch als Escape-Sequenzen implementieren?). Auch würde es den Con-Server schlanker machen. Von daher wäre diese Variante eigentlich zu favorisieren!

Ähm... der Con-Server hat sich aus der grafischen Umgebung rauszuhalten. Da gelten andere Konzepte. Der GUI-Server wiederum sollte keine Terminalemulation bieten, das ist Aufgabe einer Terminalemulator-Anwendung, die für den GUI-Server ein Fenster mit Fokus ist, für die Anwendung darunter ein (Pseudo-)Terminal.

Jetzt wirds wieder unverständlich. Das Problem welches ich habe ist, das ich zwischen einem normalen Fenster und einem Konsolenfenster schon unterscheide und Vereinfachungen vornehmen würde. Deswegen ja die ganze Geschichte mit dem Con-Server zusammen.
Auch würde ich es nicht wollen, das die Terminal-Emulations-Anwendung zwischen TUI und GUI unterscheiden muss. Am liebsten würde ich das so transparent wie möglich halten. Also entweder übernimmt der Con-Server die Fenster-Sachen oder halt der GUI-Server.

Eine andere Frage wäre, wie läuft das denn unter Linux, kann man da auf ein Programm welches ncurses benutzt einfach nen Doppel-Klick machen und der richtige Terminal-Emulator wird aufgerufen oder klappt es nur so, das man nen Terminal-Emulator öffnet und dann erst das Programm starten kann?

Ist der erste Fall richtig, dann müsste ich ja die Terminal-Emulation schon in den Con-Server und/oder den GUI-Server packen, weil ich ja nicht ohne weiteres jedes Programm mit einem bestimmen Terminal-Emulator verbinden kann.

Oder verstehe ich da jetzt wieder was total falsch?

außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.

Blöd gefragt, was kann man denn alles mit den Terminal-ioctls machen? Oder anders wofür ist das gut (ich will ja eigentlich nicht das Konzept "alles ist eine Datei" umsetzen)?

[Svenska]

Hallo,

jetzt wirds sehr lang.

Bitte nicht vergessen, das wir hier über ein Hobby-OS reden, das irgendwann mal auch nen GUI haben möchte und auf allem laufen soll ab P75 (mit ein paar Ausnahmen).
Von daher ist der Textmodus bzw. max grafischer Textmodus fürs erste das höchste der Gefühle (auch wenn man bei einem OS am liebsten mit der GUI anfangen würde ).

Richtig: grafischer Textmodus. Drunter finde ich heutzutage unnötig.

Also dein Kernel startet den GUI-Server, dieser lädt einen Grafiktreiber (VESA). Dieser GUI-Server ist jetzt Eigentümer eines Bildschirms und stellt diesen bereit. Wenn du möchtest, kannst du die Fensterverwaltung (also Erzeugen/Zerstören von Fenstern, Verschieben, Fensterdekoration ...) auch im GUI-Server erledigen, wobei die primitive Variante einfach ein einziges Fenster über den gesamten Bildschirm erzeugt und darin eine Terminalemulation startet. Später kannst du daraus einen Full-Feature Window Manager machen.

Diese Terminalemulation stellt jetzt den Anwendungen ein Terminal nebst Informationen über dasselbige zur Verfügung, also vor allem Typ und Größe. Deine Shell wird nun von der Terminalemulation dort hineingeladen und erhält von ihr stdin/stdout/stderr, welche von der Terminalemulation abgefangen werden. Das Text-Zeichnen kannst du nach Wahl in der Terminalemulation oder im GUI-Server machen.

Das ganze Konzept kommt ohne einen Con-Server aus, da es keine reinen Text-Terminals (VGA-Textmodus) gibt. Die Terminals werden von einem Programm - dem Terminalemulator - zur Verfügung gestellt.

Für die Eingabegeräte gibt es einen Input-Server, der sämtliche Eingabegeräte abfragt und die Informationen an den GUI-Server weiterleitet. Dieser leitet die Eingaben, die nicht für ihn sind, in der primitiven Variante an den einzigen Terminalemulator weiter. (Wenn der GUI-Server zu einem Window Manager erweitert wird, leitet er z.B. an das Vordergrundfenster weiter.)

Mit diesem Ansatz sparst du dir zuerst mal das Hickhack, was du unter *BSD/Linux hast, wenn die grafische Oberfläche dem Textmodus ins Handwerk pfuschst und nebenher auch noch mehrere Terminalemulationen ("linux" im Textmodus, "xterm" in der Terminalemulation) und mehrere Grafiktreiber (VGA-Textmode oder vesafb oder KMS im Textmodus, der X11-Treiber im Grafikmodus) hast, die irgendwie verwaltet werden müssen. Das Konzept ist somit eine Mischung und am Anfang recht einfach umzusetzen, aber halt später auf eine GUI ausgerichtet.

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.

Ok, sprich der GUI-Server meldet sich nicht nur beim Con-Server an, sondern auch beim Input-Server und dieser schickt alle Daten an den GUI-Server, welcher die Daten entsprechend weiterleitet.

Ja. Beziehungsweise du klemmst dir den Con-Server komplett. (Wobei ich nicht wüsste, warum sich der GUI-Server beim Con-Server anmelden müsste. Es kann eh nur einer aktiv sein oder das Umschalten muss von extern geregelt sein.)

Das ist jetzt der Punkt wo ich schwanke. Auf der einen Seite wäre es schön, wenn ich sage das der Con-Server sich um die komplette Fensterverwaltung kümmert (damit meine ich nicht das er das Fenster "erstellen" soll, sondern er "zeichnet" sozusagen die Zeichen in das Fenster).

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.

Auf der anderen Seite, könnte ich den Con-Server komplett beenden wenn der GUI-Server erstmal läuft. Nur wird es dann auch schwieriger andere Dinge als Zeichen auszugeben (oder könnte man Funktionen wie CLS oder Cursor-Sachen auch als Escape-Sequenzen implementieren?).

Genau diese Funktionen sind Steuerzeichen des Terminals und werden nicht direkt dargestellt, sondern ausgeführt. Guck dir mal ANSI-Sequenzen an und was man damit tun kann (z.B. hier, auch die Beispiele).

Auch würde es den Con-Server schlanker machen. Von daher wäre diese Variante eigentlich zu favorisieren!

Bei mir so schlank bis auf Null. Du kannst ja später zu Debugzwecken trotzdem einen CON-Server implementieren, der im VGA-Textmodus genau ein Terminal (80x25, ANSI) simuliert. 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.

Wenn du das so hochziehst - also CON-Server für VGA-Textmodus und GUI-Server für Grafikmodus - bist du insofern auch von der Ausgabeschnittstelle unabhängig. Schließlich kannst du ja auch weitere Server starten, z.B. einen X-Server oder ein serielles Terminal, die dann natürlich unabhängig von CON- und GUI-Server sind.

Jetzt wirds wieder unverständlich. Das Problem welches ich habe ist, das ich zwischen einem normalen Fenster und einem Konsolenfenster schon unterscheide und Vereinfachungen vornehmen würde. Deswegen ja die ganze Geschichte mit dem Con-Server zusammen.

Ich würde da keine Unterscheidung vornehmen. 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).

Auch würde ich es nicht wollen, das die Terminal-Emulations-Anwendung zwischen TUI und GUI unterscheiden muss. Am liebsten würde ich das so transparent wie möglich halten. Also entweder übernimmt der Con-Server die Fenster-Sachen oder halt der GUI-Server.

Der Terminalemulator ist ein grafisches Programm, in ihm laufen Textprogramme. Wenn du grafische Programme darin startest, dann müssen diese sich selbst darum kümmern, ein Fenster zu erzeugen (indem sie sich z.B. beim GUI-Server melden). Das ist dann nicht mehr Aufgabe der Terminalemulation.

Ich unterscheide übrigens zwischen dem Terminal und dem Terminalemulator. Ersteres ist z.B. der VGA-Textmodus im CON-Server oder eine serielle Leitung mit vt100-Protokoll, auf der ausschließlich Textmodus stattfindet (und stdin/stdout/stderr immer existieren). Letzteres ist ein grafisches Programm, welches ein Terminal zur Verfügung stellt.

Eine andere Frage wäre, wie läuft das denn unter Linux, kann man da auf ein Programm welches ncurses benutzt einfach nen Doppel-Klick machen und der richtige Terminal-Emulator wird aufgerufen oder klappt es nur so, das man nen Terminal-Emulator öffnet und dann erst das Programm starten kann?

Nein. Startest du ein Textprogramm wie "mc" ohne Terminalemulator unter X11, dann läuft der zwar, kann aber nichts ausgeben, da er kein stdout hat. Da sämtliche Cursorbewegungen als Steuerzeichen im Terminal codiert sind, unterscheidet sich ein ncurses-Programm nicht von einem primitiven Programm wie "ls": beide nutzen stdout, um ihre Darstellung zu erledigen.

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.

Programme, die grafisch sind, melden sich unter Linux beim X-Server an. Welcher das ist, erfahren sie wieder über eine Umgebungsvariable, in diesem Fall $DISPLAY. (Das geht auch über IP und somit quer durch ein Netzwerk, ich kann also meinen Firefox auf dem grafikkartenlosen Server in der Ecke starten und sehe das Fenster auf meinem kleinem Notebook.) Bei dir wäre das dann der GUI-Server.

Ist der erste Fall richtig, dann müsste ich ja die Terminal-Emulation schon in den Con-Server und/oder den GUI-Server packen, weil ich ja nicht ohne weiteres jedes Programm mit einem bestimmen Terminal-Emulator verbinden kann.

Die Terminalemulation ist Teil des Terminalemulators. Du kannst ja mehrere davon haben, einen der nur ANSI macht, einen der vt220 kann und einen dritten für IBM-Großrechner. Ergo hat die Terminalemulation im GUI-Server nichts zu tun.

Der sollte nur das Rendering selbst erledigen. (Alternativ lässt du das die Anwendungen selbst machen, das kannst du dir aussuchen. Dann muss der GUI-Server aber die Möglichkeiten bereitstellen, da gewisse Sachen ja hardwarebeschleunigt sein könnten.)

Oder verstehe ich da jetzt wieder was total falsch?

Ich hoffe, ich hab mein Konzept hinreichend ausführlich beschrieben und nicht wieder mit der Anlehnung an die mir bekannten Systeme alles verbrannt. Ich glaube, das Konzept ist auch hinreichend generisch/flexibel.

außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.

Blöd gefragt, was kann man denn alles mit den Terminal-ioctls machen? Oder anders wofür ist das gut (ich will ja eigentlich nicht das Konzept "alles ist eine Datei" umsetzen)?

"Alles ist eine Datei" ist aber praktisch.

Allerdings kann ich dir diese Frage nicht beantworten. Wie da die Interna sind, weiß ich nicht.

Gruß,
Svenska