Passer au contenu principal

Ligne de commande Windows, fenêtres à onglets et logiciel JP (partie III)

Dans mon dernier post j'ai parlé des raisons du changement de l'ancien 4NT / Take Command architecture. (Nombreuses limitations de la console Windows pour 4NT et problèmes de fusion des E/S d'une application en ligne de commande avec une ligne de commande GUI dans Take Command.)

Mon nouveau plan a réorganisé les choses donc 4SA (maintenant renommé TCC) était seul responsable de l'interpréteur de ligne de commande et du traitement des fichiers batch. Take Command gérerait toute l'interface graphique, y compris :

  • menus
  • Barres d'outils (les Take Command barre d'outils et la barre d'outils à onglets programmable)
  • La barre d'état
  • La fenêtre de saisie de commande (principalement requise pour l'accessibilité ; nous en parlerons plus tard)
  • Actions de la souris (sélection de texte, menus contextuels, etc.)
  • Fenêtres à onglets pour les applications console (pas seulement TCC, mais n'importe quelle application de console, y compris celles qui écrivent directement sur l'écran), et mettre à jour ces fenêtres avec le contenu de la fenêtre de console masquée appropriée.
  • Communication interprocessus entre les fenêtres de console cachées et d'autres Take Command séances. Cela permettrait également TCC interroger Take Command (et vice versa) pour diverses informations, telles que les sélections dans la vue Dossier et Liste, les poignées de fenêtre, etc.
  • Toutes les E/S du clavier (qui, en fonction de la frappe et des touches d'accélérateur définies, sont redirigées soit vers la fenêtre cachée de la console, soit vers Take Command)

Tout cela était assez simple. Il ne restait plus qu'à avoir Take Command démarrer une session de console cachée et refléter le contenu de sa fenêtre sur un Take Command fenêtre à onglets. Cela ne pourrait pas être trop difficile.

Ha!

Ma première idée était d'utiliser les API d'accessibilité Windows. Après tout, ils sont destinés à ce genre de choses. Mais après quelques semaines de lutte pour résoudre un certain nombre de problèmes, cette approche a dû être abandonnée en raison de deux problèmes insolubles :

  1. Les notifications de mise à jour de l'écran n'étaient pas transmises de manière fiable et étaient parfois envoyées dans le désordre.
  2. Les notifications étaient lentes. Vraiment, vraiment, lentement.

L'idée n°2 était d'utiliser le type d'approche utilisé dans Console2 (une simple interface Windows à onglets open source pour les applications de la console Windows). Cela implique d'injecter une DLL dans chaque processus de console, puis d'utiliser la communication interprocessus pour mettre à jour le Take Command fenêtre à onglets avec le contenu de la fenêtre du processus console. Cette approche présentait un gros avantage :

  • La DLL injectée s’exécutait dans le processus de la fenêtre de la console locale, elle pouvait donc facilement lire le contenu actuel de la fenêtre de la console.

Et plusieurs inconvénients fatals :

  • Lorsque vous injectez du code dans un autre processus, vous êtes désormais responsable de tout ce qui se passe dans ce processus. Ainsi, au lieu de vous soucier uniquement du support Take Command et TCC, je devrais maintenant me soucier de la prise en charge de toutes les applications en ligne de commande, existantes et futures.
  • Il serait impossible d'exécuter des applications DOS (16 bits) dans un Take Command fenêtre. (De toute façon, je ne peux plus faire cela sous Vista et Windows 7, mais à l'époque, je développais encore pour XP et un bon nombre d'utilisateurs exécutaient encore occasionnellement des applications 16 bits.)
  • Il faudrait des versions 32 bits et 64 bits distinctes.
  • De nombreuses applications antivirus signaleront une application injectant du code dans d’autres applications comme un virus possible. (Et ce n’est pas déraisonnable !) J’avais prévu un flot incessant de rapports de « bugs » erronés sur Take Command être infecté par un virus.
  • Applications tierces injectant leur code buggé dans Take Command (et dans une moindre mesure 4NT / TCC) sont pour moi un casse-tête en matière de support depuis plusieurs années. J’ai donc tendance à ne pas voir l’idée d’un bon œil en premier lieu.
  • L'IPC entre le processus de console et Take Command était lent. Pas aussi lent que les notifications d'accessibilité, mais suffisamment lent pour mettre en évidence un ralentissement important lors de l'exécution d'une application dans Take Command par rapport à son exécution dans une console Windows autonome.

Alors jetez quelques semaines supplémentaires de travail sur l’idée n°2, puis sur l’idée n°3. Windows ne permet malheureusement d'attribuer qu'une seule console par session, je ne pouvais donc pas simplement allouer une nouvelle console pour chaque nouvelle fenêtre à onglets et basculer entre elles. Essayer à plusieurs reprises d'allouer et de libérer des consoles a également révélé un bug Windows qui, après quelques centaines d'allocations/libérations, l'API d'allocation de console ne fonctionnait plus. (Même si je ne peux pas vraiment reprocher à Microsoft celui-ci ; je doute qu’il leur soit jamais venu à l’esprit que quelqu’un essaierait de faire quelque chose comme ça.)

À cette époque, je me sentais un peu comme Thomas Edison essayant 10,000 70 matériaux différents lorsqu'il inventait l'ampoule. J'avais découvert plus de XNUMX bogues de l'API Windows/erreurs de documentation/« non-fonctionnalités » non documentées (faites votre choix) jusqu'à présent, et il semblait que Windows faisait tout son possible pour empêcher quiconque de créer un remplacement de console viable.

Suivant : L’idée n°4 est jetée contre le mur…