Konsolenanwendung - crt.pas - Console Library

[KodeZwerg]

Zitat von arcticwolf:

Zitat von himitsu:

Jetzt läuft ja hinter der cmd.exe bzw. der neuen Terminal-App ein Console-Host, je nach Ziel (Windows-Console, PowerShell, Linux-Bash usw)

Ich hatte mal versucht rauszufinden, wie das intern abläuft, aber in der Hilfe noch nicht wirklich was gefunden, bzw. im QuellCode des Terminals, da sieht doch niemand durch.

Sonst hätte man sich da auch "einfach" was mit Delphi bauen können.

https://github.com/microsoft/terminal
https://learn.microsoft.com/de-de/windows/terminal/
https://apps.microsoft.com/store/det...l/9N0DX20HK701

https://www.golem.de/news/windows-11...08-167912.html
https://www.computerbild.de/artikel/...-30464147.html

Bis eben hatte ich das Windows-Terminal noch gar nicht installiert, also wurde bei mir automatisch der Windows-Konsolenhost verwendet. Unter dem Windows-Terminal läuft mein Code nicht sauber. Sobald das Windows-Terminal installiert ist, kann man unter "Datenschutz und Sicherheit > Für Entwickler > Terminal" einstellen, ob "Windows-Konsolenhost" oder "Windows-Terminal" verwendet werden soll. Wählt man hier den Windows-Konsolenhost läuft mein Code wieder sauber. Jetzt wäre es natürlich interessant zu wissen, ob man Windows irgendwie aus der App heraus vorgeben kann ob der Konsolenhost oder das Terminal verwendet werden soll, unabhängig von der oben genannten Windows-Einstellung. Da muss ich erst einmal recherchieren, oder hat von Euch jemand eine Idee.

Ferner wäre es natürlich interessant zu wissen, ob der Code auch kompatibel zum Windows-Terminal gemacht werden kann. Ein kurzer Test war da eigentlich sehr vielversprechend. Einige der Grundfunktionen die ich nutze scheinen direkt vom Terminal unterstüzt zu werden. Aber für eine ordentliche Bewertung muss ich mich wohl erst mal wieder in der MSDN und/oder der Dokumentation vom Terminal eingraben...

Kannst Du mal mit diesem Schnippsel prüfen was unter einem Terminal rauskommt?

Delphi-Quellcode:

function IsConsole: Boolean;
var
  Stdout: THandle;
begin
  Stdout := GetStdHandle(Std_Output_Handle);
  Win32Check(Stdout <> Invalid_Handle_Value);
  Result := Stdout <> 0;
end;

Laut hier -> https://learn.microsoft.com/en-us/wi...e/getstdhandle sollte es nur für eine Konsole funktionieren.

[arcticwolf]

Zitat:

Stdout := GetStdHandle(Std_Output_Handle);

Liefert bei Terminal schon ein gültiges Handle, sogar das gleiche wie bei Konsolenhost. Siehe Ply.Console.Pas Zeile 3839

ConHandleStdOut := GetStdHandle(STD_OUTPUT_HANDLE);

Zum Beispiel die Demo01 (Minimal_Console_App) läuft auch auf einem Terminal. Aber wenn es dann an die erweiterten Funktionen, wie z.B. manipulieren des Font, Änderung der Größe des Konsolenfensters, u.s.w. geht, dann funktioniert das nicht mehr wie gehabt.

[KodeZwerg]

Ich verstehe.
Was für einen Prozess startet denn eine Konsolen Anwendung mit installierten Terminal?
Mit der klassischen Konsolen Anwendung hab ich "conhost.exe" unter meiner ProcessID.

[himitsu]

GetStdHandle sollte so oder so gehen, denn ob die CMD oder das Terminal, die Daten-Pipe bleibt die Gleiche.
Nur dass sie seit einer Weile über die ConHost-EXEn behandelt werden
und es somit möglich ist hinten einen anderen Viewer anzuhängen oder vorne eine andere Datenquelle (Console, PowerShell, Python, eine Linux-Bash, sowie die Consolen vom MAC, Android, Azure, AWS usw.).


Wie gesagt, die alte API läuft parallel zu den 3 Consolen-Handle vom Windows, über einen eigenen Kanal. (weiß garnicht, ob Linux einen eigenen Error-Stream hat, aber da eh kaum Windows-Programme Diesen nutzen, ist er fast egal)
Im neuen Streaming werden Daten und Control-Befehle im selben Stream übertragen. Ähnlich wie ganz früher, mit den EscapeCodes.




Sobald beim Start die Console nicht verbunden war (z.B. bei einer VCL-Anwendung), oder wenn die Pipe umgeleitet wird, oder der "Viewer" diese ControlPipe nicht explizit abfragt, dann kann das nicht funktionieren.

Über AttachConsole/AllocConsole könnte man prüfen ob eine "Console" dran hängt, oder z.B. die Pipe in ein anderes Programm umgeleitet ist. (siehe mein alter FileSplitter, der prüfte, ob er aus der Console, bzw. einer Batch, oder z.B. aus dem Explorer, einem Link oder via ShellExecute/CreateProcess gestartet wurde)

[arcticwolf]

Zitat von KodeZwerg:

Ich verstehe.
Was für einen Prozess startet denn eine Konsolen Anwendung mit installierten Terminal?
Mit der klassischen Konsolen Anwendung hab ich "conhost.exe" unter meiner ProcessID.

Wenn ich das Programm als Terminal starte, dann habe ich in der Prozessliste eine "WindowsTerminal.exe", eine "conhost.exe" und die "Demo01_Minimal_Console_App.exe".
Wenn ich das Programm als Konsolenhost starte, dann habe ich in der Prozessliste eine "conhost.exe" und die "Demo01_Minimal_Console_App.exe".

[Andreas13]

Hallo Wolfgang,
vielen Dank für die Anpassung & Verbesserung Deiner Console Library an ältere Delphi-Versionen! Nun lassen sich mit XE5 alle 9 Units der Bibliothek kompilieren.
Allerdings läßt sich nur ein einziges der 8 Demo-Programme kompilieren: Demo01_Minimal_Console_App.dpr
Bei den übrigen kommt es zu etlichen Fehlermeldungen:

Delphi-Quellcode:

u. a. 
begin
  Result := (FTextAttr and COMMON_LVB_REVERSE_VIDEO) = COMMON_LVB_REVERSE_VIDEO;
end;

[dcc32 Fehler] Ply.Console.pas(951): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_REVERSE_VIDEO'
… 
[dcc32 Fehler] Ply.Console.pas(963): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_HORIZONTAL'
[dcc32 Fehler] Ply.Console.pas(981): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_LVERTICAL'
[dcc32 Fehler] Ply.Console.pas(987): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_UNDERSCORE'
[dcc32 Fehler] Ply.Console.pas(999): E2003 Undeklarierter Bezeichner: 'COMMON_LVB_GRID_RVERTICAL'

etc.

Weitere Fehlermeldungen habe ich im Anhang.

Vielleicht findest Du noch eine Lösung für XE5-Benutzer(innen)...

[arcticwolf]

Hallo Andreas,

bitte schau noch einmal ob sich Demo01 wirklich immer noch kompilieren lässt.

Ich würde vermuten, da hat sich bei Dir irgendwo im Quellcode ein oder mehrere Zeichen eingeschlichen, die da nicht sein sollten. Wenn sich Demo01 kompilieren lässt, warum sollte sich die Ply.Console.Pas (die bei Demo01 auch benötigt wird) dann bei Demo02 nicht mehr kompilieren lassen?

Wenn alles nicht hilft, mach bitte noch einmal einen neuen pull von GitHub.

[Andreas13]

Hallo Wolfgang,

Du hast recht: Auch Demo01_Minimal_Console_App.dpr läßt sich nicht kompilieren:

Delphi-Quellcode:

[dcc32 Fehler] Demo01_Minimal_Console_App.dpr(13): E2003 Undeklarierter Bezeichner: 'Console'
[dcc32 Fehler] Demo01_Minimal_Console_App.dpr(13): E2035 Nicht genügend wirkliche Parameter

Die erste Zeile Console.Window(80,25); verursacht die Probleme.

Versehentlich hatte ich am Nachmittag eine Kopie von Demo01_Minimal_Console_App.dpr von gestern kompiliert...

[arcticwolf]

Hallo Andreas,

irgendwie macht das keinen Sinn. Wenn Du sagst

Zitat:

Nun lassen sich mit XE5 alle 9 Units der Bibliothek kompilieren.

der Compiler aber dann die "Var Console" nicht findet, die in der Crt.pas in Zeile 78 deklariert ist, dann würde ich vermuten, dass bei Dir irgendwas mit den Pfaden nicht stimmt. Im Projekt ist der Suchpfad auf das Parent-Directory ".." eingestellt. Also oberhalb von \Demo. Wenn Du an den Pfaden nichts geändert hast, sollte er die (meine) crt.pas finden und damit auch die "Var Console". Räum doch bitte mal auf und lösche alles was nicht mit dem GitHub Repository kommt. Also vor allem die Verzeichnisse .\Demo\Win32\ und .\Demo\Win64\ um zu vermeiden, dass der Compiler da eine alte crt.dcu findet.

Oder der Compiler findet noch irgendeine andere crt.pas oder crt.dcu? Schau mal im globalen Suchpfad, siehe "Tools -> Optionen -> Delphi -> Bibliothek" o.ä. je nach Delphi-Version. Das würde erklären, warum der dann in der Unit Crt keine "Var Console" findet.