get CPU info, RAM info

E

Eric Sosman

[...]
There are certainly a lot of IO and network stuff not
covered by POSIX.

But Roedy started the "standard in C" subthread by
referring to "File i/o, networking" in a reply to where
Mike were referring to "The OS-specific parts of the JRE".

Roedy's exact words were "File i/o, networking etc are
basically the same on all platforms." I and others have
offered examples to refute this overly broad claim.

There is a subset of these (and other) capabilities that
are widely available, a sort of least common denominator.
But "Every city has a pizza joint" does not imply that all
food is pizza, nor that a diet of nothing but pizza is good
for you.
 
E

Eric Sosman

[... file flavors on (Open)VMS ...]
As I recall, we got a pretty good match for C's notions of
file I/O by using StreamLF for "text" files and Undef for "binary"
files.

Those are the logical choices. But the VMS traditional way is to
use fixed 512 for binary.

Wouldn't have worked for our purposes, because we needed to
support "binary" files of arbitrary length, not just multiples of
512. Also, we needed to be able to seek to an arbitrary position,
not just to 512-byte record boundaries. (Seems to me the library
could have allowed this, but at the time it didn't -- this was, as
I said, a while ago.)
 
M

Martin Gregorie

And there were often pretty good language support for those accesc
methods in Cobol, Fortran, Pascal etc..
That was a technology requirement: Here is my justification for saying
that.

Initially the computer prime input methods were cards and paper tape,
followed by magnetic tape. Of these, the only character at a time i/o
method was paper tape - Cards are an all or nothing deal - read the whole
card or don't read it. Same applied to writing to it. Magnetic tape has
always has its data written and read in blocks.

If you commit to transferring a complete card image, then record-oriented
i/o is the obvious thing to do. It was supported at the assembler level
too: in a 1900 or S/360 the 'read' and 'write' instructions were handed a
device reference, buffer pointer and buffer length and, in
acknowledgement that peripherals were slow, there was also a 'wait for i/
o completion' instruction, so a typical assembler program could process a
card while the next was being read. No threading involved, folks! Given
this basis, it follows that:

- tapes and disks, which both have fairly substantial wait times before
date can be transferred were also best handled as record-oriented
devices[1].
- Tape: pause while the medium gets up to speed
- Disk: wait for heads to move to the required track and then for
rotation to bring the required block under the heads.
[1] in the case of disk and tape, initially the block was the record
but it was soon realised that grouping several records into a
block was more efficient.

- paper tape could read or write a character at a time, but there's
still a small start/stop time, so here too, dealing with a record
is more efficient though its harder to manage since the program
still reads single characters and must store the character its just
read, check for the record separator and issue the next i/o
operation before the tape reader or punch has stopped.

- with this background it's logical that the early high level
languages (FORTRAN, COBOL, RPG) would use record oriented i/o.

The real anomaly is the trouble all more recent languages (C, Java, Algol
68, PL/1, etc.) have taken to hide the underlying record/block transfer
nature of many i/o devices from the programmer.

Algol 60, Pascal and BASIC fall in the middle: the Algol 60 spec leaves
i/o as an implementation issue[2] and IIRC Pascal and BASIC can swing
either way.

[2] Eliott Algol was character oriented because the computers used paper
tape as the prime i/o medium and introduced READ and WRITE as reserved
words. All other implementations I've seen handled i/o by calling library
routines.
 
M

Mike Schilling

Eric said:
[... file flavors on (Open)VMS ...]
As I recall, we got a pretty good match for C's notions of
file I/O by using StreamLF for "text" files and Undef for "binary"
files.

Those are the logical choices. But the VMS traditional way is to
use fixed 512 for binary.

Wouldn't have worked for our purposes, because we needed to
support "binary" files of arbitrary length, not just multiples of
512.

I recall, many years ago, having problems with that. I was trying to write a
File IO library that would be portable to Unix and VMS, and needed files to
be of arbitraty length. RMS only supported files whose length was divisible
by 4 (or perhaps 2), so that required using the ACP's QIO interface. Not
fun.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
DewittMill
Top