Doesn't quite sit in this forum, but it is software related so I'll ask here anyway.

When coding C++, the C++ language, of course, does not know what an input device or an output device etc. is, along with a whole bunch of other stuff. I simply include some kind of library and use the functions therein to control file IO etc.

Presumably, within these libraries is some code that knows how to ask the operating system for input/output (or handles it directly) and within the operating system is some code that handles it directly.

My question is really where can I get an understanding of how this is done. Presumably, the writers of the libraries such as iostream have to know how to ask the operating system to do these things on my behalf, and the writers of the operating system have to (presumably at some very low level) know how to connect directly to hardware, or through device drivers which, in turn, directly address as very low level the real world hardware.

Presumably these coders need to know all about the operating system they're writing for, and the device driver writers need to know all about the operating system and how to carry out low-level calls to their devices (which, I'm guessing, have to change a little for every operating system and probably involve directly manipulation of memory addresses and the like).

There's a whole universe here that I never get to see because I just bring in a library and use a library functions, but I want to know more about this. Where can I learn this, both from the OS side and also about hardware device drivers and the like? There are lots of forums about for general OS issues and coding problems, but I've not found much at this deeper level.

There is a book "LINUX System Programming" by Robert Love that could probably answer all of your questions on system programming.
The libraries will make a system call when they need the kernel to perform a function. Some of the c library functions you use may not be system calls in themselves but will call system calls. Linux has a standard interface for these calls. Unfortunately, as the joke goes, the marvelous things about standards is that there are so many of them. See the man page for "man 7 feature_test_macros". You may have wondered what the argument -D_GNU_SOURCE did. It defines which interfaces your program can use and other things like the maximum number of files you can rely on being able to be open at a time (by a process).

Another book that goes into more details is "Advanced Programming in the UNIX Environment" by W. Richard Stevens and Stephen A. Rago.

Okey dokey, that gives me somewhere solid to start learning; thanks very much. As an aside, can anyone give me an idea of how different things are across architectures and operating systems?

Presumably, if you're running on x86 the low level hardware interactions must be the same no matter what O/S you're using, but how radical are the differences between, say, x86 and PPC? I appreciate that this is not quite the usual bread and butter of this forum (and indeed, I've wandered away from Linux now so we're way off course). In my defence, I like to think that your average Linux hacker appreciates the search for knowledge more than staying within topic boundaries!

In addition to the book recommended above it may be useful (or it may not but here goes anyway) to recognize the base "philosophy" of a UNIX based operating system -- and the essential function of the Standard C Library -- everything is a file.

What that means is that, say, the C Programming Language and derivatives (like C++) is identical on every platform (ignoring vendor-introduced extensions which should be avoided at all costs). If you write ANSI/ISO standard code (for an ANSI/IOS standard compiler), it will work the same no matter what the operating system might be, no matter what the hardware might be, no matter what else might be. Compiler vendors utilize a set of operating system calls, the really low level stuff that's part of, in the case of UNIX and Linux, the kernel or in non-UNIX/Linux systems the operating system (that would be Windows and others). All the vendor really needs is those few (in reality very few) operating system (kernel) functions and away you go. The idea is that the kernel sits there between the hardware and the rest of the system; it "knows" how to talk to hardware, your programs know how to talk to the kernel.

GNU C is a good, if perhaps simplified, example -- you can build the GNU compiler system on pretty much any hardware (X8x, SPARC, Motorola, etc., etc.) and operating system (UNIX, Linux, Solaris, Mac, Windows etc., etc.) and, from your source code point of view (avoiding extensions), it's identical. That's the true beauty of UNIX-like operating systems; you talk to the kernel, the kernel talks to the hardware and all is well with the world.

From where you sit as a programmer, you really don't care too much what the operating system may be. If you sit in the kernel, you care about how to "translate" between a calling program and the hardware.

And that's pretty much that.

Hope this helps some.

I'm all over this one; it's one of the things I really like about *nix.

You've pushed my attention away from the libraries themselves which, as you say, are (barring extensions and that sort of thing) standard-compliant C++, or C, or whatever. All the translation to a particular system happens in the compiler.

Sounds like what I'm really asking ,then, is how one goes about coding a kernel and to a lesser extent what the compiler does to attach my code to the kernel or O/S in question, which is quite a big question and, fortunately, specific enough that I should be able to go digging for resources myself. Many thanks.