Sticky IBM C programming problems (summary of replies)

[Charles Hannum]

I seem to have missed your original posting, so I'll take this opportunity to
respond.


In article <498 at bilver.UUCP>, alex at bilver.UUCP (Alex Matulich) says:
>
>                      ...   the MSC manuals do NOT answer my questions, which
> is why I asked them; the Turbo C manuals do, however the ones I had
> were from version 1.5 or earlier and I didn't know it!
>
> I have been using primarily MSC.  Almost every single respondent is a
> Turbo C user, so many of the responses didn't apply to MSC -- I didn't
> realize Turbo C was so popular.  Anybody know anything about Lattice?

Probably because Turbo C is *fast*, the integrated environment in one *hell*
of a lot better than M*crosoft's, and the manuals are superb!


>COMMENT:  I was hoping to preserve portability in my programs by using
> cprintf() everywhere, and, in porting it to a non-IBM computer, using
> #define cprintf printf, but cprintf() doesn't translate the \n character
> properly, nor does it work with ANSI escape codes.  But I do have uses.
> cprintf() in Microsoft C is just as SLOW as printf()!  Turbo C is much
> faster, but the text doesn't inherit the current stdout text colors.
> As far as I can tell, _write() needs a file handle, and I don't know how
> to get a file handle to the video memory.

Lemme explain ...

cprintf(), et al., are specified to write directly to the CON: device (or
/dev/ttyxx, or whatever), rather than to stdout or stderr.  They are
*supposed* to do the same translations as printf() (et al.); I suspect this
is why the MSC library routines seem to offer no improvement in speed over
the normal printf() routines; this is not what they were meant for.

In Turbo C 1.0 (I've had it since the beginning!) the output was sent directly
to the MS-DOS console I/O functions (rather than the file I/O functions, which
are normally used).  However, this didn't follow the definition either, as they
could be redirected.

Starting with Turbo C 1.5, the console library has forced it to write directly
to the screen (literally!!!  B-), but it still doesn't do proper translations;
you still have to use "\n\r" rather than "\n".  <sigh>

If you just want to speed up output, and you're displaying line-by-line, use
setvbuf(stdout,... _IOLBF ...) (not exactly; fill in the missing arguments!).
I don't know about MSC, but this DRAMATICALLY improves performance in Turbo C.
(The reason, for those interested, is that Turbo C says "Hey!  It's a character
device!" and proceeds to write ONE STINKING CHARACTER at a time.  With MS-LOSS
this is horrendously slow.  By using _IOLBF, a whole line is output on each
MS-LOSS call.  [Note:  _IOFBF on an output file is the same in TC as _IOLBF.])


>COMMENT:  gettext(), etc. is only available on Turbo C.
> My current project is too big to convert to curses, but I'll look for
> it next time.

I have yet to see a decent (read: REASONABLY FAST) version of Curses! on the
PC.  If someone actually has a copy, I'd appreciate it, as I don't generally
make a habit of porting brain-dead software.


>COMMENT:  textbackground() and textcolor() aren't available with MSC.
> Escape sequences don't work with cputs(), cprintf(), etc. but it's not
> a real problem to use escape sequences with stdout functions when speed
> doesn't matter.

In your portability quest, you are not considering the problem of porting to
an entirely different *architecture*.  What if you're using a Tektronix
terminal on a *nix machine?  The escape sequences will be completely different!
Your best option, if you want total portability, is to use a *nix-like
"termcap" file.


>COMMENT:  Hmmm, that's right -- if I wait LONNNG enough, the critical error
> handler does indeed get invoked with a "device not ready" message.  From
> the responses I got, I gather that there's not really any good way to do
> this.  And how do I access "the print spooler"??  Is it a part of MS-DOS?

The "print spooler" is PRINT.COM.  It's documented in the MS-DOS manual.


>COMMENT:  Sure enough, there it is in the MSC manual!  The MSC index listed
> nothing useful under "directory", "directory control", "files", and other
> obvious headings.  _dos_findfirst(), indeed!  I never looked at that one
> long enough to realize what it was.  Also, implementation differences
> between these functions in Turbo C and MSC make for difficult porting.

These functions are not derived for any type of standard, and therefore cannot
be expected to be portable.  Tough.


>Look in argv[0], it contains the path of the program.  Then use fnsplit()
> and fnmerge() to manipulate the path.  Works under DOS 3.x.
>Use searchpath().
Note:  This was in reference to the statement below, which indicates that in
       DOS -3.00, argv[0] doesn't contain the complete path.
>In version 1.x and 2.x, your best bet is to search the current directory,
> and then the path, yourself, which is a pain.
Note:  Version 1.x doesn't use paths.  [B-)]


>[What books do you recommend?]
>The manuals that came with Turbo C
You'll get no argument on that one!  They're excellent!

(Herbert Schildt's?) "Turbo C Pocket Reference".  I'm not sure it's ever been
updated since version 1.5, but it's still an incredibly useful book.


>Many thanks to all the people who contributed (did I leave anyone out?):
>
> ...
>CMH117 at psuvm.psu.edu (Charles Hannum)

I'm at the bottom of the list!  <wimper>  B-)


Virtually,
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  cmh117 at psuvm.{bitnet,psu.edu}  "No noozzzz izzz netzzzsnoozzzzz..."
  c9h at psuecl.{bitnet,psu.edu}    "Mem'ry, all alone in the moonlight ..."