terminal
terminal copied to clipboard
microsoft
Unknown input AND output regression between v1/v2 conhost
Description of the new feature/enhancement
Please add a button or menu entry that people can open the old CMD window settings. Sometimes there are situations where you need to change them. For example to enable legacy conhost behavior.
Proposed technical implementation details (optional)
So, here's an interesting question - why would you like access to the v1 console host/? We've got a mind to deprecate that entirely.
I'd honestly think it weird to have a quick shortcut to the conhost propsheet inside the Terminal itself. They're two different apps, they should have separate settings IMO.
So, here's an interesting question - why would you like access to the v1 console host/? We've got a mind to deprecate that entirely.
I'd honestly think it weird to have a quick shortcut to the conhost propsheet inside the Terminal itself. They're two different apps, they should have separate settings IMO.
In case I have an old app that requires the "Use legacy console" setting to be enabled for cmd. (Or make the setting no sense when using WT?)
Okay, given that we are actively working on removing the legacy console, can you please let us know what application that is and how it breaks with the built-in non-legacy Windows Console Host?
Okay, given that we are actively working on removing the legacy console, can you please let us know what application that is and how it breaks with the built-in non-legacy Windows Console Host?
@DHowett I will ask my colleague if we can share some information with you tomorrow.
Would it be possible to send you a PM/Mail with further information if required?
Okay, given that we are actively working on removing the legacy console, can you please let us know what application that is and how it breaks with the built-in non-legacy Windows Console Host?
@DHowett Unfortunately I don't have much information. But I will share the one I have with you. Maybe it helps. (And by the way the problematic application will replaced in summer 2024.)
What I know is that it is an old self made IBM38 application which was ported using CICS runtime to run on Windows/DOS. My colleague told me that when our users start the app without "Legacy console mode" then they can not jump using the tab key between the fields and the mouse isn't working too. (We don't have WT installed for our users. So they definitely use the conhost)
Additional test I made: I tried to use Windows Terminal but the rendering isn't working there. Even with having Atlas Engine enabled.
In WT:
In Conhost:
This looks like the app might be using NUL characters in place of spaces. If so, that could be a case of the app needing to be run with VT mode disabled (#4954/#6973), or possibly NUL characters are being written directly to the buffer, which won't be passed on by conpty (#4363/#6265).
However, neither case explains why the legacy console option is needed. What does the app look like in Conhost without the "Use legacy console" checked. Is it the same appearance as Windows Terminal? If so, is it possible that your system has the HKEY_CURRENT_USER\Console\VirtualTerminalLevel registry entry set to 1?
@j4james There are two different problems: The output problem in WT and the input problem in Conhost (and maybe WT).
- In conhost with and without "legacy console" enabled it looks correct. Only in WT the output/layout is broken.
- We need the "legacy console" mode only to work around the input (tab key and mouse) problems described in my last comment.
- I only want to tried the app in WT to check if we have the input problems there too. But I failed because of the output/layout problem.
Is there any chance you could link us to this application to debug it/? I'd rather us figure out why this isn't working (even in conhost v2), rather than offer a bail-out to something we're actively trying to deprecate 😄
Is there any chance you could link us to this application to debug it?
Unfortunately not. It is a self development of our company. And the only person who knows about the code, can make changes and can provide more details is out of office since a long time. And we can't send you a copy of the application.
Some context: The runtime is providing IBM 3270 series terminal emulation (screen, keyboard, data channels, etc.) for Customer Information Control System (CICS) purposes. I wonder if use of console feature ENABLE_WRAP_AT_EOL_OUTPUT might be one place to start. (Forewarning, this might be a deep rabbit hole!)
Here's example CICS Runtime 6.0.27 behavior across several configurations:
Windows Console Host
https://github.com/microsoft/terminal/assets/475132/0da9d759-a57a-4277-889f-3732c515e416
Legacy Windows Console Host
https://github.com/microsoft/terminal/assets/475132/cc4f7003-536a-45a2-b4f2-48aa28ae786f
Windows Terminal:
https://github.com/microsoft/terminal/assets/475132/3449b7cd-64f7-45aa-ad6a-8ac4a3bf0488
@zadjii-msft Is there anything else I can provide to help with your conhost deprecation efforts? (I presume you need to know which console APIs the runtime is using here, etc.)
As it currently stands, this entire class of apps will fail to function if conhost v1 goes away. There's no indication the vendor is working on an update.
conhost deprecation efforts
FWIW, we are not deprecating all of conhost. We're deprecating only the v1/legacy console (which was forked after Windows 8.1 and frozen in time.)
At this point, a live repro would be the best... but I understand that probably CICS Runtime requires a bunch of setup that isn't available to us. Hmm.
@DHowett Didn't you have some kind of debug feature that could be used to log console API calls? That might be helpful here, because I'm curious to see what input APIs they are using that might be the cause of the tab key and mouse operations failing.
As far as the output corruption is concerned, I'm pretty certain that's just one of the NUL character issues I mentioned above. I can reproduce the exact same failed rendering of the CICS banner by writing NUL characters to most of the unused areas of the display.
I can get that information for you outside any logging facility that may exist. Sounds like that coupled with some test cases will be needed to move forward here so I can work on that.
vtm can log Win32 Console API calls (with Log switch enabled). Perhaps it will be useful in this case.
What we currently support are TraceLogging events of the Microsoft.Windows.Console.Host provider, aka fe1ff234-1f09-50a8-d38d-c44fab43e818. It contains an output similar to vtm:
We have instructions to record a trace here: https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#capturing-a-debug-etl-trace @riverar If it's not too much to ask, would it be possible to try and record a trace with our .wprp profile? If you need any help, let me know, but given mach2 I suspect that this will be unlikely. 😅
@j4james You're thinking of https://github.com/microsoft/terminal/tree/dev/duhowett/hax/conhost_dump_replay And yeah that would allow us to capture a complete, reproducible dump of the console calls. But it's currently not in any prebuilt binary. We could consider making one to debug this though.
Unfortunately, conhost_dump_replay doesn't capture generated input nor does it work for the legacy console; however, I can imagine introducing a version of it that acts as an interposer between the client and the server rather than as its own server. Hmm.
Oh, it might be best to use the DefTerm profile if you do go the WPR route. It's not documented on that page, but if you swap !Terminal.Verbose for !DefTerm.Verbose it will enable more tracing providers.
Unfortunately, conhost_dump_replay doesn't capture generated input nor does it work for the legacy console;
I don't think that's necessarily a problem. Even running in the new conhost, we should be able to get a general idea of what the app is doing: what input modes are set; what read APIs are called. And from that we could potentially produce our own test app that does the same sort of thing, and see how it performs in v1 conhost compared to v2 conhost.
@j4james Oh! You're totally right!
Alright, very few folks have actually run through this scenario end-to-end, so... it might break.
OpenConsole-Dump-Replay-20240221.tar.gz
- Run
OpenConsole cmd - Do your repro scenario
exitor otherwise close the new console- Notice the
conhost_log.binthat has been written in the CWD - (Optionally,) run
OpenConsole conhost_log.binto watch it play back - Send us
conhost_log.binin whatever way you feel safest.
And another with more complex menu navigation and even an unhandled exception (not console's fault) during a print operation. conhost_log.zip
Note this OpenConsole doesn't reproduce the formatting issues above. Suspect that's expected and we're just using this OpenConsole build for tracing. But do correct me if I'm wrong here.
@riverar Thanks for the logs. I had a chance to look at them this weekend, and I think I've figured out at least part of the what is going wrong.
- For the output, the app appears to be using the
WriteConsoleOutputCharacterAPI with strings containingNULcharacters, and that's the reason why the layout breaks on Windows Terminal. This is a known issue that we need to address. - For the mouse input, it looks like the input mode is switching between
1E7and1F7, which means it's toggling theENABLE_MOUSE_INPUTmode, but that in itself is not enough to make mouse events work - you also need to disableENABLE_QUICK_EDIT_MODE. I'm guessing that maybe the v1 console has that disabled by default, and the v2 console has it enabled, but you should still be able to disable it manually from the console settings menu if you can't change the code (you'll need to restart the console though). - For the keyboard input, it appears to be using the
PeekConsoleInputandReadConsoleInputAPIs to read key events, but I can't see any reason why those would behave differently in the v2 console compared to the v1 console. I could definitely read a Tab key event easily enough in my tests, so I'm not sure what's going wrong there.
- For the keyboard input, it appears to be using the
PeekConsoleInputandReadConsoleInputAPIs to read key events, but I can't see any reason why those would behave differently in the v2 console compared to the v1 console. I could definitely read a Tab key event easily enough in my tests, so I'm not sure what's going wrong there.
the "new" one doesnt supply virtual key code on key pressed down, only on key pressed up.
the "new" conhost im reffering has 10.0.18362.1 file version, living in my virtualbox world (never would have i rise above 7th win)
so the problem here is a simple lack of testing. testing tool that would fit is the showkey-like program that prints received input.
here, i supply some screens
{} means character only, [] has virtual key code
I've been using this to test ReadConsoleInput: https://gist.github.com/lhecker/43e562d5a1370d2582bb5d6eed4e4f3e
If I run that in a build 18362 conhost, I never get INPUT_RECORDs without virtual key code on key down. I tried it with the A API instead of W and it didn't happen either, nor when I tried the 0x1E7 mode mentioned above. I'm sure I must be doing something wrong, but it's unclear to me what that should be.
Is there any specific keys that you press that reproduce the issue? Otherwise I'd also of course be happy to test some PHP code if you have anything that would reproduce such an issue. 🙂
mm, ooke, that's the ReadConsoleInputW version i use.. it's the ENABLE_VIRTUAL_TERMINAL_INPUT flag that goes to SetConsoleMode and brings that behavior, not sure why i enabled it for (probably because it says "conjunction" word in the docs). its not really php, php calls windows api through FFI extension, cant supply it not operating properly for now. so maybe not the case, as the old app wont touch it.