On Friday, December 10, 2021 at 3:14:51 AM UTC+11, R.Wieser wrote:
> You're confusing me. You posted three requirements in your first post,
> and provided that last link to a call which would satisfy all of that. But
> for some reason that is not at all clear to me you are rejecting it.
> Why ? What *doesn't* it do that you need to have happening ?
I am the author of a C library (PDPCLIB) and an OS (PDOS).
Whichever function I choose is intended to go into both of
those, not just an arbitrary application doing DOS calls. I
don't want applications doing DOS calls, I want applications
doing C90 calls, and for my C library and OS to work nicely.
My C library is currently centered around calls to
open/read/write/seek/close. It is thus easier if the
behavior of the read call changes when the calling
program needs immediate, unechoed characters,
My main interest is using PDOS to develop PDOS or some
superior OS. For that you need a compiler, linker and editor.
The compiler and linker are straightforward line-buffered
C90-compliant programs (gcc and ld).
The editor (micro-emacs) has the ability to use ANSI
control characters, so is also basically C90-compliant.
Note that PDPCLIB doesn't provide any extensions to
C90. I posted here recently regarding ANSI because of
micro-emacs expects to receive characters without echo,
and ctrl-c is one of the characters it uses too. There is
nothing formal in C90 that says you can have such a
setup. However, I have basically decided that an explicit
setvbuf of "no buffering" for stdin implies that you are
getting characters as per the above.
Now in response to the setvbuf I have the option of either
setting handle 0 to raw mode, or setting a flag to say to
stop doing reads of the handle and instead call a new
function to read a single character.
My OS supports both MSDOS and Win32 API calls, so
setting the flag would make MSDOS work. But Win32
does the equivalent of setting the stream to raw mode,
as the only available interface, so I can't make my C
library bypass that paradigm. So my C library, and the
OS, will be more consistent if I can have the same
paradigm used for both MSDOS and Win32.
> Also, you've just responed to my suggestion to read just a single char at a
> time instead of a full buffers worth with a "yes". As if it was a question
> and you where already doing that. Which again doesn't make much sense.
I started writing my C library in 1994, and it's very large, and I'm
not intimately familiar with it, but I believe that if micro-emacs
does a getc(stdin) (which is what I believe it does), and there is
nothing in the FILE buffer, it will do a direct OS read of just one
character. If it doesn't already do that, I will need to make it do
that, because MSDOS doesn't seem to support "fill this buffer
with whatever you've got", which I think (ie I'm not sure) Win32