APIs do Console Clássico versus Sequências de Terminal Virtual

Nossa recomendação é substituir a API clássica do Console do Windows por sequências de terminal virtual. Este artigo descreverá a diferença entre os dois e discutirá os motivos de nossa recomendação.

Definições

A superfície clássica da API do Console do Windows é definida como a série de interfaces funcionais da linguagem C com kernel32.dll "Console" no nome.

As sequências de terminal virtual são definidas como uma linguagem de comandos embutida nos fluxos de entrada e saída padrão. As sequências de terminal virtual usam caracteres de escape não imprimíveis para sinalizar comandos intercalados com texto imprimível normal.

História

O Console do Windows fornece uma ampla superfície de API para aplicativos de linha de comando cliente manipularem o buffer de exibição de saída e o buffer de entrada do usuário. No entanto, outras plataformas não Windows nunca têm proporcionado essa abordagem específica orientada por API para seus ambientes de linha de comando, optando por usar sequências de terminal virtual inseridas nos fluxos de entrada e saída padrão padrão. (Por um tempo, a Microsoft também deu suporte a esse comportamento nas primeiras edições do DOS e do Windows por meio de um driver chamado ANSI.SYS.)

Por outro lado, as sequências de terminal virtual (em uma variedade de dialetos) conduzem as operações de ambiente de linha de comando para todas as outras plataformas. Essas sequências estão enraizadas em um ECMA Standard e em uma série de extensões por muitos fornecedores, remontando à Digital Equipment Corporation e aos terminais Tektronix, até terminais de software mais modernos e comuns, como xterm. Existem muitas extensões dentro do domínio das sequências de terminais virtuais e algumas sequências têm mais suporte do que outras, mas é seguro dizer que o padrão mundial adotou esta sequência como a linguagem padrão para interfaces de linha de comando, com um subconjunto bem conhecido sendo suportado por praticamente todos os aplicativos de terminal e cliente de linha de comando.

Suporte multiplataforma

As sequências de terminal virtual têm suporte nativo em plataformas, tornando aplicativos terminais e utilitários de linha de comando facilmente portáteis entre versões e variações de sistemas operacionais, com exceção do Windows.

Por outro lado, as APIs do Console do Windows só têm suporte no Windows. Um extenso adaptador ou biblioteca de tradução deve ser escrito entre o Windows e o terminal virtual, ou vice-versa, ao tentar portar utilitários de linha de comando de uma plataforma ou de outra.

Acesso remoto

As sequências de terminal virtual têm uma grande vantagem para o acesso remoto. Elas não exigem trabalho adicional para transportar ou executar chamadas de procedimento remoto com relação ao que é necessário para configurar uma conexão de linha de comando remota padrão. Simplesmente conectar um canal de transporte de saída e um de entrada (ou um único canal bidirecional) por meio de um pipe, socket, arquivo, porta serial ou qualquer outro dispositivo é suficiente para transportar completamente todas as informações necessárias para um aplicativo que comunica essas sequências a um host remoto.

Pelo contrário, as APIs do Console do Windows só foram acessíveis no computador local e todos os esforços para remotar eles exigiriam a criação de uma camada de interface de transporte e chamada remota inteira além de apenas um canal simples.

Separação de interesses

Algumas APIs do Console do Windows fornecem acesso de baixo nível aos buffers de entrada e saída ou funções de conveniência para linhas de comando interativas. Isso pode incluir aliases e histórico de comandos programados no subsistema do console e no ambiente de host, em vez de no próprio aplicativo cliente de linha de comando.

Por outro lado, outras plataformas fazem da memória do estado atual do aplicativo e da funcionalidade de conveniência a responsabilidade do utilitário de linha de comando ou do próprio shell.

A maneira do Console do Windows de lidar com essa responsabilidade no host e na API do console torna mais rápido e fácil escrever um aplicativo de linha de comando com esses recursos, removendo a responsabilidade de lembrar o estado do desenho ou lidar com a edição de recursos de conveniência. No entanto, isso torna quase impossível conectar essas atividades remotamente entre plataformas, versões ou cenários devido a variações de implementações e disponibilidade. Essa maneira de lidar com a responsabilidade também torna a experiência interativa final desses aplicativos de linha de comando do Windows completamente dependente da implementação, das prioridades e do ciclo de lançamento do host do console.

Por exemplo, recursos avançados de edição de linha, como realce de sintaxe e seleção complexa, só são possíveis quando um aplicativo de linha de comando lida com a edição em si. O console nunca poderia ter contexto suficiente para entender completamente esses cenários de maneira ampla como o aplicativo cliente pode.

Por outro lado, outras plataformas usam sequências de terminal virtual para lidar com essas atividades e a própria comunicação de terminal virtual por meio de bibliotecas reutilizáveis do lado do cliente, como readline e ncurses. O terminal final é responsável apenas por exibir informações e receber entrada por meio desse canal de comunicação bidirecional.

Verbos incorretos

Com o Console do Windows, algumas ações podem ser executadas na direção oposta à natural nos fluxos de entrada e saída. Isso permite que aplicativos de linha de comando do Windows evitem a preocupação de gerenciar seus próprios buffers. Ele também permite que aplicativos de linha de comando do Windows executem operações avançadas, como simular/injetar entrada em nome de um usuário ou ler parte do histórico do que foi escrito.

Embora isso forneça energia adicional para aplicativos do Windows que operam em um contexto de usuário específico em um único computador, ele também fornece um vetor para cruzar os níveis de segurança e privilégios ou domínios quando usado em determinados cenários. Esses cenários incluem a operação entre contextos no mesmo computador ou entre contextos para outro computador ou ambiente.

Outras plataformas, que usam sequências de terminal virtual, não permitem essa atividade. A intenção de nossa recomendação para fazer a transição do Console clássico do Windows para sequências de terminal virtual é convergir com essa estratégia por motivos de interoperabilidade e segurança.

Acesso direto à janela

A superfície da API do Console do Windows fornece o identificador de janela exato para a janela anfitriã. Isso permite que um utilitário de linha de comando execute operações de janela avançadas, alcançando a ampla gama de APIs Win32 permitidas em um identificador de janela. Essas APIs Win32 podem manipular o estado da janela, o quadro, o ícone ou outras propriedades sobre a janela.

Por outro lado, em outras plataformas com sequências de terminal virtual, há um conjunto restrito de comandos que podem ser executados na janela. Esses comandos podem fazer coisas como alterar o tamanho da janela ou o título exibido, mas eles devem ser feitos na mesma banda e sob o mesmo controle que o restante do fluxo.

Conforme o Windows evoluiu, os controles de segurança e as restrições dos identificadores de janela aumentaram. Além disso, a natureza e a existência de um identificador de janela endereçável por aplicativo em qualquer elemento específico da interface do usuário evoluíram, especialmente com o aumento do suporte de plataformas e fatores forma do dispositivo. Isso torna o acesso de janela direta a aplicativos de linha de comando frágil à medida que a plataforma e as experiências evoluem.

Unicode

UTF-8 é a codificação aceita para dados Unicode em quase todas as plataformas modernas, pois atinge o equilíbrio certo entre portabilidade, tamanho de armazenamento e tempo de processamento. No entanto, o Windows historicamente escolheu UTF-16 como sua codificação primária para dados Unicode. O suporte para UTF-8 está aumentando no Windows e o uso desses formatos Unicode não impede o uso de outras codificações.

A plataforma console do Windows tem suporte e continuará a dar suporte a todas as páginas de código e codificações existentes. Use UTF-16 para compatibilidade máxima entre versões do Windows e execute a tradução algorítmica com UTF-8, se necessário. O aumento do suporte do UTF-8 está em andamento para o sistema de console.

O suporte a UTF-16 no console pode ser utilizado sem nenhuma configuração adicional por meio da variante W de todas as APIs de console e é uma opção mais provável para aplicativos já bem versados no UTF-16 por meio da comunicação com a wchar_t variante W de outras funções e produtos da plataforma Microsoft e windows.

O suporte a UTF-8 no console pode ser utilizado por meio da variante A de APIs de Console em identificadores de console após definir a página de código como 65001 ou CP_UTF8 usando os métodos SetConsoleOutputCP e SetConsoleCP, conforme apropriado. Definir as páginas de código com antecedência só será necessário se o computador não tiver escolhido "Usar Unicode UTF-8 para suporte de idioma mundial" nas configurações para aplicativos não Unicode na seção Região do Painel de Controle.

Recomendações

Para todo o desenvolvimento novo e contínuo no Windows, as sequências de terminal virtual são recomendadas como a maneira de interagir com o terminal. Isso convergirá aplicativos cliente de linha de comando do Windows com o estilo de programação de aplicativos em todas as outras plataformas.

Exceções para o uso de APIs do Console do Windows

Um subconjunto limitado de APIs do Console do Windows ainda é necessário para estabelecer o ambiente inicial. A plataforma Windows ainda é diferente de outras em tratamento de processo, sinal, dispositivo e codificação:

• Os identificadores padrão de um processo ainda serão controlados com GetStdHandle e SetStdHandle.

• A configuração dos modos de console em um identificador para aceitar o suporte à Sequência de Terminais Virtuais será manipulada com GetConsoleMode e SetConsoleMode.

• A declaração de página de código ou suporte a UTF-8 é realizada com os métodos SetConsoleOutputCP e SetConsoleCP .

• Algum nível de gerenciamento geral de processos pode ser necessário com o AllocConsole, AttachConsole e FreeConsole para ingressar ou sair de uma sessão de dispositivo de console.

• Os sinais e a manipulação de sinal continuarão a ser realizados com SetConsoleCtrlHandler, HandlerRoutine e GenerateConsoleCtrlEvent.

• A comunicação com os identificadores de dispositivo de console pode ser realizada com WriteConsole e ReadConsole. Eles também podem ser aproveitados por meio dos runtimes de linguagem de programação nas formas de: - C Runtime (CRT): E/S do fluxo como printf, scanf, putc, getc ou outros níveis de funções de E/S. - Biblioteca Padrão C++ (STL): iostream como cout e cin. - Runtime do .NET: System.Console como Console.WriteLine.

• Aplicativos que devem estar cientes das alterações de tamanho da janela ainda precisarão usar ReadConsoleInput para recebê-los intercalados com eventos-chave, pois Somente ReadConsole as descartará.

• A localização do tamanho da janela ainda deve ser executada com GetConsoleScreenBufferInfo para aplicativos que tentam desenhar colunas, grades ou preencher a exibição. O tamanho da janela e do buffer corresponderá em uma sessão de pseudoconsola.

Planejamento para o futuro e pseudoconsole

Não há planos para remover as APIs do console do Windows da plataforma.

Pelo contrário, o host do Console do Windows forneceu a tecnologia pseudoconsole para converter chamadas de aplicativos de linha de comando existentes do Windows em sequências de terminal virtual e encaminhá-las para outro ambiente de hospedagem remotamente ou entre plataformas.

Essa tradução não é perfeita. Ele requer que a janela do host do console mantenha um ambiente simulado do que o Windows teria exibido para o usuário. Em seguida, ele projeta uma réplica desse ambiente simulado para o host pseudoconsole . Todas as chamadas à API do Console do Windows são operadas no ambiente simulado para atender às necessidades do aplicativo cliente de linha de comando herdado. Somente os efeitos são propagados para o host final.

Um aplicativo de linha de comando que deseja compatibilidade total entre plataformas e suporte total de todos os novos recursos e cenários no Windows e em outros lugares é, portanto, recomendável mover para sequências de terminal virtual e ajustar a arquitetura de aplicativos de linha de comando para se alinhar com todas as plataformas.

Mais informações sobre essa transição do Windows para aplicativos de linha de comando podem ser encontradas em nosso roteiro do ecossistema.