HS> How many other compilers need cprintf? There's no use
 HS> Pfft. You don't even know what it does.
DM>Sure I do.  It does slightly different things on each compiler I've used
DM>it on.  For example, when using cprintf in Turbo, to replicate the same
DM>thing on Watcom, I couldn't use cprintf but the combination of sprintf
DM>and _outtext.
That's a great explanation, Darin. Petty it doesn't really explain anything. 
Now, are you SURE you know what cprintf() does?
DM>This echo is not just for those who already know C, but for those
DM>learning, too.  Your exclusion of those learning is one of the
DM>reasons
DM>that you are slowly being twitted by anyone who knows better.
 HS> Your unwarranted assumption is noted, and rejected.
 HS> Please stay ontopic or stop bothering me altogether.
DM>Stay on topic?  Coming from you?  Wow, I'm impressed.  I've been told to
DM>stay on topic by the guy who doesn't seem to know what the topic is.
DM>The topic, for your information, is _C_.  Not _Borland C_, or _Microsoft
DM>C_, or anything else.  It is _C_.  The C in the standard.  We pay
DM>particular attention to the standard in the hopes of getting everyone's
DM>compilers (even _Visual Age_, _EMX_, and _PCC_, or even non-Intel
DM>machines) giving the same results.  Use of extentions is therefore
DM>limited to times where it is absolutely necessary.
Note: Flame bait.
The current topic is cprintf, which you managed to change originally from 
ANSI-C standard, which you changed from the EVENT HANDLER program i 
previously posted. Back to our current topic, (which you seem to want to 
drift away from, again) cprintf() is only useless for DOS. Get your facts 
straight before you talk to me.
 HS> You believe? I KNOW that mainstream compilers have it
DM>Well, if you're going to be pedantic, I *know* I've seen the list, I
DM>just don't recall which compilers they were.
Oh, okay. You must be right then.
 HS> .. Watcom, Borland, Djgpp, etc. If a compiler doesn't
 HS> have it, then it most likely contains an equivalent.
DM>They don't do the same thing on all compilers.
(sigh)
cprintf() sends a formatted output STRAIGHT to the screen.
printf() sends a formatted output string to stdin.
Can you understand that?
If you can, then you would understand why the textcolor-family functions FAIL 
with printf() (ANSI-C disallows it to do anything else other than send to 
stdin). That's why all these companies put in cprintf which formats the 
string with ansi-colours. Like I said, if a compiler doesn't have cprintf() 
then it contains an equivalent which is most likely just printf().
 HS> then it would most likely contain an equivalent.
DM>Sure - but not called cprintf!  So why would you write code using
DM>cprintf when it isn't the same on all compilers being used?  Just stick
DM>to the standard code and everything is fine.
Because the mainstream compilers only allow ansi-colours with cprintf().
Mainstream = Borland, DJGPP, Watcom.
DM>Why?  What happened to printf anyway?
 HS> With cprintf, the string is written either directly to
 HS> screen memory or by way of a BIOS call, depending on
 HS> the value of directvideo.
DM>I've seen implementations that do the same thing for printf (where
DM>stdout is not redirected) in an attempt to speed up output.
Then as already mentioned, it is the equivalent of cprintf(). Although it 
shouldn't be, since the standard doesn't allow printf() to do that.
 HS> Ever wondered why textcolor(), textbackground(),
 HS> textattr().. etc don't seem to affect stdout with
 HS> printf? That's why they implemented cprintf() for
DM>They do sometimes, depending on the underlying implementation.  Watcom,
DM>I believe it was, did become affected.  Mind you, it wasn't textcolor,
DM>textbackground, textattr, but _settextcolor and _setbkcolor.  In fact, I
DM>have the following snippet that I wrote years ago to handle the
DM>differences:
They do sometimes? Gee, I wish I had compilers that decided what they did, 
when they wanted.
>** CODE **
Judging by your code, it doesn't really do much.
Try using textcolor-type functions with printf() and tell me if they work.
 HS> direct output to screen. If a compiler contains the
 HS> functions textcolor() etc, then it HAS an equivalent
 HS> for cprintf().
DM>Which is NOT cprintf!
If it doesn't, then printf() does it automatically. Which is against the 
ansi-stanard, but still useable - which goes back to my previous point that 
you DONT NEED TO FOLLOW THE STANARD ALL THE TIME.
 HS> SomeType *mytime = (SomeType *)malloc(sizeof(SomeType))
 HS> when,
 HS> SomeType *mytype = malloc(.... etc
 HS> compiles. Even though ANSI-C++ forbids void *
DM>We're not talking about C++, are we?  I thought this was the C echo.
 HS> Same concept applies to C. You did realize that, didn't you?
 HS> No. The same general concept applies - Even though it's
 HS> erroneous to the standard, it works.
DM>I love it when you start disagreeing with yourself.  And failing to cast
DM>void* to the appropriate type hasn't worked on any of my compilers for a
DM>while...
Wrong, yet again.
char *a = malloc(1243);
where malloc returns a void*. Works fine.
Please point out where i've been "disagreeing with myself".
DM>Something like that.  Now, if you'd stop using infantile logic...
 HS> Education begins at the lowest level.
DM>Come back when you've finished grade 1.
DM>
Note: Personal insult.
... If you can't make it good, make it LOOK good. -Bill Gates.
--- Ezycom V1.48g0 01fd016b
---------------