I spent way too much time today trying to get this test to run on Windows and wasn't successful, so unless someone else has the time or the deep knowledge of Win32 to make it work, I think we'll have to be satisfied with testing on Linux.

As far as I've been able to determine, the problem boils down to a core difference between Unix pty devices and Windows ConPTY. On Linux, the kernel creates "master" and "slave" pty devices as a pair, and they behave as though they're connected by a bidirectional pipe. The slave device is what keeps track of the local echo state, and although the simplest thing you would do with it is let a child process inherit it as its TTY, there's nothing stopping the parent process from also keeping a reference to it and monitoring its state.

But on Windows, there are at leastthree distinct sets of handles:

1. A pair of pipes created by the parent; the parent holds onto one end of each of these, and they play roughly the same role as a Unix "master" pty
2. A "pseudoconsole handle" which the parent passes as a parameter toCreateProcess, encapsulating the other ends of the pipes (corresponding to data read/written by the child)
3. A "console input buffer" and "console screen buffer" handle, which the child process receives as its stdio handles

Of these, 3 seems to be the only one that supportsGetConsoleMode which allows you to query the echo status. (The pipes are just streams of bytes that happen to contain terminal escape codes, and the pseudoconsole handle is an opaque reference that isn't actually usable for I/O.) But there seems to be no good way for the parent to use 1 or 2 to get a reference to 3. The child's handles are created automatically at process creation time, without the parent ever being able to see them.

see also:

https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

microsoft/terminal#262 (comment)

It might be that testing this on Windows would require a totally different approach.

@dwahler I went down a similar rabbit hole with ConPTY when creating thepty package. Even our PTYs on Windows in testing aren'treal PTYs, because ConPTY requires attaching to a command.