headers
Stephan T. Lavavej | 7 Apr 2003 20:16
Picon
Favicon

ANSI Colors in MinGW

Hi,

What I would like to do is create a Win32 console mode application that
prints colored text to the console.  In DJGPP, I could access some functions
that would allow me to print with 16 or so colors.  Unfortunately, DJGPP
does not create Win32 applications like MinGW does.  Yet I can't find out
(after extensive Googling) how to print colored text to the console in
MinGW.

If at all possible I would like the resulting executables to be standalone;
i.e. they can be run on another system by themselves and still work.  (This
is the case for normal MinGW executables.)

This thread:
http://www.geocrawler.com/mail/msg.php3?msg_id=9136852&list=18160
mentions that you have to link executables against msys-1.0.dll instead of
MSVCRT.  I can't figure out how to do this with MinGW alone, much less
statically.  I tried installing MSYS and compiling the given application
under MSYS; when I ran objdump on it, it was still linked against MSVCRT.
The executable would print colors under MSYS but not under cmd.exe.

I'd appreciate any light that anyone can shed on this manner.

Stephan T. Lavavej

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Dunstan | 8 Apr 2003 04:05
Picon
Favicon

Re: ANSI Colors in MinGW


>From: "Stephan T. Lavavej" <stl@...>
>Reply-To: <stl@...>
>To: <mingw-msys@...>
>Subject: [Mingw-msys] ANSI Colors in MinGW
>Date: Mon, 7 Apr 2003 11:16:37 -0700
>
>Hi,
>
>What I would like to do is create a Win32 console mode application that
>prints colored text to the console.  In DJGPP, I could access some 
>functions
>that would allow me to print with 16 or so colors.  Unfortunately, DJGPP
>does not create Win32 applications like MinGW does.  Yet I can't find out
>(after extensive Googling) how to print colored text to the console in
>MinGW.
>
>If at all possible I would like the resulting executables to be standalone;
>i.e. they can be run on another system by themselves and still work.  (This
>is the case for normal MinGW executables.)

There are a few possibilities depending on where your program needs to run.

1. If you use Win32 API console functions it will only work in a DOS box, 
and of course only on Windows. For example, a function that sounds like what 
you want but I haven't tried is: SetConsoleTextAttribute

2. If your program only needs to run under rxvt (MSYS or other) then you can 
use hardcoded xterm strings like the message you refer to.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andre Steenveld | 9 Apr 2003 10:38
Picon
Picon

.../MSYS/1.0/msys.bat

Hi,

This is about .../MSYS/1.0/msys.bat from 1.0.9-2003.03.07-1, line 125
The line reads 'rem    Thanks to Nicolas Weber <nicolasweber@...>.

On WIN98 command.com does not like the fish hooks ('<' and '>'), not even in a 'rem' statement.
It looks like windows is trying to redirect the comment which fails.

Kind regards,

Andre Steenveld.

     /"\
     \ /  ASCII RIBBON CAMPAIGN
      X     AGAINST HTML MAIL
     / \

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Carl Hetherington | 9 Apr 2003 15:04

Text conversions on binary files written to shared directories

Hi,

I'm experiencing some strange behaviour with a new install of MSYS-1.0.8,
as I did with previous versions.  I'm using Windows XP.

Copying files around my local hard disc filesystem with cp works fine.
However copying a file from the hard disc to a network share, using
something like

cp file //server/file

results in the copy of `file' on `server' having its 0x0a characters
translated to 0x0d0a (the Unix line endings -> DOS line endings
transform).  This happens with both text and binary files.  It does not
happen if I use the standard DOS `copy' command.

Copying the file back from the server to the hard disc

cp //server/file file

results in the line endings transform being reversed, so the file ends up
as it was.

I also notice similar behaviour with tools such as `tar'; things like

tar -c adir > //server/foo.tar

leave //server/foo.tar similarly corrupted.

Is it something I'm doing wrong, or a bug?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Earnie Boyd | 9 Apr 2003 20:52
Picon
Favicon

Re: Text conversions on binary files written to shared directories

This would be a bug if you're using the MSYS version of cp?  Confirm 
with the output of ``type -a cp''?  In the meantime, I'll give it a go here.

Earnie.

Carl Hetherington wrote:
> Hi,
> 
> I'm experiencing some strange behaviour with a new install of MSYS-1.0.8,
> as I did with previous versions.  I'm using Windows XP.
> 
> Copying files around my local hard disc filesystem with cp works fine.
> However copying a file from the hard disc to a network share, using
> something like
> 
> cp file //server/file
> 
> results in the copy of `file' on `server' having its 0x0a characters
> translated to 0x0d0a (the Unix line endings -> DOS line endings
> transform).  This happens with both text and binary files.  It does not
> happen if I use the standard DOS `copy' command.
> 
> Copying the file back from the server to the hard disc
> 
> cp //server/file file
> 
> results in the line endings transform being reversed, so the file ends up
> as it was.
> 
> I also notice similar behaviour with tools such as `tar'; things like
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl Hetherington | 10 Apr 2003 12:59

Re: Text conversions on binary files written to shared directories

Hi Earnie,

Thanks for getting back to me.

On Wed, 9 Apr 2003, Earnie Boyd wrote:
> This would be a bug if you're using the MSYS version of cp?  Confirm
> with the output of ``type -a cp''?  In the meantime, I'll give it a go here.

$ type -a cp
cp is /bin/cp

Let me know if there's anything else I can do.

Cheers
Carl

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 0 comments |
headers
ironhead | 10 Apr 2003 15:46
Favicon

MSYS rxvt and ftp

I've got to say, MinGW has come a LONG way from the last time I played
around with it, kudos to all involved!

I love MSYS to!  It beats Cygwin hands down!

A couple of things I've noticed though, and forgive me if they have been
corrected in the 1.0.9 snapshot, as I'm using 1.0.8 at the moment, are:

- rxvt.exe: it does not seem to accept keyboard input if I resize the
window with the mouse to almost maximum size.  One thing I noticed is
that if I set '-sl 2500' or some other large value, I can drag the
bottom border to the bottom of the screen and it works fine.  However,
if I then drag the right border to the right edge of the screen, the
keyboard input ceases to work.  Could this be related to a text buffer
that is being exceeded?

- ftp.exe: it always pops up in a new command box.  I'm not sure if this
done by design, but it is a little annoying at times ;)

I'm running Windows XP SP1, MSYS 1.0.8 and MinGW 2.0.0-3 with all the
updates.

Cheers!

Chris

---
ironhead@...
http://bb4win.org
(Continue reading)

Permalink | Reply | 5 comments |
headers
Luke Dunstan | 11 Apr 2003 03:03
Picon
Favicon

Re: Text conversions on binary files written to shared directories


>From: Carl Hetherington <lists@...>
>To: mingw-msys@...
>Subject: [Mingw-msys] Text conversions on binary files written to shared 
>directories
>Date: Wed, 9 Apr 2003 14:04:31 +0100 (GMT Daylight Time)
>
>Hi,
>
>I'm experiencing some strange behaviour with a new install of MSYS-1.0.8,
>as I did with previous versions.  I'm using Windows XP.
>
>Copying files around my local hard disc filesystem with cp works fine.
>However copying a file from the hard disc to a network share, using
>something like
>
>cp file //server/file
>
>results in the copy of `file' on `server' having its 0x0a characters
>translated to 0x0d0a (the Unix line endings -> DOS line endings
>transform).  This happens with both text and binary files.  It does not
>happen if I use the standard DOS `copy' command.
>
>Copying the file back from the server to the hard disc
>
>cp //server/file file
>
>results in the line endings transform being reversed, so the file ends up
>as it was.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andriy Podanenko | 14 Apr 2003 08:10

Re: MSYS rxvt and ftp

> I've got to say, MinGW has come a LONG way from the last time I played
> around with it, kudos to all involved!

> I love MSYS to!  It beats Cygwin hands down!

> A couple of things I've noticed though, and forgive me if they have been
> corrected in the 1.0.9 snapshot, as I'm using 1.0.8 at the moment, are:

> - rxvt.exe: it does not seem to accept keyboard input if I resize the
> window with the mouse to almost maximum size.  One thing I noticed is
> that if I set '-sl 2500' or some other large value, I can drag the
> bottom border to the bottom of the screen and it works fine.  However,
> if I then drag the right border to the right edge of the screen, the
> keyboard input ceases to work.  Could this be related to a text buffer
> that is being exceeded?

> - ftp.exe: it always pops up in a new command box.  I'm not sure if this
> done by design, but it is a little annoying at times ;)
because you are using MS ftp client 8) try mingw port of this client

> I'm running Windows XP SP1, MSYS 1.0.8 and MinGW 2.0.0-3 with all the
> updates.

> Cheers!

> Chris

> ---
> ironhead@...
> http://bb4win.org
(Continue reading)

Permalink | Reply | 4 comments |
headers
Earnie Boyd | 14 Apr 2003 22:18
Picon
Favicon

Snapshot: MSYS-1.0.9-2003.04.14-1.exe

File: http://prdownloads.sf.net/mingw/MSYS-1.0.9-2003.04.14-1.exe

The following changes were crafted for this release:

* Work around an odd malloc routine bug which was causing stackdump of 
sh.exe.
* Change test for bin directory to bin\nul in msys.bat.
* Remove a resource leak from the path conversion routine.
* Correct an anomily with exectuable binaries that are dependent on 
msys-1.0.dll.
* Add -backspacekey switch to rxvt startup in msys.bat.
* Try to correct the rxvt resize freeze problem.
* Reset mount points on change to /etc directory.
* Calculate a HASH value based on the name of the DLL to differentiate 
different msys dll binaries.
* Add /bin/xargs.exe.
* Add /bin/which.

NOTE: The rxvt.exe was reverted to the previous version.  Additional 
changes were made to hopefully correct the rxvt freeze on resize problem.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 12 comments |

Gmane