Pascal Schmidt wrote in a message to Roy J. Tellason:

 PS> 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.

 PS> Yeah, that happens. I have looked at the source code for some
 PS> packages that interested me, and while all were C, some I couldn't
 PS> understand at all and others were obvious to me. Depends a lot on
 PS> 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 
 RJT> enough in c to sit down and make something work,  if I wanted to 
 RJT> do that.

 PS> That's a good start already.

Well,  I've been around here for a while,  Bob knows ,  even got
my name tossed out for moderator twice a few years back,  which I declined
both times.  I was filtering by subject pretty heavily back then and barely
able to keep up,  and that would've meant I had to read *all* of the posts.
 There was just no way I could manage it.

The thing is,  I haven't *done* anything with it.

 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.

 PS> Yep. What helps me a lot is just trying to write something myself -
 PS> even if I don't know much about the problem at hand, it helps to
 PS> get an understanding of the basic principles of the particular
 PS> problem and that in turn helps a lot with understanding other
 PS> people's source code for the same thing.

That's a real good point.  I think a lot of "programming" isn't
so much sitting down and writing code as much as defining both one's
understanding of the problem and the approach you plan to take to deal with
it.

 PS> I cut my teeth (so to speak) on the C64, first with BASIC and then
 PS> with assembler (using a simple monitor program to input it, so I
 PS> had to calculate all the jump offsets by hand, knowing the length
 PS> of most of the instructions by heart).

I saw an awful lot of those machines,  mostly because of repairing them, 
which I did for a while.  I also got together with a few friends and we got
a book doing assembly with it,  and accumulated some tools,  but I never
really did anything serious with it.  At that time I was mostly running a
CP/M box.

I thought back then that it would've been a whole heck of a lot more usable
a computer if someone had come up with a small card to plug into the
cartridge port and let you plug a 34-wire floppy cable on the other side. 
There even seem to be some lines there that were meant for something of the
sort.

 PS> Then I got a PC and (because of school) got into Turbo Pascal.

That was,  if I'm remembering right,  also available for CP/M boxes.  In
fact it was one of the first higher-level languages available for the CP/M
platform.  There was also small-c,  which was free but pretty limited --
integer only,  and no structs,  I forget what else it was missing.  But you
got the source with it (and I still have it around someplace).  I forget
what else was around for languages back in those days.  I messed around
some with dbase II,  but the implementation I had was an earlier one and
fairly buggy. Eventually,  fairly late in the game,  I got Mix C.

 PS> Then came university, which brought me to Linux and programming in 
 PS> C and to some small extend also in C++.

I've never really felt much attraction to c++ at all,  there's enough with
c to keep me busy for a really long time.  

 PS> [...]

 RJT> One of the things that bugged me back in those days was all of 
 RJT> the platform-specific stuff then,  things like "find out what 
 RJT> kind of a monitor and video subsystem is in the box we're running 
 RJT> on" for example.  But this was probably before you got into it.  
 RJT> :-)

 PS> I only got a mild dose of that in that I had to distinguish between
 PS> the EGA hardware my school was using and the SVGA stuff I had at
 PS> home. Before that, I programmen on a C64, and there obviously were
 PS> no hardware variations worth mentioning.

Yeah,  most programs didn't bother with the BIOS because it was too slow. 
And since you wanted to write directly into video ram you had to find out
what hardware was running (mono or CGA,  EGA and VGA came a bit later on
:-) and where that ram was.  Programs were a lot more complicated in this
respect.

 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.

 PS> I sure never was into Windows programming, never even tried doing
 PS> much under that system. I went more or less straight from DOS/Win
 PS> 3.1 to Linux, with maybe a couple of weeks of Win95 inbetween.

I *have* 95 and 98 here,  got 98 installed on the one box after I trashed
the registry on the original 95 installation beyond repair by continually
trying to get rid of the last residues of all of the corporate crap that
was in there from the machine's earlier life,  but I sure don't use it
much.  I have 3.1 installed on _this_ box (the bbs machine),  but since it
won't co-exist nicely with Desqview,  I don't run it.  I don't think I've
run it since probably around 1996 or so.  :-)  And the 3.11 install I had
on a 386 box that was the predecessor of the w98 machine (before we got
that one) is still loaded up on the original 80M drive that we used back
then.  I have a couple of 170M drives stuck in that box,  was planning to
resurrect it at some point for the simpler games for the younger grandkids,
 but I simply have no place to put it just now.  So it'll sit and wait
until I get around to it.

 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.  :-)

 PS> Well, much of what is found in the Linux C library is derived from
 PS> the POSIX standard(s).

I don't even know what those _are_.  Except vaguely,  that is.

 PS> No idea whether those are available for free, but I'd guess they 
 PS> don't make a good introduction anyway.

I see a number of references to them in man and info pages.

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

Yep.

 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.

 PS> Well, it depends. Basic stuff should still work on current Linux
 PS> system, sure (I did try to compile some original Unix V7 source on
 PS> my system and some commands, even sed, compiles and ran without
 PS> modifications), but sometimes there are newer functions for the
 PS> same jobs which may or may not have advantages. ;)

True.  The few very small and simple compiles I've tried with "cc
whatever" have worked,  and shown me some bugs to be swatted,  typos
and such,  while the heavier-duty stuff has been someone else doing most of
the work and I just use make  and let it rip.

I remember back when I was in here years ago there were people then who
were using makefiles and such,  I never got into anything that complicated
at the time and now it seems like an awful lot of stuff uses them.  At some
point I'd like to get a better understanding of that stuff too.  I see
where O'Reilly has a book out on the subject,  maybe I'll see if I can find
some online info on it if I can't locate the book locally.

 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.

 PS> Sure is.

 PS>> man 3 dlopen

 RJT> Is it necessary in general to specify the number in there?

 PS> For dlopen it doesn't make any difference, but some library 
 PS> functions have the same name as user commands (for example, man
 PS> printf doesn't give you the description of the printf C function),
 PS> so I just play it safe all the time.

Ok.  Where else would printf show up,  under bash?  I remember seeing it
somewhere,  in a script file I think it was,  and it was kind of a kick
because I had at least some clue as to what was going on.  I've never been
the type to memorize all the fine details of things like that (the format
specifications for example),  figuring it was handy enough if I had a book
that I could look it up in.  And I'm continuing the same approach to stuff
with the man pages.  

 PS> [example in manpage]

 RJT> Now that sounds handy!

 PS> Yep. I've done some medium projects in C on Linux so far, and most
 PS> of the libraries I used (libpng, libxml) have good documentation
 PS> available.

That's good to know.  There seem to be an awful lot of libraries out there,
and I have no clue as to what most of them are for,  or why some
applications seem to need so many of them.  Where is this documentation
normally found,  in the source packages?  I don't recall running across
much of it in the system here.

 PS> To be fair, I've also seen the opposite - libavcodec, a video 
 PS> encoder/decoder library, has very limited documentation and I 
 PS> basically had to try a lot of things by hand and look at other 
 PS> people's code - no real docs came with the library itself. Well,
 PS> that's very much an experimental and very actively developed 
 PS> library. The standard stuff has good docs.

Sometimes I need to fiddle with stuff to get a handle on how it works, 
too,  and sometimes it isn't like I think it is,  but slightly different.

 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.

 PS> I've learned to get along with info. I just use return to enter a
 PS> new topic and l to return to wherever I was before. And sometimes /
 PS> to search. If I press any other navigation key, I get lost - but
 PS> while only using those few keys, the info reader works quite well
 PS> for me.

I'll play with it some more,  no doubt,  but I have little patience with it
at this point in time.

 PS>>     apropos dynamic
 PS>> would have turned up the dlopen(3) manpage among others.

 RJT> I use that sometimes,  but not that often.

 PS> I personally almost never use it, it's just to hard to find
 PS> appropriate keywords. apropos only searches the NAME part of
 PS> manpages, so you're at the mercy of whoever wrote the manpage - if
 PS> they place good keywords on that one-line short descriptions, good;
 PS> otherwise, bad luck.

Hmm.  Interesting point.  I was just reading (in a book about the inet+
certification) about indexing web pages,  and some of the things that need
to be considered,  so it's somewhat fresh in my mind.  It's not something
I've given a lot of thought to before.

---