Como hospedar o aplicativo de console moderno no dispositivo COM serial legado no Windows

Question

EDIT: Exemplo primário alterado do Zork Dungeon para o shell do sistema operacional padrão.

Eu tenho um aplicativo de console em execução em uma máquina moderna. Eu também tenho um Apple // e com um Super Serial Card, que permite que ele funcione como um terminal burro através de uma conexão COM serial (detalhes são inúteis além disso). Eu posso conectar esses dois dispositivos muito bem usando uma porta USB Serial.

Quando a máquina moderna tem o Linux inicializado, configurando configurações de COM e dando a mim mesmo direitos ao grupo ao qual o arquivo do dispositivo pertence, eu posso rodar

$ bash </dev/ttyUSB1 >/dev/ttyUSB1 2>/dev/ttyUSB1

e obtenha uma sessão bash no Apple - a máquina Linux atua como servidor e executa o programa, mas a entrada e a saída vão para a Apple, que é um cliente simples. Isso também funciona com programas mais dedicados, como dungeon (Zork).

Como faço a mesma coisa no Windows? Obviamente, não posso replicar a solução acima exatamente porque o Windows só me permite ter uma COM port aberta em um lugar por vez - executando o análogo do Windows do comando acima,

C:\> cmd <COM4 >COM4 2>COM4

me fornece um erro de acesso negado.

Eu posso enviar dados para a porta COM:

C:\> echo "Hello" >COM4

e leia entrada bruta (incluindo caracteres de controle e escape!) da porta COM:

C:\> type <COM4

mas não posso fazer as duas coisas ao mesmo tempo, no mesmo processo ou em processos separados.

Eu tentei usar PuTTY e RealTerm, mas ambos só me permitem operar a Apple a partir da máquina Windows, o que prova que a conexão funciona, mas é exatamente a direção oposta do que eu quero. Como faço para hospedar um aplicativo de console do Windows para acesso a partir de um terminal conectado?

    

Answer 1

Edit: "Re-answered" after question clarification

De acordo com a Microsoft (não consigo encontrar a seção Using command redirection operators do Windows mais recente do que XP):

Duplicating handles

The & redirection operator duplicates output or input from one specified handle to another specified handle. For example, to send dir output to File.txt and send the error output to File.txt, type:

dir>c:\file.txt 2>&1

When you duplicate a handle, you duplicate all characteristics of the original occurrence of the handle. For example, if a handle has write-only access, all duplicates of that handle have write-only access. You cannot duplicate a handle with read-only access into a handle with write-only access.

Então, boas notícias são:

• Você pode alterar <COM4 >COM4 2>COM4 para <COM4 >&1 2>&1 .

Más notícias são:

• Você está misturando requisitos de acesso somente de leitura <COM4 e somente >&1 2>&1 somente para gravação e está alterando Access Denied para The handle could not be duplicated during redirection of handle 1 .

Se você mudar:

• <COM4 >&1 2>&1 to >COM4 2>&1 <&1 (somente leitura e somente gravação ainda são misturadas), o que funciona e dá a você STDOUT e STDERR , mas STDIN ainda parece ser * quebrado. (*) Eu fiz alguns testes, mas parece que STDIN não funciona ...

No entanto, posso ver uma solução para corrigi-lo:

• Use o com0com null-modem emulator e defina 3 pares de portas virtuais:
  • COM_O - COM_O4 para STDOUT ;
  • COM_E - COM_E4 para STDERR ;
  • COM_I - COM_I4 para STDIN .

• Crie um hub serial com hub4com.exe ( com0com part) de COM_O4 , COM_E4 , COM_I4 e COM4 :

  • hub4com.exe --route=0:1 --route=2,3:0 --baud=19200 --data=8 --parity=no --stop=1 --octs=off --odsr=off --ox=off --ix=off --idsr=off --ito=0 \.\COM4 \.\COM_I4 \.\COM_E4 \.\COM_O4
  • Lembre-se de configurar os parâmetros de transmissão adequados (você próprio): --baud ...

• E <\.\COM_I >\.\COM_O 2>\.\COM_E forma linha de comando.

Finalmente, para:

hub4com.exe --route=0:1 --route=2,3:0 --octs=off \.\COM4 \.\COM_I4 \.\COM_E4 \.\COM_O4

e:

cmd <\.\COM_I >\.\COM_O 2>\.\COM_E

você tem uma linha de comando do Windows em COM4 on 19200 8N1 ...