Jeder der mit MS-Windows-Rechnern zu tun hat, kennt diese schwarzen Fenster, mit dem cmd-Kommamdozeileninterpreter, wenn auch kaum jemand sie mag. Die Unix- und Linux-Leute mögen sie nicht, weil cmd einfach verglichen mit typischen Linux- und Unix-Shells lächerlich wenig kann und die MS-Windows-Leute wollen nicht in der Kommandozeile arbeiten, jedenfalls nicht in dieser. Es gibt Alternativen wie Powershell und cygwin mit bash, aber das schwarze Fenster wird doch meist mit cmd assoziiert. Unter Linux gibt es auch solche Fenster für die Shell, z.B. xterm, aber dort sind sie meistens weiß. Dabei kann man auf beiden Systemen die Farben konfigurieren, wie man will.
NT-basierende MS-Windows-Systeme (NT 3.x, 4.x, 2000, XP, Vista, 7, 8, 10) haben jeweils verschiedene Subsysteme und Programme laufen in diesen Subsystemen, z.B. Win64, Win32, Win16, cygwin, DOS. Weil nun Programme für das DOS-Subsystem typischerweise im CMD-Fenster gestartet wurden und einige der Kommandos, die im CMD angeboten werden, ihren gleichnamigen Vorläufern aus der DOS-Ära von vor 30 Jahren nachempfunden wurden, wurde dieses CMD-Fenster früher (und vielleicht gelegentlich noch heute) oft fälschlicherweise als DOS-Fenster bezeichnet. Dabei kommt dieses schwarze Fenster eigentlich in vielen Situationen zum Vorschein, wenn z.B. ein Win32-Programm gestartet wird, das Ein- und Ausgabe (stdin, stdout, stderr) hat. Wenn diese umgeleitet sind, z.B. in eine Datei oder an ein anderes Programm, kann das Programm unsichtbar ohne schwarzes Fenster starten und gegebenenfalls graphisch in Erscheinung treten. Wenn es keine Umleitung der Ausgabe gibt, wird dem Programm ein solches schwarzes Fenster für die Anzeige der Ausgabe automatisch zur Verfügung gestellt. Und eines dieser Programme mit stdin und stdout ist nun einmal cmd, deshalb wird beim starten von cmd das schwarze Fenster drumherum dazu geliefert. Unter Linux (und Unix mit X11) ist es umgekehrt, man startet xterm bekommt darin die übliche Shell, außer man gibt explizit an, dass etwas anderes darin gestartet werden soll.
Nun empfehle ich einmal ein kleines Experiment. Wir brauchen dazu einen beliebigen graphischen Editor wie z.B. emacs, gvim, ultraedit, textpad, scite, es darf sogar notepad sein. Und ein cmd-Fenster.
- Diese Befehle abschreiben nicht mit Copy&Paste übertragen.
- Im cmd-Fenster mit cd in ein Verzeichnis wechseln, in dem Dateien angelegt werden können (Schreibrecht), falls nötig..
echo "xäöüx" > filec.txt- Die dabei angelegte Datei filec.txt mit dem graphischen Editor öffnen. Wie sehen die Umlaute aus??
- Mit dem Editor im selben Verzeichnis eine neue Datei fileg.txt anlegen, die etwa folgende Zeile enthält: yäöüy.
- Im CMD-Fenster diese ausgeben:
type fileg.txt- Wie sehen jetzt die Umlaute aus?
Es ist ein Feature oder ein Fehler aller gängigen MS-Windows-Versionen, dass diese schwarzen Fenster in der Standardeinstellung die Umlaute auf andere Positionen legen als die graphischen Editoren. Vielleicht weiß jemand, wie man das ändern kann, es würde mich interessieren.
Was ist hier genau passiert? Als die ersten DOS-Versionen Anfang der 1980er-Jahre aufkamen, gab es nur einen halbwegs etablierten Standard für Zeichensatzcodierungen, das war ASCII oder ISO-646-IRV, was immerhin ein großer Fortschritt gegenüber EBCDIC war. Aber dieser normierte nur die unteren 128 Zeichen (7 Bit) und enthielt keine Umlaute oder in Varianten Umlaute statt „irrelevanter“ Zeichen wie „@“, „[„, „~“ u.s.w. So fingen Hersteller und Softwaresysteme an, für die oberen 128 Plätze im Zeichensatz ihre eigene Lösungen zu erfinden. Commodore, Atari, MS-DOS, Apple, NeXT, TeX und überhaupt „alle“ hatten im Laufe der Jahre ihre „Lösungen“ für verschiedene Sprachregionen gefunden, die natürlich jeweils inkompatibel miteinander waren, meist sogar noch zwischen verschiedenen Produktgenerationen oder Ländereinstellungen desselben Herstellers inkompatibel. In Zeiten, wo man sowieso noch kaum Netzwerke hatte, wo es auch eine Sammlung von verschiedenen herstellerspezifischen Formaten für Disketten und herstellerspezifische Netzwerktechnologien gab, fiel das noch nicht so auf. Aber relativ früh wurde es bei X11 (dem gängigen graphischen System für Unix und Linux) üblich, Standardzeichensätze aus der ISO-8859-x-Familie oder später sogar Unicode mit utf-8 und utf-16 zu unterstützen. Linux hat schon in den 0.99-Versionen auch ohne graphische Oberfläche diese ISO-8859-1-Zeichensätze verwendet und nie versucht, seine eigene Zeichensatzcodierung zu erfinden.
Inzwischen sind wohl alle relevanten Systeme auf zum Unicode-Standard kompatible Zeichensatzcodierungen wie ISO-8859-x, utf-8 und utf-16 umgeschwenkt. Aber MS-Windows hat dies nur teilweise umgesetzt. Während das graphische System nur die modernen Codierungen verwendet oder zumindest mit Cp1252 dem recht nahe kommt, hat man für das textbasierte System (schwarze Fenster wie bei cmd) die Codierungen aus der DOS-Zeit von vor über 30 Jahren, wie z.B. Cp850 beibehalten und so einen Bruch innerhalb des System in Kauf genommen, der sehr ärgerlich ist, wenn man mit Daten mit Umlauten in cygwin oder cmd-Fenstern arbeiten will.
Wenn man mutig ist, kann man dieses Verhalten in der Registry ändern. Man muss dazu in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage die Einträge OEMCP und OEMHAL gleichzeitig ändern. Einer ist für die Eingabe und einer für die Ausgabe zuständig, wenn man die also nicht gleichzeitig ändert, wird es sogar innerhalb des schwarzen Fensters inkonsistent. Sucht man danach im Internet, finden sich Beispiele, wo jemand versucht haben will, utf-8 (CP65001) einzustellen und das Ergebnis war, dass er nicht mehr booten konnte. Ich habe nicht überprüft, ob das manipulierte Behauptungen sind, um einer beliebten Firma zu schaden, oder ob es reale Erfahrungen sind. Man kann es mit Virtualisierung relativ risikofrei probieren, indem man sich ein funktionierendes System kopiert und es mit der Kopie testet. Auf jeden Fall ist das Editieren in der Registry nicht ganz risikofrei und geschieht „auf eigene Gefahr“…. Und in vielen Umgebungen ist es nicht möglich, weil die Berechtigungen dafür nicht ausreichen. Man kann es noch mit chcp im schwarzen Fenster selber ändern, vielleicht muss man dort auch noch so etwas wie chhal oder so eingeben, damit der Font passend zur Eingabe codiert ist.
Ob man das als „Bug“ oder lieber wegen der Kompatibilität zu älteren Versionen bis 30 Jahre zurück als Feature bezeichnen sollte, überlasse ich dem Leser.
Schreibe einen Kommentar