ioctl

[muta...@gmail.com]

I have a need for stdin to do the following:

1. OS should return immediately with data instead
of waiting for "enter" to be pressed.

2. OS should not echo characters.

3. OS should not detect ctrl-C

I only have a need for those to be all on, or all off.
I don't need control over the individual behavior.

I have just been made aware of these interrupts:

http://www.ctyme.com/intr/rb-2820.htm
http://www.ctyme.com/intr/rb-2821.htm

Would I be correct in assuming that this bit:

5 raw (binary) mode

switches them all on or all off?

If not, any suggestions? The only alternative I know
of is to use this instead:

http://www.ctyme.com/intr/rb-2560.htm

Thanks. Paul.

[R.Wieser]

Muta (paul),

> I have just been made aware of these interrupts:
>
> http://www.ctyme.com/intr/rb-2820.htm
> http://www.ctyme.com/intr/rb-2821.htm
>
> Would I be correct in assuming that this bit:
>
> 5 raw (binary) mode
>
> switches them all on or all off?

Quite likely (depends on the driver receiving the request). But that
influences *all* communication with that particular device *even after you
close the program changing that flag*. IOW, don't do it.

> If not, any suggestions? The only alternative I know
> of is to use this instead:
>
> http://www.ctyme.com/intr/rb-2560.htm

Thats the one you will still need to use, unless 4402 will actually return
an entered key (never used it, so I'm not sure). Its also the simpelest
one to use,

And as you do not want the input to be buffered (only returned after the
"enter" key is pressed) you will have to handle the backspace and any other
"undesirable" (control) characters yourself ...

Regards,
Rudy Wieser

[muta...@gmail.com]

On Tuesday, December 7, 2021 at 8:39:53 PM UTC+11, R.Wieser wrote:

> Quite likely (depends on the driver receiving the request). But that
> influences *all* communication with that particular device *even after you
> close the program changing that flag*. IOW, don't do it.

That just means that it is my responsibility to put the
device back to the way I found it.

> > If not, any suggestions? The only alternative I know
> > of is to use this instead:
> >
> > http://www.ctyme.com/intr/rb-2560.htm

> Thats the one you will still need to use, unless 4402 will actually return
> an entered key (never used it, so I'm not sure). Its also the simpelest
> one to use,

In my case it's not the simplest to use, because I also
support a subset of the Win32 API, so I need to be able
to handle SetConsoleMode and have it do something
sensible in DOS terms.

Also, it's not 4402 that I call, it's the normal read (3F).

> And as you do not want the input to be buffered (only returned after the
> "enter" key is pressed) you will have to handle the backspace and any other
> "undesirable" (control) characters yourself ...

Sure.

Anyway, I ran the following test:

static int testReadFile(void)
{
char buf[10];
size_t readbytes;
unsigned int devinfo = 0;
unsigned int olddi;

PosGetDeviceInformation(0, &devinfo);
printf("devinfo is %x\n", devinfo);
devinfo &= 0xff;
olddi = devinfo;
devinfo |= 1 << 5;
PosSetDeviceInformation(0, devinfo);
PosReadFile(0, buf, sizeof buf, &readbytes);
printf("char is %x\n", buf[0]);
PosSetDeviceInformation(0, olddi);

return 0;
}

and it is working as more-or-less desired - not echoing the
characters and not waiting for enter. However, it does wait
for the full buffer to be entered instead of returning on the
first available keystroke. But I can live with that.

BFN. Paul.

[R.Wieser]

Muta (Paul),

> That just means that it is my responsibility to put the
> device back to the way I found it.

Yep.

Its just thats its my stance that if you do any such switching on a
program-temporary basis and you have another option you should take that
other option. But, YMMV.

And although you're on DOS, there might come a case where you have other
(TSR?) software running which expects the device in its normal
configuration.

> Also, it's not 4402 that I call, it's the normal read (3F).

Ah yes, ofcourse.

> However, it does wait for the full buffer to be entered instead
> of returning on the first available keystroke. But I can live with that.

Set the # of to-be-retrieved chars to One ?

Any reason why you do not want to use that (simpler, redirectable) Int 21h,
AH=07h method ?

Regards,
Rudy Wieser

[muta...@gmail.com]

On Thursday, December 9, 2021 at 8:14:36 PM UTC+11, R.Wieser wrote:

> Set the # of to-be-retrieved chars to One ?

Yes.

> Any reason why you do not want to use that (simpler, redirectable) Int 21h,
> AH=07h method ?

PDOS/386 supports both MSDOS-like executables using Pos*
wrappers, and also some of the Win32 API.

One of the Win32 functions I need to work is SetConsoleMode
which switches off echo and switches off line mode. I need this
to work so that micro-emacs will work using getc(stdin).

SetConsoleMode is defined in kernel32.dll and I need to make
it do something in Pos* terms. I could have a variable in
kernel32.dll to remember what mode I am in, and then whenever
a read is done, reference that variable and switch to the
single char function. But I don't think that is as neat as just
having PosReadFile in the OS figure things out.

BFN. Paul.

[R.Wieser]

Muta (Paul).

> SetConsoleMode is defined in kernel32.dll and I need to make
> it do something in Pos* terms. I could have a variable in
> kernel32.dll to remember what mode I am in, and then whenever
> a read is done, reference that variable and switch to the
> single char function. But I don't think that is as neat as just
> having PosReadFile in the OS figure things out.

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 ?

Also, you have mentioned that you want to "switch to the single char
function", but have not made clear in any way if that is something that that
micro-emacs is supposed to be able to do itself, or if its just intended as
a wrapper around that program (switching on before, switching off after).

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.

IOW, due confusing and conflicting information I don't think I can currently
can't help you. Sorry.

Regards,
Rudy Wieser

[muta...@gmail.com]

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,
including ctrl-c.

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
this application.

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
does.

BFN. Paul.