You *know* something's wrong when you find yourself envying people who 
use Unix because it can emulate an obsolete VT100... o_O

Basically, I have a perfectly working console application, but I wish I 
could just make certain parts of its output come out in a different 
colour. On Unix, this would be a fairly trivial matter of writing some 
escape codes to stdout and you're done. On Windoze... well that doesn't 
work.

I wonder... Is there some function call in the Win32 API that can 
actually change the colour of the text in a console window? Or is that 
impossible? Does anybody here know the Win32 API well enough to know the 
answer?

(Certainly the "color" command changes the colours of the console window 
- but it changes the colour of *everything*. I don't know if you can 
change just some of the text, rather than all of it...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 20 Aug 2008 15:08:37 +0200, Invisible <voi### [at] devnull> wrote:
> Basically, I have a perfectly working console application, but I wish I  
> could just make certain parts of its output come out in a different  
> colour. On Unix, this would be a fairly trivial matter of writing some  
> escape codes to stdout and you're done. On Windoze... well that doesn't  
> work.

NT-based console windows do not support colour escape codes. Only 16-bit  
applications (running under NTVDM) can use colour escapes.


> I wonder... Is there some function call in the Win32 API that can  
> actually change the colour of the text in a console window?

http://msdn.microsoft.com/en-us/library/ms682088.aspx



-- 
FE

Post a reply to this message

>> On Unix, this would be a fairly trivial matter of writing some 
>> escape codes to stdout and you're done. On Windoze... well that 
>> doesn't work.
> 
> NT-based console windows do not support colour escape codes. Only 16-bit 
> applications (running under NTVDM) can use colour escapes.

Indeed. So that isn't much help.

>> I wonder... Is there some function call in the Win32 API that can 
>> actually change the colour of the text in a console window?
> 
> http://msdn.microsoft.com/en-us/library/ms682088.aspx

Bugger. I don't have bindings for those particular functions. :-(

I wonder if I could write some...?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Fredrik Eriksson wrote:

> http://msdn.microsoft.com/en-us/library/ms682088.aspx

Oh. My. God.

I literally can't believe this... I just wrote and compiled a C program 
that calls the Win32 API directly, AND IT FRIGGIN WORKED!! 0_0

*dies*

I would never have believed it was possible... I was sure it would 
blue-screen the machine or crash spectacularly, but no, it actually 
worked properly. (AND, best of all, it IS possible to change the colour 
of just some characters in a console window. I wasn't sure it could be 
done.)

I was a little shocked to discover that I already have the necessary C 
header files. And, obviously, it took a litle while to figure out how to 
make my Haskell compiler compile raw C files instead of Haskell programs.

The hardest part was figuring out what "warning: function foo() defined 
implicitly" means. Apparently it means you spelt the function's name 
wrong, so the compiler couldn't find it in the header file. This also 
causes the linker to make rude comments.

But once you get over all of these things... my God, I made a direct OS 
call and *didn't* crash the OS. Astonishing!

I think I need to go sit down...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Oh. My. God.
> 
> I literally can't believe this... I just wrote and compiled a C program 
> that calls the Win32 API directly, AND IT FRIGGIN WORKED!! 0_0
> 
> *dies*

..and it only took you twelve minutes!
*Falls_over_in_amazement*

John
-- 
"Eppur si muove" - Galileo Galilei

Post a reply to this message

Doctor John wrote:

> ..and it only took you twelve minutes!
> *Falls_over_in_amazement*

Really? Gee, it seemed like much longer than that to me...

The hard part, of course, is writing some Haskell bindings. ;-) In 
particular, I cannot for the life of me figure out how to get at 
symbolic constant names. :-(

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 20 Aug 2008 16:20:17 +0100, Invisible wrote:

> In
> particular, I cannot for the life of me figure out how to get at
> symbolic constant names. :-(

In C?  Look at #define

Jim

Post a reply to this message

On Wed, 20 Aug 2008 17:20:17 +0200, Invisible <voi### [at] devnull> wrote:
> The hard part, of course, is writing some Haskell bindings. ;-) In  
> particular, I cannot for the life of me figure out how to get at  
> symbolic constant names. :-(

If you are looking for 'FOREGROUND_BLUE' and the like, they are defined in  
'WinCon.h'. There you will also find the structure definitions relevant to  
the console subsystem.



-- 
FE

Post a reply to this message

>> In
>> particular, I cannot for the life of me figure out how to get at
>> symbolic constant names. :-(
> 
> In C?  Look at #define

I meant how to get that stuff into Haskell.

It seems Haskell provides a magical command which somehow lets you call 
a C function as if it's a Haskell function, assuming you can find a 
header file that contains the C function you're after. (I literally have 
*no idea* how the linker finds the actual code...) However, there seems 
to be no way to import constants. In fact, every Haskell binding I've 
looked at has these hard-coded in the Haskell source code rather than 
imported, so I've just waded through a few KB of header files tracking 
down all the #defines and their literal values.

And you know what?

I just ported my program to Haskell, AND IT STILL WORKS CORRECTLY! 0_0

This is an unprecidented level of success. It seems I can actually call 
any C function I have a header file for. Wow.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Fredrik Eriksson wrote:
> NT-based console windows do not support colour escape codes. Only 16-bit 
> applications (running under NTVDM) can use colour escapes.

So this doesn't work?

http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html


-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Wed, 20 Aug 2008 17:43:05 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Fredrik Eriksson wrote:
>> NT-based console windows do not support colour escape codes. Only  
>> 16-bit applications (running under NTVDM) can use colour escapes.
>
> So this doesn't work?
>
>
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html

"the command.com shell interpreter"

"Any DOS applications you run in this command shell will now have ANSI  
support."



-- 
FE

Post a reply to this message

>>> NT-based console windows do not support colour escape codes. Only 
>>> 16-bit applications (running under NTVDM) can use colour escapes.
>>
>> So this doesn't work?
>>
>>
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html

>>
> 
> "the command.com shell interpreter"
> 
> "Any DOS applications you run in this command shell will now have ANSI 
> support."

I've tried things like this several times before, and it's never worked 
for me...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Fredrik Eriksson wrote:
> On Wed, 20 Aug 2008 17:20:17 +0200, Invisible <voi### [at] devnull> wrote:
>> The hard part, of course, is writing some Haskell bindings. ;-) In 
>> particular, I cannot for the life of me figure out how to get at 
>> symbolic constant names. :-(
> 
> If you are looking for 'FOREGROUND_BLUE' and the like, they are defined 
> in 'WinCon.h'. There you will also find the structure definitions 
> relevant to the console subsystem.

Yes. I eventually tracked those down.

Also, apparently STD_OUTPUT_HANDLE is -10, not 10. >_<

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 20 Aug 2008 17:50:46 +0200, Invisible <voi### [at] devnull> wrote:
> I've tried things like this several times before, and it's never worked  
> for me...

As I said before, only 16-bit applications can use colour escapes under NT.


-- 
FE

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:48ac3d56$1@news.povray.org...
>>>> NT-based console windows do not support colour escape codes. Only 
>>>> 16-bit applications (running under NTVDM) can use colour escapes.
>>>
>>> So this doesn't work?
>>>
>>>
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html
>>
>> "the command.com shell interpreter"
>>
>> "Any DOS applications you run in this command shell will now have ANSI 
>> support."
>
> I've tried things like this several times before, and it's never worked 
> for me...

I run ksh on my windows xp machine and I'm able to do all that with just a 
few escape sequences in my .profile

Jim

Post a reply to this message

Invisible wrote:
> I cannot for the life of me figure out how to get at 
> symbolic constant names. :-(

Technically, there's no such thing in C as such. The #define substitutes 
the actual value for the name before the "compiler proper" ever sees it.

That's why the C standard requires something like
   f(3 + 2);
to not do any additions before invoking f(5). Otherwise, people would 
hesitate to use something like
#define LAST (PREV+1)


-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Fredrik Eriksson wrote:
> On Wed, 20 Aug 2008 17:43:05 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> Fredrik Eriksson wrote:
>>> NT-based console windows do not support colour escape codes. Only 
>>> 16-bit applications (running under NTVDM) can use colour escapes.
>>
>> So this doesn't work?
>>
>>
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html

>>
> 
> "the command.com shell interpreter"
> 
> "Any DOS applications you run in this command shell will now have ANSI 
> support."

Oh. OK. So you can't invoke it from command.com and have it work?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Wed, 20 Aug 2008 18:08:05 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Oh. OK. So you can't invoke it from command.com and have it work?

Only if it is a 16-bit application. The colour escape functionality is  
provided by 'ansi.sys' which is a 16-bit driver.


-- 
FE

Post a reply to this message

Invisible wrote:

> I wonder... Is there some function call in the Win32 API that can 
> actually change the colour of the text in a console window? Or is that 
> impossible? Does anybody here know the Win32 API well enough to know the 
> answer?

Yes, there is:

#include "stdio.h"
#include "windows.h"

void main()
{
     HANDLE hCon = GetStdHandle(STD_OUTPUT_HANDLE);
     SetConsoleTextAttribute(hCon, 0x0C);
     printf("Hello in red");
     SetConsoleTextAttribute(hCon, 0x09);
     printf(" and in blue\n");
     getchar();
}

Detailed here:
http://msdn.microsoft.com/en-us/library/ms686047.aspx

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> You *know* something's wrong when you find yourself envying people who 
> use Unix because it can emulate an obsolete VT100... o_O

> Basically, I have a perfectly working console application, but I wish I 
> could just make certain parts of its output come out in a different 
> colour. On Unix, this would be a fairly trivial matter of writing some 
> escape codes to stdout and you're done.

  AFAIK, the VT100 didn't support colors. That came with later versions
of VT.

-- 
                                                          - Warp

Post a reply to this message

On Wed, 20 Aug 2008 16:42:13 +0100, Invisible wrote:

> I meant how to get that stuff into Haskell.

Oh, I see....

Jim

Post a reply to this message

Mike Raiford wrote:

> Yes, there is:
> 
> #include "stdio.h"
> #include "windows.h"
> 
> void main()
> {
>     HANDLE hCon = GetStdHandle(STD_OUTPUT_HANDLE);
>     SetConsoleTextAttribute(hCon, 0x0C);
>     printf("Hello in red");
>     SetConsoleTextAttribute(hCon, 0x09);
>     printf(" and in blue\n");
>     getchar();
> }
> 
> Detailed here:
> http://msdn.microsoft.com/en-us/library/ms686047.aspx

Yah, that works.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   AFAIK, the VT100 didn't support colors. That came with later versions
> of VT.

Rather alarmingly, you're right again...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> You *know* something's wrong when you find yourself envying people who 
> use Unix because it can emulate an obsolete VT100... o_O

Not any more! Now I have my simple console application set up so that 
the command prompt comes out in a different colour to the command 
output. You have *no idea* how much easier this makes it when scrolling 
through the programs output!

(Of course, it's still no help if you decide to pipe output to a file... 
But for that, there is HTML and other markup languages.)

I'm seriously chuffed now. :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> Not any more! Now I have my simple console application set up so that 
> the command prompt comes out in a different colour to the command 
> output. You have *no idea* how much easier this makes it when scrolling 
> through the programs output!

...and then he wastes an entire morning agonising over exactly which 
colour combinations look the nicest! o_O

The answer: They ALL look like something from the 1980s. (Or Teletext.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Not any more! Now I have my simple console application set up so that 
> the command prompt comes out in a different colour to the command 
> output. You have *no idea* how much easier this makes it when scrolling 
> through the programs output!

  Next you'll need colored file listing.

http://warp.povusers.org/snaps/ColoredListing.png

  You wouldn't believe how much easier it makes to visualize files by
type.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Next you'll need colored file listing.
> 
> http://warp.povusers.org/snaps/ColoredListing.png
> 
>   You wouldn't believe how much easier it makes to visualize files by
> type.

What, with only 16 possible colours available? ;-)

Actually, I tend to work with files through a GUI instead. And I also 
tend to not have very many of them. Distinguishing by icon is almost as 
easy as by colour.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> What, with only 16 possible colours available? ;-)

  Even 16 colors makes your life a LOT easier with file listings.

> Actually, I tend to work with files through a GUI instead. And I also 
> tend to not have very many of them. Distinguishing by icon is almost as 
> easy as by colour.

  I disagree. Icons are small and often hard to distinguish from each
other, and it's difficult to view at a glance what type of file is
being listed at a certain position. The icon is not any better than
the file extension itself. You may as well look for the file extension.
However, coloring makes it much easier to see the file types at a quick
glance, without having to focus on a specific icon or extension.

  In Windows in particular, the icon is actually worse than the file
extension. The icon does *not* represent the file type. It represents
the program which opens that file. This sometimes leads to completely
ridiculous situations where you have two files with the exact same
name (if extension have been disabled, as it's the default in Windows)
and exact same icon. If you are looking at the icon listing (rather
than the detailed listing) there's absolutely no way to visually
distinguish which file is which.

-- 
                                                          - Warp

Post a reply to this message

>> What, with only 16 possible colours available? ;-)
> 
>   Even 16 colors makes your life a LOT easier with file listings.

Well it's probably a lot better than just 1.

>> Actually, I tend to work with files through a GUI instead. And I also 
>> tend to not have very many of them. Distinguishing by icon is almost as 
>> easy as by colour.
> 
>   I disagree. Icons are small and often hard to distinguish from each
> other, and it's difficult to view at a glance what type of file is
> being listed at a certain position. The icon is not any better than
> the file extension itself. You may as well look for the file extension.
> However, coloring makes it much easier to see the file types at a quick
> glance, without having to focus on a specific icon or extension.

Depends on the icons in question. For example, I'm currently working on 
a Haskell program. All the source code files show up as a white page 
with a black lambda on them. All the other files (object files, 
interface files, etc.) show up with that default Windoze "gee, I don't 
know what the hell this file is" icon, which has a lot less white in it. 
I can visually scan down a list of files and instantly find the source 
files.

>   In Windows in particular, the icon is actually worse than the file
> extension. The icon does *not* represent the file type. It represents
> the program which opens that file.

...which means that if I had a folder full of PNG files, some of which 
had also been converted to JPEG, I'd have a problem, because they would 
all have identical icons.

OTOH, are you really telling me your system has a different colour for 
every possible filetype? It only has 16 colours available, remember.

> This sometimes leads to completely
> ridiculous situations where you have two files with the exact same
> name (if extension have been disabled, as it's the default in Windows)
> and exact same icon.

A very stupid default, IMHO. I changed that long ago.

> If you are looking at the icon listing (rather
> than the detailed listing) there's absolutely no way to visually
> distinguish which file is which.

I have mine default to details. Occasioanlly I change it to thumbnail. 
(Possibly the *only* genuinely useful feature M$ has ever come up with. 
I wonder which competitor they stole it from?)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> 
> A very stupid default, IMHO. I changed that long ago.
> 

Incredibly. I hate getting on someone's system and finding that I can't 
read the extensions. I know the rationale behind it, but in practice 
with Windows the extension is part of the file name. On other (Mac) 
systems, the file has a separate fork that has metadata about the file, 
files can't share the same name,so you don't get two files that are 
practically indistinguishable from each other.

>> If you are looking at the icon listing (rather
>> than the detailed listing) there's absolutely no way to visually
>> distinguish which file is which.
> 
> I have mine default to details. Occasioanlly I change it to thumbnail. 
> (Possibly the *only* genuinely useful feature M$ has ever come up with. 
> I wonder which competitor they stole it from?)
> 

ACDSee? ThumbsPlus?  hmmm...

Post a reply to this message

Warp wrote:
>   I disagree. Icons are small and often hard to distinguish from each
> other, and it's difficult to view at a glance what type of file is
> being listed at a certain position. The icon is not any better than
> the file extension itself. You may as well look for the file extension.
> However, coloring makes it much easier to see the file types at a quick
> glance, without having to focus on a specific icon or extension.

	Did they never make a Norton Commander that'll work with Windows 
consoles? Or a similar app?


-- 
When everything's coming your way, you're in the wrong lane


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Invisible wrote:
> Warp wrote:
> 
>>   Next you'll need colored file listing.
>>
>> http://warp.povusers.org/snaps/ColoredListing.png
>>
>>   You wouldn't believe how much easier it makes to visualize files by
>> type.
> 
> What, with only 16 possible colours available? ;-)

...and 16 different backgrounds, so a theoretical 16^2 pssible 
combinations (I am of course assuming you can change the default black 
as you can on *nixes) though not all are usable


John
-- 
"Eppur si muove" - Galileo Galilei

Post a reply to this message

Doctor John wrote:
> ....and 16 different backgrounds, so a theoretical 16^2 pssible 
> combinations

If you want to get really picky, subtract out at least 16 combinations. 
I don't think you want too many files listed as blue on blue. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message