QEMU -noconsole prints ANSI escape codes

[rayzchen]

Windows Terminal version

1.13.10395.0

Windows build number

10.0.19042.1526

Other Software

QEMU emulator version 6.2.0 (v6.2.0-11889-g5b72bf03f5-dirty)

Steps to reproduce

qemu-system-x86_64 -nographic

Expected Behavior

something similar to the output of this window:

Actual Behavior

←c←[?7l←[2J←[0mSeaBIOS (version rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org)


iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+07F915B0+07EF15B0 CA00



Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
Boot failed: could not read the boot disk

Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0003)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok

ANSI codes don't seem to render properly, for example ←[0;1miPXE which should be iPXE in bold.

[zadjii-msft]

Looks like QEMU isn't enabling ENABLE_VIRTUAL_TERMINAL_PROCESSING with SetConsoleMode. If they want to use VT sequences, they'll need to set that flag. If this worked before, then it must be a recent regression in QEMU...

unless... how are you launching QEMU? Via a Terminal profile, or just by running the exe directly (from like the start menu or run dialog)? Do and I remember there being talk that Terminal should enable that flag by default for applications is spawns, but I don't kn

Nevermind. I thought this might be a defterm bug but you're on Windows 10 so it can't be that. I bet this is a regression in QEMU, we haven't changed this in years.

[rayzchen]

is there a way to force QEMU to enable that flag?

[zadjii-msft]

See, that's the interesting part. If you're running QEMU in the Windows Terminal, then ENABLE_VIRTUAL_TERMINAL_PROCESSING should be set by default. Only way the above would happen is if they actually disabled that mode explicitly. I'd reckin this is a bug that needs to go to their issue tracker.

Can you post a screenshot of the Terminal with the (broken) QEMU output?

idly: I wonder if they ship like, mintty with QEMU to use that as their console window.

There might be a reg key to force VT on by default, I forget off the top of my head, and I don't think it works in the Terminal (because again, the Terminal should enable that flag itself by default)

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[hello-smile6]

reg key to force VT on by default

Is this it?
https://www.dostips.com/forum/viewtopic.php?t=9144

[zadjii-msft]

Yep that's the one I was thinking of.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[hello-smile6]

It seems reproducible with the latest npm in conhost.

[eryksun]

Only way the above would happen is if they actually disabled that mode explicitly.

I'm sure lots of programs set a hard-coded value. After all, it's not as if the console API ever changes. ;-) It would have been good to protect it with something like ENABLE_EXTENDED_FLAGS (0x0080) that's required in order to set and unset the VT modes.

[hello-smile6]

Could qemu be detected based on its hash or something? If so, maybe you could ignore its configuration.

[rayzchen]

Can you post a screenshot of the Terminal with the (broken) QEMU output?

Sorry for the absurdly late reply...

[hello-smile6]

Can you post a screenshot of the Terminal with the (broken) QEMU output?

Sorry for the absurdly late reply...

I was hoping the issue wouldn't be automatically closed, so I kept commenting.

[YO4]

I found how to reproduce.

cmd.exe on Windows Terminal, chcp 437 and run msys's bash.exe. Then run qemu and it will reproduce.

chcp 1252, chcp 932 or without msys bash, qemu works fine on Windows Terminal.

note: msys uses /c/ProgramData path notation.

[zadjii-msft]

Huh, kinda surprised we never came back to this. The involvement with msys here makes me think this is a variation on #6634. @DHowett back me up?

[DHowett]

Agreed, this looks like a /dupe of #6634, and it's something that the upstream application is going to need to handle better.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!