BIOS vs OS

[[e-mail]]

(sorry for delay in zmodem response)

It occurs to me that at some level there is no difference
between a BIOS and an OS. Both of them have a set of
files/devices that they present to the level below them.

Both of them may present the file/device as either block
mode or a character stream. The C library will take care
of converting any block mode devices into character
streams.

An OS comes into existence when it converts one of those
files/devices into a new filesystem to present to the level
below them (ie applications).

PDOS-generic envisaged a BIOS that presented a structure
with the required C library in it. But this structure can
actually be made available to the OS's C library so that the
OS can access the BIOS devices as normal local files. Or
I can not bother with this layering and simply directly call
the Bos* functions, along with the Pos* functions, as part
of the OS C library. This does require activating block mode
and character mode logic in the same executable though.

BFN. Paul.

[[e-mail]]

Another principle.

The BIOS layer, possibly in the C library, will by
default take responsibility for echoing characters
from the keyboard and displaying them on the
terminal. This is until the OS sets setvbuf
no-buffering to indicate it is taking over responsibility.

Although at this point in time I can't think of any
reason why the OS would take over responsibility.
I can only see why an application would take that
over, and then that request would dutifully be passed
back up to the BIOS.

BFN. Paul.

[Rod Pemberton]

On Fri, 31 Dec 2021 10:05:31 -0800 (PST)

Post by ***@gmail.com
Another principle.
The BIOS layer, possibly in the C library, will by
default take responsibility for echoing characters
from the keyboard and displaying them on the
terminal. This is until the OS sets setvbuf
no-buffering to indicate it is taking over responsibility.
Although at this point in time I can't think of any
reason why the OS would take over responsibility.
I can only see why an application would take that
over, and then that request would dutifully be passed
back up to the BIOS.

Well, it depends on your OS design.

Your OS recreates DOS and DOS uses the BIOS.

My OS doesn't use the BIOS. My OS programs
the hardware directly. There is no layer below
that of the OS proper.


--

[[e-mail]]

Post by Rod Pemberton
Well, it depends on your OS design.
Your OS recreates DOS and DOS uses the BIOS.
My OS doesn't use the BIOS. My OS programs
the hardware directly. There is no layer below
that of the OS proper.

Your OS will read data from the disk in block mode, right?

Do you think that code should be put inside the C library,
e.g. PDPCLIB, and then the OS opens drives with
fopen("0x80", "r+b");
etc?

That becomes your defacto BIOS layer, or maybe we need
another name for it. Regardless, it deals with flat files, it
doesn't introduce a file system.

Then your OS can use the above file and impose a file
system on top of it. That's the OS proper.

Then even your OS can do fopen("config.sys", "r"); That
will go through quite different logic, that accesses your
OS routines that deal with the file system it introduced,
rather than the block reads of the physical hard disk.

Maybe you don't consider this to be layering though. And
maybe you think it is wrong to put that logic into the C
library? What I'm looking for, but don't expect, is
mathematical proof one way or the other. Or is this
considered to be art?

BFN. Paul.

[[e-mail]]

Another thing is that a hard disk, e.g. file :0x80,
can have multiple FAT partitions, which I will open
for direct access as "+C", "+D" etc.

I'll have an "offline +C" command to take a FAT
partition offline so that an application can issue
the fopen when direct access is required.

And an "eject :0x80" to take an entire device offline.

Or should I just have a single command work on
either file type?

BFN. Paul.