DM>recall you going on about some non-standard code
DM>(cprintf?) that happens
DM>to work on YOUR compilers, but not really _ALL_ current compilers.
 HS> How many other compilers need cprintf? There's no use
 HS> Pfft. You don't even know what it does.
Sure I do.  It does slightly different things on each compiler I've used it 
on.  For example, when using cprintf in Turbo, to replicate the same thing on 
Watcom, I couldn't use cprintf but the combination of sprintf and _outtext.
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 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.
Stay on topic?  Coming from you?  Wow, I'm impressed.  I've been told to stay 
on topic by the guy who doesn't seem to know what the topic is.  The topic, 
for your information, is _C_.  Not _Borland C_, or _Microsoft C_, or anything 
else.  It is _C_.  The C in the standard.  We pay particular attention to the 
standard in the hopes of getting everyone's compilers (even _Visual Age_, 
_EMX_, and _PCC_, or even non-Intel machines) giving the same results.  Use 
of extentions is therefore limited to times where it is absolutely necessary.
 HS> You believe? I KNOW that mainstream compilers have it 
Well, if you're going to be pedantic, I *know* I've seen the list, I just 
don't recall which compilers they were.
 HS> .. Watcom, Borland, Djgpp, etc. If a compiler doesn't 
 HS> have it, then it most likely contains an equivalent.
They don't do the same thing on all compilers.
 HS> then it would most likely contain an equivalent.
Sure - but not called cprintf!  So why would you write code using cprintf 
when it isn't the same on all compilers being used?  Just stick to the 
standard code and everything is fine.
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.
I've seen implementations that do the same thing for printf (where stdout is 
not redirected) in an attempt to speed up output.
 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 
They do sometimes, depending on the underlying implementation.  Watcom, I 
believe it was, did become affected.  Mind you, it wasn't textcolor, 
textbackground, textattr, but _settextcolor and _setbkcolor.  In fact, I have 
the following snippet that I wrote years ago to handle the differences:
>>>>>>>>>> CSplit: Version 2.2 >>>>>>>>>>
>>>>>>>>>> CSplit: Begin part 1/1 >>>>>>>>>>
>>>>>>>>>> CSplit: Begin file watcomc.c >>>>>>>>>>
/*
 * WatcomC specific functions/global variables
 */
#include "watcomc.h"
#ifdef __WATCOMC__
#include 
long g_lbkcolors[16] = {
    _BLACK, _BLUE, _GREEN, _CYAN,
    _RED, _MAGENTA, _BROWN, _WHITE,
    _GRAY, _LIGHTBLUE, _LIGHTGREEN, _LIGHTCYAN,
    _LIGHTRED, _LIGHTMAGENTA, _YELLOW, _BRIGHTWHITE
};
#endif
>>>>>>>>>> CSplit: End file watcomc.c >>>>>>>>>>
>>>>>>>>>> CSplit: Begin file watcomc.h >>>>>>>>>>
/*
 * functions/macros that convert from Borland code to Watcom
 */
#ifndef WATCOMC_H
#define WATCOMC_H
#include 
#ifdef __WATCOMC__
#include 
#define gotoxy(x,y) _settextposition(y,x)
#define clrscr() _clearscreen(_GCLEARSCREEN)
extern long g_lbkcolors[16]; /* located in watcomc.c */
#define textattr(c) { _settextcolor((c) & 0x0F); _setbkcolor( \
\
g_lbkcolors[((c) & 0xF0) >> 4] ); }
#define OUTTEXT(str) _outtext(str)
#define wherex() _gettextposition().col
#define wherey() _gettextposition().row
/* for outporting... */
#define outportb outp
#else
#define _dos_findclose(x)
#define OUTTEXT(str) cprintf("%s",str)
#endif
/* Turbo C++ doesn't define this for access(), so we will here */
#ifndef F_OK
#define F_OK 0
#endif
#endif /* watcomc_h */
>>>>>>>>>> CSplit: End file watcomc.h >>>>>>>>>>
>>>>>>>>>> CSplit: End part 1/1 crc: 721d >>>>>>>>>>
 HS> direct output to screen. If a compiler contains the 
 HS> functions textcolor() etc, then it HAS an equivalent 
 HS> for cprintf().
Which is NOT cprintf!
 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.
I love it when you start disagreeing with yourself.  And failing to cast 
void* to the appropriate type hasn't worked on any of my compilers for a 
while...
DM>Something like that.  Now, if you'd stop using infantile logic...
 HS> Education begins at the lowest level.
Come back when you've finished grade 1.

---
---------------