Direkt zum Inhalt

Die Windows-Befehlszeile und JP-Software – eine kurze Geschichte

Ich habe einen neuen Blogeintrag über die Befehlsdialoge in geschrieben Take Command v13, als mir klar wurde, dass die meisten Leser die Geschichte unserer vorherigen Befehlszeilen- und GUI-Produkte nicht kennen würden und nicht wissen würden, wie wir uns für die aktuelle Benutzeroberfläche entschieden haben.

In den späten 1980er Jahren schrieb ich BIOS und Netzwerksoftware für DOS. Ich hatte eine Reihe von Dienstprogrammen geschrieben, um die Entwicklung zu vereinfachen, und habe sie schließlich in den Vorgänger von 4DOS (eine Befehlsshell für DOS) integriert. Microsoft hatte es in DOS 2.0 ermöglicht, den Befehlsprozessor (COMMAND.COM) zu ersetzen, obwohl dies erst mit DOS 3.0 praktikabel wurde. JP Software veröffentlichte schließlich 4 die erste kommerzielle Version von 1989DOS. Es folgten 4OS2 (ein Ersatz für CMD in OS/2) und 4NT (ein Ersatz für CMD in NT 3.1).

In den frühen 90er Jahren machten sowohl Microsoft als auch IBM Gerüchte über die Abschaffung der Befehlszeile in der nächsten Version von OS/2/Windows NT. Mehrere Benutzer drängten mich, eine GUI-Version der Befehlszeile zu erstellen, damit sie nicht gezwungen waren, auf eine Point-and-Click-GUI umzusteigen. Daraus entstand die erste Version von Take Command. Es sah genauso aus wie die Befehlszeilenversion, verfügte jedoch über einen minimalen GUI-Wrapper (mit Menü, Symbolleiste und Statusleiste). Take Command/16 (für Windows 3.x) folgte Take Command/OS2 und Take Command/32 (für Windows NT 3.x). Funktionell waren die Kommandozeilenversionen (4DOS, 4NT, 4OS2) und die GUI-Versionen grundsätzlich identisch. Die Befehlszeilenversionen waren überverkauft Take Command mit etwa 2:1 in den USA und Deutschland, und Take Command Im Rest der Welt wurden die Befehlszeilenversionen um 2:1 übertroffen. (Das habe ich immer noch nicht herausgefunden!)

Das Problem mit den GUI-Versionen bestand darin, dass man eine Befehlszeilen-App ausführen wollte. Niemand wollte, dass ein Zeichenmodusfenster auftauchte, das Programm ausführte und wieder verschwand. Der erste Ansatz zur Lösung dieses Problems wurde „Caveman“ genannt und bestand darin, das Zeichenmodusfenster auszublenden, die App auszuführen, den Inhalt des ausgeblendeten Fensters zu lesen und die Ausgabe im GUI-Fenster anzuzeigen. Tastatureingaben wurden im GUI-Fenster abgefangen und in das ausgeblendete Fenster umgeleitet. Das meist funktionierte, obwohl es verschiedene Probleme mit Apps gab, die ihre Ausgabe pufferten oder zufällig auf verschiedene Teile des Displays schrieben. (Es gab sogar eine bekannte Befehlszeilenanwendung, die ihre Ausgabe an den Anfang der Zeile, dann an das Ende der Zeile und dann in die Mitte schrieb.)

Zu diesem Zeitpunkt wurden wir von beiden Seiten bedrängt. Befehlszeilenbenutzer wünschten sich eine bessere Befehlszeilen-Benutzeroberfläche und Take Command Benutzer wünschten sich eine bessere Befehlszeilenfunktionalität. Der erste Versuch, die bessere Befehlszeilen-Benutzeroberfläche anzusprechen, hieß TCI (Tabbed Console Interface). TCI sah aus wie Take Command verhielt sich aber wie 4NT. TCI verfügte über ein Menü und eine Symbolleiste, vor allem aber über Fenster mit Registerkarten, in denen Windows-Konsolenanwendungen (4NT, CMD usw.) ausgeführt wurden. Es verwendete eine (stark aktualisierte) Version von Caveman (was mit 32-Bit-Windows viel einfacher war als mit 16-Bit-Windows – kein VxD erforderlich!), und konnte fast alle Befehlszeilen-Apps ausführen. Es war nicht besonders schön, aber es hat seinen Zweck erfüllt. (TCI war in etwa vergleichbar mit Console2, einer Open-Source-Konsolenfensteranwendung mit Registerkarten, die sich seit mehreren Jahren in der Betaphase befindet, obwohl TCI völlig andere Methoden zum Lesen und Anzeigen der verborgenen Konsolenfensterinhalte verwendete als Console2.)

Zu diesem Zeitpunkt hatten wir also 4NT, TCI und Take Command/32 (Windows 3.x und OS/2 sind abgelaufen und 4DOS funktioniert kaum noch mit Lebenserhaltung). Es gab erhebliche Überschneidungen, erheblichen zusätzlichen Entwicklungsaufwand und erhebliche Verwirrung bei den Endbenutzern. Es war an der Zeit, das Befehlszeilenparadigma zu überdenken und umzurüsten.