Oh, in Linux, yeah. Strictly speaking, there are "syscalls" underlying Windows, too, but we're generally not allowed to touch 'em. Take away the "MS" and we've got a C library, too. The C library provides open/read/write/close and also provides fopen/fread/fwrite/fclose. The latter group are "buffered I/O" - they allocate a buffer and manage it, as well as accessing the file. This makes a big difference, for example, if we were reading a file a byte at a time. "read()", which is pretty much "sys_read", AFAIK, we would read a sector (smallest amount we can actually read), and fetch a byte from it. "read()" another byte, and we read a sector again, and fetch a byte from it. "fread()" only actually reads from the disk the first time, and when the buffer is exhausted - subsequent "fread()"s just fetch a byte from the buffer until we actually need to "read()" some more sectors. This can make a C program much faster than a naive asm program! Of course, if we're aware of this, we "read()" or "sys_read" a bufferfull at a time and just fetch bytes from it - just like "fread()" is doing for us.
As I recall when I was trying to learn C, they told us to just use the "f" versions and forget the "low level" calls... but I'm pretty sure the "high level" routines use the "low level" routines, and ultimately syscalls, to do the actual work. So I guess you could say that the syscalls exist to enable the library calls, rather than the other way around...
Best,
Frank
