2

Applies to:

  • Visual Studio Community Edition 2015 (C++)
  • Windows 10

Visual Studio has two ways to run a C++ program for Win32 Console: "Start Without Debugging (Ctrl+F5)" and "Start Debugging (F5)". Both will launch a separate console window for the program. If the program sends ANSI escape codes via cout, the first window works as expected, but the second will show the codes as characters, with unprintable codes such as ESC replaced by a question mark in a box.

Why is it different? Is there a way to get the ANSI escape codes to behave normally while debugging?

Sean Gugler
  • 779
  • 8
  • 18
  • It is not obvious why it works at all, ansi.sys is ancient history. Describe your runtime environment bettter. – Hans Passant Mar 24 '16 at 22:56
  • This is a stock installation of both Windows 10 Pro and Visual Studio. The code I am examining uses "\033[2J\033[1;1H" to clear the screen, where \033 is octal for ESC. I cannot explain why it works with the F5 method; I notice it also does not work when I run the .exe outside Visual Studio. – Sean Gugler Mar 24 '16 at 23:38
  • Yeah, you need to forget about this. – Hans Passant Mar 24 '16 at 23:55
  • 1
    Forget about what? I didn't write this code, and when discouraging the author from using ANSI codes I would prefer to explain WHY it is behaving inconsistently rather than just point out that it does. And maybe learn something myself if there is actually some way to have them keep working. – Sean Gugler Mar 25 '16 at 00:44

1 Answers1

2

The 2015 documentation does not say that there is a restriction (earlir versions required the paid version).

With Visual Studio, you can use the debugger to attach to a running process, which would avoid the problem — provided that your program can initialize and wait for you to do this.

As for why it is different, that is probably because the debugger is intercepting the input/output of the program running in the console window (and preventing it from changing the I/O modes).

Further reading:

From followup comments, @Sean-Gugler realized that

  • the executable's ANSI codes were not interpreted when it is run natively (e.g., opening from the File Explorer),
  • but worked when run normally from Visual Studio.

On being reminded that Windows 10 console window interprets ANSI escape sequences,

  • he verified that the executable ran as expected in a console window, and
  • surmised that Visual Studio was running the executable directly (without a console window) when debugging (F5), but did run it in a console window when running the executable normally (ctrlF5).

One of the problems in starting a console application from a GUI (such as Visual Studio) is that the application would have to do some extra work to allocate a console.

Further reading:

Community
  • 1
  • 1
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • Upon further investigation, I find the ANSI codes are not interpreted when the .exe is run natively either, only when run-without-debugger from within Visual Studio. Very curious. – Sean Gugler Mar 25 '16 at 00:47
  • Reportedly Windows 10 console window interprets ANSI sequences. – Thomas Dickey Mar 25 '16 at 00:48
  • That helps! I now see that if I run the .exe from a "CMD" console I get ANSI interpretation, but if I double-click the .exe I do not. So I bet Visual Studio launches directly with F5, but runs a CMD shell for Ctrl+F5. – Sean Gugler Mar 25 '16 at 00:52
  • sounds good (a user mentioned this to me, and it's on my to-do list to document properly in [ncurses](http://invisible-island.net/ncurses/ncurses.html#download_database)). – Thomas Dickey Mar 25 '16 at 00:54
  • If you want to write/edit an answer to include these findings, I'll accept yours for credit, otherwise I'll just rudely answer my own question. – Sean Gugler Mar 25 '16 at 21:20