Book on Microsoft C

[Edward J Driscoll]

In article <10107 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>specific detail you'd need to know.  All of the language
>extensions inevitably provided should be avoided whenever
>possible, not exploited.
>
>for the IBM PC," etc.  These books may be the only source of
>important documentation, which the irresponsible vendors have
>neglected to provide, but they also teach you (if only
>implicitly) to write machine-, system-, compiler-, and device-
>dependent code.
>
>                                            Steve Summit
>                                            scs at adam.pika.mit.edu

I disagree with the notion that portability is necessarily the
primary consideration.  It very well may be in some cases, but
a programmer who knows his software isn't going to be ported anywhere,
or would require major work in any case (that is, if it was
machine-dependant by nature), has every right to know about and
use machine-, system-, compiler-, and device- dependant code.
A simple case in point:  A DOS programmer who wants fast screen
IO will use the machine-specific trick of writing directly into
the video RAM.  Sure, this makes his program a little less
portable, but it also makes it more attractive to the end user,
who probably doesn't give a whit about portability, but WILL
notice the speedup in screen IO.  To claim that programs should
always be written in the most portable way is like claiming that
they should always be optimized for speed, rather than space.
There are costs to take into account, and whether or not to
use machine-specific code is something that should be decided
on a case-by-case basis.  Personally, I know how to write
portable code, but I rarely need to.  When I know ahead of time
that portability isn't an issue, I'll go ahead and get as much
as I can out of my hardware and compiler.  If that means using
machine-dependant code, big deal.

-- 
Ed Driscoll
The University of Michigan
ejd at caen.engin.umich.edu