CODEWITHSUNDEEP
c++windowscmdconsoleansi-escape
Rusty Weber
Rusty Weber

Reputation: 1582

Is there a way to make windows output ansi escape sequences

Is there a way to make windows output ansi escape sequences after internal console color changes? I know about things like ansicon that will INTERPRET ansi escape sequences output by a program being ran, but I am wondering if there is a way that windows will forward those escape sequences through stdout. For example


#include 
#include 
using namespace std;
HANDLE hCon;

enum Color { DARKBLUE = 1, DARKGREEN, DARKTEAL, DARKRED, DARKPINK, DARKYELLOW, GRAY, DARKGRAY, BLUE, GREEN, TEAL, RED, PINK, YELLOW, WHITE };

void SetColor(Color c){
        if(hCon == NULL)
                hCon = GetStdHandle(STD_OUTPUT_HANDLE);
        SetConsoleTextAttribute(hCon, c);
}

int main()
{
    std::cout "\x1b[31;1m  I should be red if printed on the console, otherwise I should have passed that ansi code to stdout.\n";
    SetColor(GREEN);
    cout "I should be green if printed on the console, but I should have passed the escape sequence to the stdout pipe..\n";
    char x;
    std::cin.get(x);
}

I want the byte level data being sent on stdout to be in ALL ansi approved text including color codes and cursor movement escaped sequences.. I'm not even sure that's possible but if any one knew... HERE would be the place to know if it's already been done. I am also open to possibilities on rolling my own and adding it to ansicon.

Upvotes: 2

Views: 1746

Answers (3)

user314104
user314104

Reputation: 1538

An approach that I've seen in the open-source KpyM Telnet/SSH Server was the use of GetConsoleScreenBufferInfo and ReadConsoleOutput.

Rather than manipulating the console I/O routines to emit terminal escape sequences, KTS creates a new console window and captures data from it through the handles it owns and the GetConsoleScreenBufferInfo (cursor information) and ReadConsoleOutput (on-screen information, including colors) functions. After capturing the data, KTS emits the appropriate terminal escape sequences to the remote end to reproduce the display.

This behavior requires no hooks beyond what's provided in the Win32 API and works well for interactive applications, but it can result in screen "tearing", especially when a large amount of output is dumped to the console and the SSH daemon isn't polling fast enough to keep up. Additionally, because this mechanism uses polling, it will consume more power, especially on mobile devices acting as a server, and on mobile clients with a naive server implementation. (An intelligent server implementation could detect that nothing has changed, reducing the data sent to a mobile client.)

If you are planning on implementing (or have already implemented) an SSH daemon for Windows, don't forget that not all applications will want this terminal emulation behavior -- only when you get a pty-req message should this terminal emulation be done. If you don't receive a pty-req message, the SSH daemon should merely relay the standard input/standard output/standard error streams.

Upvotes: 1

user314104
user314104

Reputation: 1538

While this is a bit of a kludge, you might be able to solve it through the use of Detours and emitting the appropriate ANSI escape sequences. On calls to the console API functions, you'd emit the appropriate escape sequences to the standard output stream.

(I hope someone suggests a better answer, because, while this should work, it's a horrible hack.)

Upvotes: 0

Carsten Cumbrowski
Carsten Cumbrowski

Reputation: 95

I am pretty sure that there is nothing that ships with any Windows OS since Windows 2000 that includes support for ANSI Escape sequences.

It also makes sense, if you consider the limitations of ANSI http://www.roysac.com/learn/ansisys.html, just 16 colors (that are fix), only 8 of them usable as background color etc.

Unless you need to be backwards compatible that far into the past or for nostalgic reasons (that last category would include myself actually :)), there is no reason to go with ANSI Escape Sequences.

If you look at the documentation (link), you will also learn that the old ANSI stuff isn't very intuitive and easy to use and certainly not straight forward also. The old PCBoard ANSI equivalent encoding @X00 .. @X7F (@X instead of CHR(27) "ESC" then 1 byte BackColor (Hex) and 1 byte ForeColor (Hex) was a walk in a park in comparison :)

Upvotes: 0

Related Questions