OS file reconciliation

[muta...@gmail.com]

It seems to me that there are two different ways of
writing an OS.

1. Unix-style. open/read/write or my equivalent
PosOpenFile etc. These OSes allow an arbitrary
number of bytes to be read from a stream.

It might be necessary to extend this so that the
open() call knows whether this is a text or binary
stream as that may have implications when writing
to a device like a card punch.

2. MVS-style. The OS does not maintain bytes for you.
You are instead given an entire block and expected to
manage it yourself.

MVS has a RECFM=V which I don't think should be
supported as a concept for an OS standard.

There is also the possibility of blocks being shorter
than the maximum (for the end of the file). But there
will be a concept of the block size being a multiple of
a particular number (record size).

I don't think the MVS concept of short blocks in the
middle of a file should be supported for an OS
standard.


I don't like POSIX, which does (1), since it requires
things like fork(). I'm after a simple API for (1), close
to MSDOS.

And I'm after an API for (2).

PDPCLIB can then support these two flavors. It basically
already does, but not for these exact 2 APIs which haven't
been defined yet.

Any thoughts?

BFN. Paul.

[wolfgang kern]

there are much more than two options on how to create an OS.
If you chose either of this two your OS wont be any different
to what's already around for decades.

I wrote my own tools and designed my own filesystem,
and I gave a fart to compatibility with any M$-BS.
I would never ever use C-libraries for hardware-drivers.
__
wolfgang