Turning off the cursor in WSL?

[vefatica]

Microsoft Windows 10 Pro for Workstations
10.0.19044.1889 (2009, 21H2)
WindowsTerminalPreview 1.15.2208.16002

Below is a little program. Run it in any Windows shell (console or WT) and the cursor is OFF during the Sleep(). Run it in any WSL/Ubuntu shell (console or WT) and the cursor is ON during the Sleep(). Note also that in the WSL case, the cursor is at EOL. What's going on? Thanks!

#include <Windows.h>

BOOL Emit (HANDLE h, LPWSTR sz)
{
	return WriteConsoleW(h, sz, lstrlen(sz), nullptr, nullptr);
}

INT wmain (INT argc, WCHAR **argv)
{
	HANDLE hCONOUT = CreateFileW(L"CONOUT$", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);

	// cursor off; up 1 line; to column 1; erase to EOL
	Emit(hCONOUT, L"\x001b[?25l" L"\x001b[1A" L"\x001b[1G" L"\x001b[K");

	Sleep(5000);

	// cursor on;
	Emit(hCONOUT, L"\x001b[?25h");

	return 0;
}

[vefatica]

And, as far as I can tell, ReadConsoleOutputW and WriteConsoleOutputW work when my EXE is run by any Windows shell running in a console or WT and don't work when my EXE is run by bash in WSL.

Am I expecting too much?

[zadjii-msft]

You'll have to give more details beyond just it "doesn't work". How doesn't it work? Does it fail entirely? Does it return something unexpected?

When running in WSL, win32 console applications are stealthily running in a ConPTY session separate from the linux PTY. If you're trying to ReadConsoleOutput the contents of the buffer that were emitted by linux tools, then yea, that's not gonna work.

[vefatica]

If you're trying to ReadConsoleOutput the contents of the buffer that were emitted by linux tools, then yea, that's not gonna work.

Why not? Doesn't the ConPty that my app is talking to know what's in the ConPty (or whatever it is) that I'm looking at?

It's a ruler app. It presents a ruler (....+....1....+....2...) on the line whete the command was issued. Up/Down move the ruler, saving/restoring any text that it overwrote (in the WSL case, probably out there by Linux). Any other key terminates the app, placing the cursor so that a new prompt replaces the original command line. It works perfectly with any Windows shell, even in SSH. [If it were built-into WT I'd have it everywhere. :-)]

Actually, writing the ruler works better if I move the cursor (with a VT sequence) though WriteConsoleOutputW has, on the surface, nothing to do with the cursor position.

Should I just give up on making it work in WSL?

[DHowett]

This one is a bit complicated. There's actually two consoles involved -- the outer console (maybe conpty) hosting WSL and the inner console (definitely conpty) hosting the Windows application from inside WSL. The inner one doesn't know what the outer one has on the screen. This is partly because what outer WSL put on the screen may not even be representable to the inner Win32 console application.

I drew a diagram for a different issue, but I'll transclude it here.

Yes! Somebody finally reported it! 😁

This is an unfortunate consequence of WSL using ConPTY for interop with windows binaries and passing the PSEUDOCONSOLE_INHERIT_CURSOR flag.

What you end up with is two console hosts:

the one on the right owns drawing the history for CMD. Since it's acting like the buffer starts halfway down the screen (a point that changes with every line drawn), it will only redraw that region as it's the only region it has a backing buffer for.

[vefatica]

Hmmm! I sort of understand. And that (sort of) explains why moving the cursor above the command line allows WriteConsoleOutput to write there (writing the ruler below the command line was not a problem). Of course, above the command line is where a ruler is most useful. But I don't understand why ReadConsoleOutput doesn't work anywhere when I'm running in WSL. I just get lines of NULs.

In any event, I have given up. "Transclude" ... nice word!

[DHowett]

I just get lines of NULs.

That's this part:

The inner one doesn't know what the outer one has on the screen. This is partly because what outer WSL put on the screen may not even be representable to the inner Win32 console application.

When you're running under "WSL Interop", you are in an isolated console that literally contains nothing except your application.

[DHowett]

Transclude

Thanks! I think I learned it from Mediawiki? or AngularJS? It's been a while.

giving up

This part of the console subsystem isn't great. Sorry about that. :(