Direkt zum Inhalt

Windows-Befehlszeile, Windows mit Registerkarten und JP-Software (Teil III)

In meinem letzten Beitrag habe ich über die Gründe für den Wechsel des alten 4NT gesprochen / Take Command die Architektur. (Zahlreiche Einschränkungen der Windows-Konsole für 4NT und Probleme beim Zusammenführen der Befehlszeilen-Anwendungs-E/A mit einer GUI-Befehlszeile in Take Command.)

Mein neuer Plan hat die Dinge neu organisiert, also 4NT (jetzt umbenannt). TCC) war allein für den Befehlszeileninterpreter und die Batchdateiverarbeitung verantwortlich. Take Command würde die gesamte GUI übernehmen, einschließlich:

  • Menüs
  • Symbolleisten (die Take Command Symbolleiste und die programmierbare Symbolleiste mit Registerkarten)
  • Statusleiste
  • Das Befehlseingabefenster (hauptsächlich für die Barrierefreiheit erforderlich; mehr dazu später)
  • Mausaktionen (Textauswahl, Kontextmenüs usw.)
  • Fenster mit Registerkarten für die Konsolenanwendungen (nicht nur TCC, aber jede Konsolen-App, einschließlich solcher, die direkt auf den Bildschirm schreiben) und Aktualisieren dieser Fenster mit dem Inhalt des entsprechenden versteckten Konsolenfensters.
  • Interprozesskommunikation zwischen den versteckten Konsolenfenstern und anderen Take Command Sitzungen. Dies würde es auch ermöglichen TCC Abfragen Take Command (und umgekehrt) für verschiedene Informationen, wie z. B. die Auswahl in der Ordner- und Listenansicht, Fenstergriffe usw.
  • Alle Tastatur-E/A (die abhängig vom Tastendruck und allen definierten Zugriffstasten entweder zum ausgeblendeten Konsolenfenster oder zu umgeleitet werden Take Command)

Das war alles ziemlich einfach. Das Einzige, was noch zu tun blieb, war zu haben Take Command Starten Sie eine versteckte Konsolensitzung und spiegeln Sie den Inhalt ihres Fensters auf a Take Command Fenster mit Registerkarten. Das kann nicht allzu schwer sein.

Ha!

Meine erste Idee war, die Windows-Barrierefreiheits-APIs zu verwenden. Schließlich sind sie genau für so etwas gedacht. Doch nachdem man sich ein paar Wochen lang damit abgemüht hatte, eine Reihe von Problemen zu umgehen, musste dieser Ansatz wegen zweier unlösbarer Probleme verworfen werden:

  1. Die Benachrichtigungen über Bildschirmaktualisierungen wurden nicht zuverlässig und gelegentlich nicht in der richtigen Reihenfolge zugestellt.
  2. Die Benachrichtigungen waren langsam. Wirklich, wirklich, langsam.

Idee Nr. 2 bestand darin, den in Console2 verwendeten Ansatz zu verwenden (eine einfache Open-Source-Windows-Oberfläche mit Registerkarten für Windows-Konsolen-Apps). Dies beinhaltet das Einfügen einer DLL in jeden Konsolenprozess und die anschließende Aktualisierung der prozessübergreifenden Kommunikation Take Command Tab-Fenster mit dem Inhalt des Fensters des Konsolenprozesses. Dieser Ansatz hatte einen großen Vorteil:

  • Die eingefügte DLL wurde im Prozess des lokalen Konsolenfensters ausgeführt, sodass sie den aktuellen Inhalt des Konsolenfensters problemlos lesen konnte.

Und mehrere fatale Nachteile:

  • Wenn Sie Code in einen anderen Prozess einfügen, sind Sie nun für alles verantwortlich, was in diesem Prozess passiert. Anstatt sich also nur um den Support kümmern zu müssen Take Command und TCC, müsste ich mich jetzt um die Unterstützung aller vorhandenen und zukünftigen Befehlszeilenanwendungen kümmern.
  • Es wäre unmöglich, DOS-Apps (16-Bit) in einem auszuführen Take Command Fenster. (Das geht unter Vista und Windows 7 sowieso nicht mehr, aber damals habe ich noch für XP entwickelt und es gab eine ganze Reihe von Benutzern, die noch gelegentlich eine 16-Bit-App ausführten.)
  • Es müsste separate 32-Bit- und 64-Bit-Versionen geben.
  • Viele Antiviren-Apps kennzeichnen eine App, die Code in andere Apps einschleust, als möglichen Virus. (Und das nicht ungerechtfertigt!) Ich habe einen nicht enden wollenden Strom fehlerhafter „Bug“-Berichte vorhergesehen Take Command mit einem Virus infiziert sein.
  • Apps von Drittanbietern, die ihren fehlerhaften Code einschleusen Take Command (und in geringerem Maße 4NT / TCC) bereiten mir seit mehreren Jahren Support-Kopfschmerzen. Daher neige ich dazu, die gesamte Idee von vornherein nicht positiv zu bewerten.
  • Der IPC zwischen dem Konsolenprozess und Take Command war langsam. Nicht so langsam wie die Benachrichtigungen zur Barrierefreiheit, aber langsam genug, um auf eine erhebliche Verlangsamung beim Ausführen einer Anwendung hinzuweisen Take Command im Vergleich zur Ausführung in einer eigenständigen Windows-Konsole.

Werfen Sie also noch ein paar Wochen Arbeit an Idee Nr. 2 weg und machen Sie sich an Idee Nr. 3. Windows erlaubt leider nur die Zuweisung einer einzelnen Konsole pro Sitzung, sodass ich nicht einfach jedem neuen Fenster mit Registerkarten eine neue Konsole zuweisen und zwischen ihnen wechseln konnte. Beim Versuch, Konsolen wiederholt zuzuweisen und freizugeben, trat auch ein Windows-Fehler auf, der dazu führte, dass die Konsolenzuweisungs-API nach einigen hundert Zuweisungen/Freigaben nicht mehr funktionierte. (Obwohl ich Microsoft diesbezüglich nicht wirklich etwas vorwerfen kann; ich bezweifle, dass ihnen jemals in den Sinn gekommen wäre, dass jemand so etwas versuchen würde.)

Zu diesem Zeitpunkt fühlte ich mich ein wenig wie Thomas Edison, der 10,000 verschiedene Materialien ausprobierte, als er die Glühbirne erfand. Ich hatte bisher mehr als 70 Windows-API-Bugs/Dokumentationsfehler/undokumentierte „Unfeatures“ (wählen Sie Ihre Wahl) aufgedeckt, und es schien, dass Windows alles daran setzte, niemanden daran zu hindern, einen brauchbaren Konsolenersatz zu erstellen.

Weiter: Idee Nr. 4 wird gegen die Wand geworfen …