Andy,
I've read your original post, and the several posts that
have followed, from Randy, Clarence, Day, and yourself.
As usual, each contributor sees things through different
eyes. So my answer will address a number of things,
without attempting to pre-empt anyone else's input.
My credentials: My first language was assembly, and
I've used it on 4 quite different CPU types and under 4
operating systems/operating environments. My first
program was a complete telex/modem package that
included its own text editor. I rewrote it twice under the
original OS (CP/M) to achieve better generalization of
hardware and to make those parts that would always
depend on specific hardware easier to port from one
machine to the next. My second language was 'C',
and I have written all kinds of stuff in that -- database,
communications, screen interface managers, DOS
utilities, and so on.
So at least I have a clue. And, clearly, others who
answered also have a clue. Let's begin.
There are two kinds of things you can write in 'C',
things that depend on specific features of the OS
or machine for which you are writing, and those
that don't.
Writing a simple text filter, a sorting program, a line
editor, or any of several other generic utilities, should
not involve any degree of dependency on either the
OS or the hardware.
Writing anything that handles communications will
depend, at least to some degree, on features that
are available in the OS, and possibly on the target
hardware.
Anything that directly addresses the cursor position
on the screen depends on the minimal ability of the
hardware to do that. Some OSes include an interface
to a code library that does this, some don't. For those
environments where it's not directly supported by the
OS, there is usually a general-purpose code library
that does support it. Under the Unix family, this is the
"curses" library. Under DOS there are commercial
packages (or were, anyway), and there may be a
version of "curses" (PC-Curses, perhaps?) for DOS.
All the windowing OSes have specific features of
their API that do this.
Anything you can write with 'C' you can also write
with assembly -- it's just more work -- and you're
not going to just drop it onto another hardware
platform. Sometimes (e.g. certain embedded
systems, where what you write *is* the system),
assembly will be the right choice. Other times you
will need to use assembly for a piece of the code
that talks directly to some piece of hardware --
this is called a "driver." For pretty much everything
else you want to use a higher level language, and
often 'C' can be that language.
"Portable" means "can be compiled in environments
other than the one originally used for development."
Properly organized, 'C' (and C++) can be quite
portable -- possibly more so than just about any
other language (the Pascal guys will point out
that Pascal is equally portable -- and I believe
this is true). Basic is higher level, but, in general
it's less portable, depending on the dialect you
select.
Certain 'C' compilers include direct access to
assembly language (called "in-line assembly")
and sometimes will include features to take
advantage of known aspects of the OS and/or
the hardware. Use these features with care --
make a point of isolating those routines which
depend on OS or hardware features. This way
when you move your program to a new platform
you have minimized the number of places in
your program that need to be "tweaked" to get
it running in its new home.
ANSI 'C' does not promote or forbid the use of
specialized libraries. It provides the framework
and the grammar for expressing math and logic,
calling routines, passing values, and getting
returned values back from called routines. If your
code calls a routine in a special-purpose library,
'C' is completely ok with that. If that library code
does something that's specific to the hardware
or OS, you'll need a replacement library when
you port your code somewhere else.
In choosing your language, you will need to
balance these things:
1) target platforms -- where will it be used?
2) availability of platform support -- code libraries?
3) maintenance -- will others need to see the code?
4) investment of effort -- which language will let
me write this in the least time?
If (1) is "just DOS" or "just Unix" then (2) gets
easier. If (3) is "only me, no one else" then (4)
becomes a wider range of choices. Another
aspect of (3) is "am I tryin to learn something that
a bunch of other people already use?" If this is
true, then that narrows the choices for (4).
I have not researched "how would I find out" which
compilers are most portable or which ones have
the most comprehensive support for particular
hardware. I believe some of the other traffic on
this has mentioned some sources. My selection
of compilers has usually been constrained by
my employer.
Not all compilers are created equal. For years
competing 'C' compilers under DOS sought the
"holy grail" of code generation:
1) small executables,
2) fast executables,
3) fast compiliation.
Sometimes (2) is most important, while under
other circumstances (1) is the greatest concern.
And (3) is always a factor if you're paying guys by
the hour.
For DOS and Windows, both Borland and MS
have very usable compilers, with comprehensive
debugging suites (these are also important).
For Unix, there's plenty to choose from. I would
try to find a compiler which has versions available
on all the platforms I plan to use as targets for
my application.
At the very least, become acquainted with the
assembly language of your primary hardware
platform. This will serve to de-mystify the inner
workings of the higher-level language you choose.
Once you know one assembly language, you'll
have at least a decent idea of what's going on
under the hood, even when you move to another
piece of hardware. Much may change, but the
basic concepts won't.
By the way, 'C' and C++ aren't the only flavors
of 'C'; there is also "object C" (also known as
"objective C"). It is considered by many to be
a cleaner and lighter implementation than C++.
I've not used it, so I can't say from experience.
I don't believe you would be wasting your time
learning 'C' -- I believe that's time well spent.
I have some other things I also recommend
for the serious student, but let's not muddy the
water.
Oh -- in answer to the "is assembly too low a
level for coding in Windows" question: Steve
Gibson (www.grc.com) and others write only
in assembly language -- even for Windows.
That involves a real commitment, for there is
not only a learning curve, but the accumulation
of a code base upon which to build your
applications.
That will be 2 cents, please.
~~Garry
[EMAIL PROTECTED]
-----Original Message-----
on Friday, July 20, 2001 7:04 PM
ANDY <[EMAIL PROTECTED]> wrote:
>
> if I write a program in ANSI C (is Arachne written in
> ANSI C?) does that mean it will run on ANY hardware?
>
> when I write a program in C or C++, will it's ability to run,
> or/and run properly, on a/or given hardware, depend on
> what compiler/programming environment I use??
>
> and, if so, how would I find out which compiler/programming
> environment offers the greatest hardware compatibilty?
> (I forget which compiler was used for Arachne)
>
> how would I find out which compiler/programming
> environment is suitable for which hardware? or I guess I
> should ask: which hardware is suitable for code compiled/
>created using which compiler/programming environment??
>
> just curious...
>
> Andy
> [EMAIL PROTECTED]
>
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
