Saltar al contenido principal

Línea de comandos de Windows, Windows con pestañas y software JP (Parte III)

En mi último post hablé de los motivos para cambiar el antiguo 4NT/ Take Command arquitectura. (Numerosas limitaciones de la consola de Windows para 4NT y problemas al fusionar la e/s de la aplicación de línea de comando con una línea de comando GUI en Take Command.)

Mi nuevo plan reorganizó las cosas de modo que 4NT (ahora renombrado TCC) era el único responsable del intérprete de línea de comandos y del procesamiento de archivos por lotes. Take Command manejaría toda la GUI, incluyendo:

  • Menús
  • Barras de herramientas (las Take Command barra de herramientas y la barra de herramientas con pestañas programables)
  • Barra de estado
  • La ventana de entrada de comandos (principalmente necesaria para la accesibilidad; más sobre esto más adelante)
  • Acciones del mouse (selección de texto, menús contextuales, etc.)
  • Ventanas con pestañas para las aplicaciones de consola (no sólo TCC, sino cualquier aplicación de consola, incluidas las que escriben directamente en la pantalla), y actualizar esas ventanas con el contenido de la ventana de consola oculta adecuada.
  • Comunicación entre procesos entre las ventanas de la consola oculta y otras Take Command sesiones. Esto también permitiría TCC para consultar Take Command (y viceversa) para información diversa, como las selecciones en la vista de carpetas y listas, identificadores de ventanas, etc.
  • Todas las E/S del teclado (que, según la pulsación de tecla y las teclas aceleradoras definidas, se redirigen a la ventana oculta de la consola o a Take Command)

Todo eso fue bastante sencillo. Lo único que faltaba era tener Take Command iniciar una sesión de consola oculta y reflejar el contenido de su ventana en un Take Command ventana con pestañas. Eso no podría ser demasiado difícil.

¡Ja!

Mi primera idea fue utilizar las API de accesibilidad de Windows. Después de todo, están destinados precisamente a este tipo de cosas. Pero después de un par de semanas luchando por solucionar una serie de problemas, ese enfoque tuvo que ser descartado debido a dos problemas irresolubles:

  1. Las notificaciones de actualización de la pantalla no se entregaron de manera confiable y, en ocasiones, se entregaron fuera de servicio.
  2. Las notificaciones eran lentas. Muy, muy lento.

La idea n.º 2 era utilizar el tipo de enfoque utilizado en Console2 (una sencilla interfaz de Windows con pestañas de código abierto para aplicaciones de consola de Windows). Esto implica inyectar un dll en cada proceso de la consola y luego usar la comunicación entre procesos para actualizar el Take Command ventana de pestaña con el contenido de la ventana del proceso de la consola. Este enfoque tenía una gran ventaja:

  • La DLL inyectada se estaba ejecutando en el proceso de la ventana de la consola local, por lo que podía leer fácilmente el contenido actual de la ventana de la consola.

Y varias desventajas fatales:

  • Cuando inyectas código en otro proceso, ahora eres responsable de todo lo que sucede en ese proceso. Entonces, en lugar de tener que preocuparse sólo por apoyar Take Command y TCC, ahora tendría que preocuparme por dar soporte a todas las aplicaciones de línea de comandos, existentes y futuras.
  • Sería imposible ejecutar aplicaciones de DOS (16 bits) en un Take Command ventana. (De todos modos, ya no puedo hacer eso en Vista y Windows 7, pero en ese momento todavía estaba desarrollando para XP y había un buen número de usuarios que todavía ejecutaban alguna aplicación ocasional de 16 bits).
  • Sería necesario que hubiera versiones separadas de 32 y 64 bits.
  • Muchas aplicaciones antivirus marcarán una aplicación que inyecta código en otras aplicaciones como un posible virus. (¡Y no sin razón!) Preví un flujo interminable de informes erróneos de "errores" sobre Take Command estar infectado con un virus.
  • Aplicaciones de terceros que inyectan su código con errores Take Command (y en menor grado 4NT / TCC) han sido un dolor de cabeza para mí durante varios años. Así que, en primer lugar, tiendo a no ver con buenos ojos toda la idea.
  • El IPC entre el proceso de la consola y Take Command fue lento. No es tan lento como las notificaciones de accesibilidad, pero lo suficientemente lento como para resaltar una desaceleración significativa al ejecutar una aplicación en Take Command en comparación con ejecutarlo en una consola de Windows independiente.

Entonces, desperdicie algunas semanas más de trabajo en la idea n.° 2 y pase a la idea n.° 3. Desafortunadamente, Windows solo permite asignar una única consola por sesión, por lo que no podía simplemente asignar una nueva consola para cada nueva ventana con pestañas y cambiar entre ellas. Al intentar asignar y liberar consolas repetidamente también apareció un error de Windows que después de unos cientos de asignaciones/liberaciones, la API de asignación de consola ya no funcionaba. (Aunque no puedo culpar a Microsoft por esto; dudo que alguna vez se les haya ocurrido que alguien intentaría hacer algo como esto).

En ese momento me sentía un poco como Thomas Edison probando 10,000 materiales diferentes cuando estaba inventando la bombilla. Había descubierto más de 70 errores de la API de Windows/errores de documentación/”características” no documentadas (elija), y parecía que Windows estaba haciendo todo lo posible para evitar que alguien creara un reemplazo de consola viable.

Próximo: La idea n.° 4 queda arrojada contra la pared...