Hi Roy! :-)

 RJT> That's a real good point.  I think a lot of
"programming" isn't so 
 RJT> much sitting down and writing code as much as defining both one's 
 RJT> understanding of the problem and the approach you plan to take to 
 RJT> deal with it.
Much agreed, but some amount of sitting down and coding is often required
to understand the problem and to find out what kind of infrastructure a
solution requires. Some design can be done before starting to code
(sometimes it's obvious how many different modules are needed and what they
should do), but things also tend to come up while writing the code (like
ending up writing a couple of somewhat similar function and then putting
them all in a module of their own).

 RJT> I saw an awful lot of those machines,  mostly because of repairing 
 RJT> them,  which I did for a while.
Never had a problem with mine despite some abuse. ;) I wish I had kept and
not sold it.

 RJT> I thought back then that it would've been a whole heck of a lot more 
 RJT> usable a computer if someone had come up with a small card to plug 
 RJT> into the cartridge port and let you plug a 34-wire floppy cable on 
 RJT> the other side.  There even seem to be some lines there that were 
 RJT> meant for something of the sort.
Well, there were also regular floppy drives for the C64. I had one, but
they used one of the other ports of the machine. ;)

 PS>> Then came university, which brought me to Linux and programming in 
 PS>> C and to some small extend also in C++.
 RJT> I've never really felt much attraction to c++ at all,  there's 
 RJT> enough with c to keep me busy for a really long time.  
C++ was required by some university courses, I don't use it when I have a
choice. I'm not a big fan of the object-oriented approach. It has its uses
for some things, none of which interest me (GUIs and such).

 RJT> Yeah,  most programs didn't bother with the BIOS because it was too 
 RJT> slow.  And since you wanted to write directly into video ram you had 
 RJT> to find out what hardware was running (mono or CGA,  EGA and VGA 
 RJT> came a bit later on :-) and where that ram was.  Programs were a lot 
 RJT> more complicated in this respect.
A somewhat similar problem exists today, at least when you're writing
portable stuff meant to run on different Unix flavors. It's not so much
about hardware, but about what system libraries are available and what
functions they provide.

 PS>> Well, much of what is found in the Linux C library is derived from
 PS>> the POSIX standard(s).
 RJT> I don't even know what those _are_.  Except vaguely,  that is.
POSIX == Portable Operating System Interface for Unix

The standards define a lot of library function that have to be there and
also document system tools like sed or grep, along with a set of parameters
that those tools have to support to be able to call themselves
POSIX-compliant.

[...]
 RJT> I remember back when I was in here years ago there were people then 
 RJT> who were using makefiles and such,  I never got into anything that 
 RJT> complicated at the time and now it seems like an awful lot of stuff 
 RJT> uses them.
It has lots of advantages for any project with more than, say, two .c and
.h files. For one, how to build the software is documented by the makefile
and there is no chance to forget any details. For bigger projects, the fact
that make only rebuilds what needs to be rebuilt is a big plus during
development.

 RJT> At some point I'd like to get a better understanding of 
 RJT> that stuff too.  I see where O'Reilly has a book out on the subject, 
 RJT> maybe I'll see if I can find some online info on it if I can't 
 RJT> locate the book locally.
I've learned my make knowledge from "info make" ;), but O'Reilly
books are generally known to be of very good quality, too.

 RJT> Ok.  Where else would printf show up,  under bash?
printf is a command-line tool that is part of the sh-utils package (or in
newer distribtions the coreutils package), so it's documented in section 1.

 RJT> That's good to know.  There seem to be an awful lot of libraries out 
 RJT> there, and I have no clue as to what most of them are for,  or why 
 RJT> some applications seem to need so many of them.  Where is this 
 RJT> documentation normally found,  in the source packages?  I don't 
 RJT> recall running across much of it in the system here.
Much of it is manpages or html docs that are installed alongside the devel
packages. For example, on Red Hat, libpng documentation is part of the
libpng-devel package. They also come with the sources, mostly, yes.
Sometimes the documentation only lives on the project's web pages, though.

Ciao
Pascal

--- Msged/LNX 6.1.1