Jerry Coffin wrote in a message to Roy.J..Tellason!1.270.615.0{at}filegat:

Looks like some aspects of the gateway still need a little work here.

 JC> From: Jerry Coffin 

Yeah,  you were around back when,  weren't you?  :-)

 JC> At 02:07 AM 1/15/2004, you wrote:

 JC> [ ... ]

>  PS> Then I got a PC and (because of school) got into Turbo Pascal.
>
>That was,  if I'm remembering right,  also available for CP/M boxes. 
>In fact
>it was one of the first higher-level languages available for the CP/M
>platform.

 JC> It was really a lot closer to being one of the _last_.  By the time
 JC> it came along, the PC was already imminent, and when it came out
 JC> new languages for CP/M became quite rare.

 JC> In Pascal compilers alone, there were things like JRT Pascal,
 JC> Pascal/S, Pascal/MT+ (which had a number of direct predecessors
 JC> itself) as well as a couple of free Pascal compilers.

I seem to remember hearing about how JRT never quite worked the way it was
supposed to...  Pournelle,  maybe?  It's been a while.

 JC> On the C side, you've already noted Mix, but there was a pretty
 JC> wide range of C compilers as well, ranging from BDS C (small, fast,
 JC> pretty usable) to Whitesmiths C which was really FAR too large for
 JC> CP/M at all -- it wouldn't even fit on one disk with most systems,
 JC> so you had to swap floppies a few times to complete a single
 JC> compilation...

I'd forgotten about BDS.  A product that tended to do things their own way.
  And I didn't know that Whitesmith's had a CP/M product out at
all.

>Yeah,  most programs didn't bother with the BIOS because it was too
>slow.  And since you wanted to write directly into video ram you had 
>to find out what hardware was running (mono or CGA,  EGA and VGA came 
>a bit later on :-) and where that ram was.  Programs were a lot more 
>complicated in this respect.

 JC> Most programs were a lot more complex than they really needed to
 JC> be.

Yep!

 JC> In the end, you didn't really want to check the hardware per se, 
 JC> but the video mode you were going to use.  If you were in mono
 JC> mode, the screen started at 0xb800, otherwise it was at 0xb000.

That agrees with my recollection too.

 JC> The programs that tried to get fancy and detect the hardware 
 JC> usually ended up screwing things up -- just for example, an EGA or
 JC> VGA can emulate a monochrome adapter, so if you assume EGA/VGA ->
 JC> 0xb000, your program can end up wrong.

>Ok.  Where else would printf show up,  under bash?  I remember seeing it
>somewhere,  in a script file I think it was,  and it was kind of a kick
>because I had at least some clue as to what was going on.

 JC> AWK would be one obvious possibility -- it's a rather strange
 JC> language, but can be quite handy at times.

That's one I haven't messed with at all.

 JC> In AWK, you have a set of patterns it searches for, and an action 
 JC> to execute when a pattern is found.  The patterns are regular 
 JC> expressions.  The actions are in a unique language all their own, 
 JC> but it's somewhat reminiscent of C, and (in particular) does 
 JC> include a printf.

Yeah,  well,  maybe I'll get around to it sooner or later.  I may have it
installed,  I don't remember for sure.  If I do it's because of some
scripts or other that need it...

---