Passer au contenu principal

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

Dans mon dernier article, j'ai parlé de certaines des stratégies que j'ai essayées pour afficher les fenêtres de la console dans une fenêtre GUI pendant le Take Command 9 conception et développement.

Les trois premières idées (les API d'accessibilité Windows, l'injection d'une DLL dans les applications console et l'allocation de consoles à partir du Take Command session) avaient tous été abandonnés après avoir rencontré des défauts fatals. L'idée n°4 était de connecter les API de la console Windows afin de pouvoir intercepter tout appel pour lire ou écrire dans une fenêtre de console. (ReadConsole, ReadConsoleInput, WriteConsole, WriteConsoleOutput, etc.) En théorie, cela me fournirait une couverture complète de toutes les E/S de la console, afin que je puisse les gérer, en modifiant ou en redirigeant éventuellement les E/S avant de les transmettre. En pratique, il s'est avéré qu'il présentait tous les inconvénients du n°2 (injection d'une DLL), et quelques autres :

  • Cela nécessitait de modifier dynamiquement d'autres programmes (voir : Est-ce que Take Command infecté par un virus !?).
  • Il a ajouté un lot d'une complexité supplémentaire.
  • Il ne semblait y avoir aucun moyen d'intercepter les mystérieux appels d'API occasionnels qui semblaient provenir de quelque part au plus profond de Windows et qui appelaient des API de console de niveau inférieur non documentées.
  • J'ai rencontré une autre série d'API boguées et/ou mal documentées. (J'en avais trouvé certains à l'époque de NT 3.x – apparemment, Microsoft n'a pas accordé la plus haute priorité à l'amélioration de la fenêtre de la console au cours des 15 dernières années.)
  • En raison de la sous-documentation par Microsoft des API de la console, de nombreux programmes les appelaient de manière incorrecte. Dois-je ignorer les mauvais appels ? Essayer de les corriger et de les transmettre ? Ou traitez-les simplement comme demandé, transmettez-les et espérez qu'ils ne détruiront pas le Take Command l'affichage est trop mauvais ?

Sur le point d'abandonner l'idée des fenêtres de console à onglets, j'ai pensé à inverser l'idée n°3. Au lieu de Take Command créer la console puis lancer l'application de ligne de commande dans cette fenêtre de console, que se passerait-il si je lançais l'application de ligne de commande (qui créerait alors sa propre fenêtre de console cachée) puis que je me connectais Take Command à cette fenêtre de console ? Cette idée présentait certains avantages :

  • Aucune application antivirus ne s’en plaindrait.
  • Take Command pourrait partager la fenêtre de la console avec l'application de ligne de commande (par exemple, TCC), et pouvait lire et écrire directement dans cette fenêtre, sans nécessiter de communication interprocessus entre Take Command et l'application en ligne de commande.
  • Take Command pourrait facilement basculer entre les fenêtres d’onglets en vous déconnectant de la console précédente et en vous connectant à la nouvelle.

Bien sûr, cela n’allait pas être aussi simple. Il y avait un nombre inhabituel (même pour Windows) d'obstacles :

  • Une autre série apparemment infinie d’API Windows boguées/mal documentées. Par exemple, certaines API se comportaient de manière inattendue ou échouaient complètement si la fenêtre de la console était masquée.
  • Cela s’est avéré être un exercice loin d’être trivial, même pour quelque chose d’aussi simple en apparence que Take Command pour obtenir rapidement et de manière fiable le handle de la fenêtre de console de l’application qu’elle vient de démarrer.
  • Le simple fait d'avoir accès à la fenêtre de la console ne signifiait pas que je pouvais mettre à jour le Take Command fenêtre rapidement.
  • J'ai dû surveiller en permanence toutes les fenêtres de la console (même celles qui ne sont pas visibles dans une fenêtre à onglet) pour pouvoir déterminer si l'application s'était fermée, avait modifié sa fenêtre et/ou la taille du tampon (ce qui n'est pas rare), (re)masquer la console. fenêtre si elle était devenue visible d'une manière ou d'une autre (encore une fois, ce n'est pas rare), mettez à jour les titres des onglets, etc.
  • Détectez les instances où l'application console a démarré une autre application, puis s'est arrêtée (en laissant l'application enfant en cours d'exécution, mais avec un ID de processus différent).
  • La saisie au clavier devait être gérée Take Command, filtré de manière appropriée, puis transmis aux fenêtres de la console.
  • L'ordre z des fenêtres devait être continuellement ajusté pour que la mise au point soit au bon endroit.
  • Gérer la fâcheuse tendance des applications DOS à redimensionner le tampon de la fenêtre de la console à 80×25. (Moins on en dit sur le reste des problèmes liés à l’exécution des applications DOS, mieux c’est.)
  • Et tellement d’autres que je me sens glisser dans un état dangereusement dépressif en revivant le long cauchemar…

Si j'avais connu tous les problèmes que j'aurais rencontré par la suite, j'aurais continué à chercher l'idée n°6, ou peut-être accepté un poste de directeur adjoint dans le McDonald's local. Mais je ne le savais pas, alors j’ai progressivement vaincu les problèmes un par un jusqu’à me soumettre. Parfois grâce à une programmation incroyablement intelligente, mais surtout grâce à une analyse heuristique intensive (c'est-à-dire des essais et des erreurs). Il s'avère qu'il y a une bonne raison pour laquelle seule une infime poignée d'autres applications tentent d'implémenter des fenêtres à onglets pour les applications console (et la plupart d'entre elles fonctionnent lentement et mal).

Cette approche adoptée pour Take Command La v9 est toujours utilisée (rationalisée et mise à jour) pour la v13, et je ne prévois aucun changement architectural majeur dans la prochaine version.

Nous sommes donc à jour et je peux recommencer à parler de nouvelles fonctionnalités (et de nouveaux problèmes).