How to host modern console application on legacy serial COM device in Windows

Question

EDIT: Changed primary example from Zork Dungeon to the default OS shell.

I have a console application running on a modern machine. I also have an Apple //e with a Super Serial Card, which allows it to function as a dumb terminal via a serial COM connection (details are useless beyond that). I can connect these two devices just fine using a USB Serial port.

When the modern machine has Linux booted, by configuring COM settings and giving myself rights to the group the device file belongs to, I can run

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

and get a bash session on the Apple - the Linux machine acts as server and runs the program, but input and output go to the Apple, which is a simple client. This also works with more dedicated programs, such as dungeon (Zork).

How do I do the same thing in Windows? Obviously, I cannot replicate the above solution exactly since Windows only lets me have a COM port open in one place at a time - running the Windows analogue of the above command,

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

gives me an Access Denied error.

I can send data to the COM port:

C:\> echo "Hello" >COM4

and read raw input (including control and escape characters!) from the COM port:

C:\> type <COM4

but I cannot do both at the same time, in the same or separate processes.

I tried using PuTTY and RealTerm, but both of those only let me operate the Apple from the Windows machine, which proves the connection works but is exactly the opposite direction of what I want. How do I host a Windows console application for access from a connected terminal?

Answer 1

Edit: "Re-answered" after question clarification

According to Microsoft (I can't find Using command redirection operators section for Windows newer than 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.

So good news is:

• You can change <COM4 >COM4 2>COM4 to <COM4 >&1 2>&1.

Bad news is:

• You are mixing read-only <COM4 and write-only >&1 2>&1 handle access requirements and you are changing Access Denied to The handle could not be duplicated during redirection of handle 1.

If you change:

• <COM4 >&1 2>&1 to >COM4 2>&1 <&1 (read-only and write-only are still mixed) which works and give you usable STDOUT and STDERR, but STDIN still seems* to be broken. (*)I have done few tests, but it seems that STDIN don't work...

However I can see one workaround to fix it:

• Use com0com null-modem emulator and define 3 virtual port pairs:
  • COM_O - COM_O4 for STDOUT;
  • COM_E - COM_E4 for STDERR;
  • COM_I - COM_I4 for STDIN.

• Make a serial hub with hub4com.exe (com0com part) from COM_O4, COM_E4, COM_I4 and 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
  • Remember to setup proper (you own) transmission parameters: --baud...

• And <\\.\COM_I >\\.\COM_O 2>\\.\COM_E form command-line.

---

Finally, for:

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

and:

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

you have a Windows command-line on COM4 on 19200 8N1...