Created attachment 105504 [details] [review]
patch against cvs HEAD

Created attachment 105505 [details]
mandatory screenshot

I thought cmd.exe is a VT100 emulator just like the linux console, xterm, and the old MS-DOS prompt (and very nearly everything else since the 80's).  In that case, we should be able to send VT100 escape codes just like the existing code.

AFAIK, cmd.exe does not support VT100 escape sequences.

In the Old Good Days of command.com and the early days of cmd.exe (windows 95 and 98 I guess) you could use then. Since windows 2000, cmd.exe does not support ANSI escape sequences, no matter if you put a DRIVER=ansi.sys in you config.sys or not.

I've googled around and I can find some thingys about cmd.exe and colors:

* the color command that allows you to set a fg or bg color
* a property dialog that acts as a frontend to color
* the /A flag of cmd.exe that is said "to print ANSI characters", it's set by default, still no escape sequence

Anyway, if someone is able to make ANSI escape sequences work with cmd.exe, it's at least not enabled by default on my windows box. (see next screenshot)

Created attachment 105569 [details]
What gst-launch prints by default in a cmd.exe console

I refactored it a bit to reduce code duplication.

commit c5ee0b7c1d4cd8925b5a5307c9491d62ae2cb01b
Author: Damien Lespiau <damien.lespiau at gmail.com>
Date:   Wed Mar 18 19:07:00 2009 +0100

    info: more indentation fixes
    
    Fixes #517231.

commit d12d111fa257141ac6ae056ede0ebb6617f29f1f
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Mar 18 19:06:23 2009 +0100

    info: indentation fix

commit 3857d902c32c9e366162464caba5e02ff7981588
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Mar 18 18:57:16 2009 +0100

    info: simply some more

commit ca33a78881d5343b06c3f2e937377e352f266dc6
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Mar 18 18:45:41 2009 +0100

    info: refactor debug colors for win32 and other
    
    Refactor the debug line code to use as much code as possible for the win32 and
    other color codings.
    Update docs with new symbol.

commit 0c059ad2dedd099bcb70c39f90d9b4fb94485dab
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Mar 18 17:30:12 2009 +0100

    windows: initial commit for terminal colors

Created attachment 131126 [details] [review]
Makes the new logging threadsafe

Comment on attachment 131126 [details] [review]
Makes the new logging threadsafe

Well, another way of doing that is to make multiple calls to g_strdup_printf(), concat the strings and then print them in one call to g_printerr().

The second solution you mention (creating the string and THEN outputting it) is much cleaner imho and avoids using a lock. IIRC, that's how the regular outputter does it.... but I'm not 100% sure if that would work with the SetConsoleTextAttribute() method.

Re-opening and adjusting the title accordingly.

It could be possible to use FillConsoleOutputAttribute() to color a string that is already written to console, but that will also require us to lock it (else we may put the colors in wrong place).

Another option is to use WriteConsoleOutput() function, which takes combined character and attribute (color) data. But there is one problem with it - it won't change the cursor position. So we'll have to change it manually. Which means calling GetConsoleCursorInfo() to get current cursor position and SetConsoleCursorPosition() to change it.

It's still not thread-safe. On the other hand, if we DO use locking, this solution offers shortest locktime, because character/color buffer is prepared outside of lock, function locks only to write data into the console and move the cursor, which should be faster than writing a string and changing color attribute a few times (current solution) or writing one string and then setting console attributes a few times (the FillConsoleOutputAttribute solution).

FillConsoleOutputAttribute has an advantage of writing meaningful text data in both implementations (with or without locking), because the presence of a lock only affects the way it colorizes text (it may colorize wrong characters in concurrent mode, but at least text will be intact).

I commited the mutex patch because it does the right thing for now and nobody said that debugging in full colors to the console should be efficient. If you have a better and cheaper patch, please reopen and attach.


commit 7e0bdbf2086b5fffa439dbd876a5e57281dc7c1a
Author: LRN <lrn1986 at gmail.com>
Date:   Tue Apr 14 10:32:07 2009 +0200

    info: use mutex to do console colors on windows
    
    Use a static mutex to keep the console colors and context together when
    debugging with colors on Windows.
    Fixes #517231.