How does C work on non-unix?

[CBFalconer]

There's something privileged about command.com on DOS. On UNIX you
have a choice of shells, though you might be forced to use one by
the system administrator.

No there isn't. Just install 4dos, or 4nt. You never need
command.com again. Of course, you have to know how to do the
install.

 

[Malcolm]

Well, it's no different under X11.

Where's X11's "pascal" specifier?

Nonsense. Memory mapped files work on IDE, SCSI, floppy or
network shares, regardless what particular access mode the
hardware/driver/OS prefers.

Huh? A games console isn't generally a hosted environment, so no stdio. You
do of course need to load data from bulk storage, which you generally do by
DMA (a hardware device that does a really fast memcpy() in parallel with the
rest of the program). You can of course run some sort of stream system over
the memory, once you've loaded it.

By providing either /dev/null or nul: as the first argument.
The paranoid might redirection to this device as well.

Shows how little I know about DOS. That's the first I've heard of nul:

Not really. There is even a famous replacement shell, 4dos.

And your user is really going to have heard of 4dos, or use it.

 

[Dave Thompson]

[... C] treats IO as streams, which was influenced by UNIX, because this
model makes sense on a UNIX box.

True -- and historically C and Unix were closely interdeveloped (if
you know what I mean). So I can't debate that C makes sense on Unix;
however, don't most post-Cobol languages use stream I/O, even those
primarily developed on non-Unix systems?

PL/I has both record-oriented binary I/O and effectively-stream
character I/O. (As Fortran sort of does, and to a first approximation
PL/I includes everything in Fortran and COBOL plus more.)

Classical BASIC is mostly line-oriented, although the micro/PC BASICs
mostly had (have?) screen-oriented extensions. I think SNOBOL was
line-oriented, but those memories are *really* fuzzy. awk, if you
consider it a programming language, is normally line-oriented.

Pascal and Ada do text I/O as character streams broken into
lines/records and pages, but by (notionally) out-of-band signals
rather than reserved characters. And also, but probably less often,
raw I/O that may be record-oriented.

Trivially, assembler normally provides only whatever the OS does, so
on record-oriented OSes like OS/360 et seq it's record-oriented; on
(mostly) stream-oriented OSes like Unix it's stream-oriented; on
(sometimes) character-oriented OSes like MSDOS or TOPS etc.

Wait. Don't answer that. I just remembered that whether C makes
sense or not, that doesn't affect its portability to non-Unix systems.
So it's a moot point.

Too late <G>. I assume you meant here "whether the C (stream) I/O
model makes sense on non-Unix systems". It does affect portability in
that it may be too difficult to implement C I/O on some system and
thus there will not be a (conforming) implementation at all; but if
there is, standard code will be portable to it. Modulo resource limits
and the weasel wording, as always.

- David.Thompson1 at worldnet.att.net