Zortech problems

[Bob Stout]

In an article of <14 Feb 90 16:48:00 GMT>,  (Peter Nelson) writes:

 >   A while back I posted a question about allocating large 2 dimensional 
 >   arrays AND ACCESSING THEM AS 2 DIMENSIONAL ARRAYS.
 >   [...discussion follows of malloc'ing vs. huge model...]
 >   But why does Zortech make you go to this trouble?

  As Walter Bright pointed out, this is a philosophical difference. The ZTC  
code will run faster than code using huge pointer manipulation, though the  
latter is admittedly easier to write. The bottom line is to blame Intel for  
the segmented architecture.

 >   As far as I can tell, none of the "get" string or character functions 
 >   (getc, getch, etc) Zortech supplies will return without *waiting for a 
 >   keystroke*, so I can't write a routine which periodically checks to see 
 >   if anyone has typed something from the keyboard.  There must be some DOS 
 >   call that can fix this.   But why does  Zortech create the need to find a 
 >   workaround in the first place?

  All of the calls you mention are either ANSI or compatible with MSC/TC. The  
easiest way to do what you want is to use the kbhit() function - the same non-
ANSI function you'd use from MSC or TC. This is not a Zortech "feature", but  
one common to most popular DOS C compilers.

 >   An even more glaring problem is the apparent lack of any way
 >   to output text in graphics mode!!!  

  While you have the library reference open to look up kbhit(), you might  
flip to pages 182 and 185 and see if fg_putc() or fg_puts() might be what  
you're looking for. Amazing what goodies you can find when you look through  
the documentation! (BTW, thes functions do work as described - I tried them  
before posting the message.)

 >   Finally, I tried running one of my programs on a friend's 286 system
 >   with a Paradise VGA card.  The software mangled the timing of the VGA 
 >   display and outputted ca-ca.

  Making FG compatible with all the various cards in the aftermarket has been  
an ongoing and evolutionary process with Zortech. Rather than deal with the  
overworked, underinformed tech support folks in Boston, I suggest you contact  
Joe Huffman, the author of the FG library directly via Walter Bright's BBS at  
206-822-6907 (8 data, 1 stop, no parity, connect, then hit space twice).

 >   I've only used a tiny subset of Zortech's C and C++ and library
 >   features and I'm dismayed at the number of problems I've already
 >   found.

  As noted, reading the manual *does* help. Two of your three gripes in this  
message had answers in the documentation. Your original multi-dimensional  
array problem has its roots in the Intel segmented architecture and the  
various ways different compiler writers choose to deal with the implications.  
Again, Walter's approach is justifiable and fully documented in the manuals.

 >   Right now Zortech is the only game in town for C++ on a PC. 
 >   But when Microsoft and Borland release their long-awaited products
 >   Zortech runs a serious risk of being completely blown away if it
 >   doesn't clean up its act fast.   

  I've been using Walter's compilers for the past 5 years starting with  
Datalight C despite continuing predictions that the "next release" by Borland  
or Microsoft would blow him away. I still use his compilers because they're  
the best for the work I do (your mileage may vary). Ultimately, most people  
choose compilers based on what they're comfortable with rather than technical  
merit. People pay me to write code using all sorts of different compilers so I  
can't afford to get too comfortable with any one of them, though I will admit  
a preference for Walter's compilers. Note that my loyalty is to the compiler,  
*not* to Zortech. (I actually preferred dealing with Datalight, but that's  
water under the bridge.)