Hi Roy! :-)

 RJT> I've looked at a bit of source,  and they seem to throw all sorts of 
 RJT> things in there that I never would have thought of.
Yeah, that happens. I have looked at the source code for some packages that
interested me, and while all were C, some I couldn't understand at all and
others were obvious to me. Depends a lot on the style used, I'd say.

 PS>> I could program before, just in other languages.
 RJT> I don't claim any particular expertise,  but I feel competent enough 
 RJT> in c to sit down and make something work,  if I wanted to do that.  
That's a good start already.

 RJT> Sometimes I can read a source file and understand what's going on,  
 RJT> sometimes I can't,  but that depends as much on the style of the 
 RJT> writer as it does on what's in the code.
Yep. What helps me a lot is just trying to write something myself - even if
I don't know much about the problem at hand, it helps to get an
understanding of the basic principles of the particular problem and that in
turn helps a lot with understanding other people's source code for the same
thing.

I cut my teeth (so to speak) on the C64, first with BASIC and then with
assembler (using a simple monitor program to input it, so I had to
calculate all the jump offsets by hand, knowing the length of most of the
instructions by heart). Then I got a PC and (because of school) got into
Turbo Pascal. Then came university, which brought me to Linux and
programming in C and to some small extend also in C++.

[...]
 RJT> One of the things that bugged me back in those days was all of the 
 RJT> platform-specific stuff then,  things like "find out what kind of a 
 RJT> monitor and video subsystem is in the box we're running on" for 
 RJT> example.  But this was probably before you got into it.  :-)
I only got a mild dose of that in that I had to distinguish between the EGA
hardware my school was using and the SVGA stuff I had at home. Before that,
I programmen on a C64, and there obviously were no hardware variations
worth mentioning.

 RJT> I don't do much with any flavor of windows,  since 3.1 onwards,  and 
 RJT> don't care to try and deal with programming on that platform at all.
I sure never was into Windows programming, never even tried doing much
under that system. I went more or less straight from DOS/Win 3.1 to Linux,
with maybe a couple of weeks of Win95 inbetween.

 RJT> Well,  there's standard library functions and then there's standard 
 RJT> library functions.  Stuff that I'm familiar with is probably pretty 
 RJT> near universal.  It's the platform-specific "standard"
stuff I need 
 RJT> to get to know.  :-)
Well, much of what is found in the Linux C library is derived from the
POSIX standard(s). No idea whether those are available for free, but I'd
guess they don't make a good introduction anyway.

It sure helps that you already know C and therefore are not going to be
surprised by having to pass around char pointer for strings and doing your
own memory allocation and freeing. It also means you'll understand what
library function manpages will try to tell you.

 RJT> I have some c books I got ages ago,  and now that I think of it one 
 RJT> of them was pretty much oriented toward the unix environment -- 
 RJT> mentioned "a.out" a bunch of times.    I'll
have to see if I can 
 RJT> dig that out of wherever it's hiding.  Yeah,  I know,  a.out is 
 RJT> pretty much obsolete these days,  or at least on anything I'm going 
 RJT> to be concerned with,  but the basic stuff oughta still apply.
Well, it depends. Basic stuff should still work on current Linux system,
sure (I did try to compile some original Unix V7 source on my system and
some commands, even sed, compiles and ran without modifications), but
sometimes there are newer functions for the same jobs which may or may not
have advantages. ;)

 RJT> This is a good thing!  The problem with that is that if I'm looking 
 RJT> for something and don't remember exactly what it's called.  I 
 RJT> suppose that would be a handy way to deal with trying to understand 
 RJT> someone else's code,  though.
Sure is.

 PS>> man 3 dlopen
 RJT> Is it necessary in general to specify the number in there?
For dlopen it doesn't make any difference, but some library functions have
the same name as user commands (for example, man printf doesn't give you
the description of the printf C function), so I just play it safe all the
time.

[example in manpage]
 RJT> Now that sounds handy!
Yep. I've done some medium projects in C on Linux so far, and most of the
libraries I used (libpng, libxml) have good documentation available. To be
fair, I've also seen the opposite - libavcodec, a video encoder/decoder
library, has very limited documentation and I basically had to try a lot of
things by hand and look at other people's code - no real docs came with the
library itself. Well, that's very much an experimental and very actively
developed library. The standard stuff has good docs.

 PS>>     info libc
 PS>> has introductions to everything.
 RJT> I *really* disklike the user interface for info.  I'll have to try 
 RJT> getting at that stuff under KDE,  where they say you can do that.
I've learned to get along with info. I just use return to enter a new topic
and l to return to wherever I was before. And sometimes / to search. If I
press any other navigation key, I get lost - but while only using those few
keys, the info reader works quite well for me.

 PS>>     apropos dynamic
 PS>> would have turned up the dlopen(3) manpage among others.
 RJT> I use that sometimes,  but not that often.
I personally almost never use it, it's just to hard to find appropriate
keywords. apropos only searches the NAME part of manpages, so you're at the
mercy of whoever wrote the manpage - if they place good keywords on that
one-line short descriptions, good; otherwise, bad luck.

Ciao
Pascal

--- Msged/LNX 6.1.1