Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #3974

Re: MSDOS 3.2 COM ports

Show all headers | View raw

On Tuesday, April 27, 2021 at 7:40:22 PM UTC+10, R.Wieser wrote:

> > A long-running "grep -R" running within PDOS, forget 
> > about the BBS, would be considered to be using 
> > blocking I/O (on the disk, not the BBS), wouldn't it?

> Yes, and no. 
> 
> No : As mentioned, on your own *local* machine you can most always use 
> ctrl-c to abort (force-closing the program). 
> 
> Yes : As long as your program doesn't output anything you cannot stop it 
> (the ctrl-c checking is done inside (some of) the character output BIOS 
> INTs)

Wow. I didn't know that. I didn't actually believe it,
so I tried writing a program that just went into a
loop, and confirmed that I could ctrl-C out of it
on Windows (which screws up my keyboard
because it is left in ANSI terminal mode and
Windows doesn't fix that).

Then I ran the same program on MSDOS and it
didn't allow me to ctrl-c out of it.

I did one more test which was to run my Windows
program on MSDOS using HX under Freedos. It
also couldn't be aborted.

I thought all keyboard strokes resulted in an
interrupt?

Isn't it a simple matter of hooking into that interrupt
and doing the ctrl-c checking?

Note that I haven't implemented ctrl-c checking in
PDOS at all yet. Neither PDOS/86 nor PDOS/386,
not even on output.

I guess now is the time to find out what options are
available. :-)

> > Interrupting either the disk or the BBS is an independent 
> > activity, isn't it?

> And just ask yourself : Your BBS listens to your client-programs 
> communications and does whatever it says. How's that independant ?

ctrl-c checking is independent of the application
being run.

> > Are you talking about from an application programmer's 
> > perspective, a user's perspective, or something else?

> both (though for different, opposite reasons), and what else is there ?

Hardware design, C library design. Language design.

> >> But keep the downside of it in mind. 
> > 
> > Can you list those? It might be possible to 
> > overcome them.

> Whut ? What didn't you understand from what I already said : 
> 
> [quote=me, parent post]
> But as your client program is using blocking I/O you could be pressing keys 
> all you want, but those won't be send until after you got your response back 
> from the BBS ...
> [/quote] 

It was all based on a misunderstanding.

By "blocking mode" I thought you meant that the
application waited until data arrived instead of
going into a polling loop to check multiple devices
at the same time. I didn't know you meant
ctrl-c checking.

> Again: as long as you are in a blocking wait (for data to come in) *you 
> can't do anything else*. Your 'puter is effectivily frozen. How do you 
> think you can overcome that ? 

By getting the OS, even Freedos, to check the keyboard
every timer interrupt to see if there are any pending
characters? That won't work on an application that
disables interrupts, but I don't care about that, I only
care about normal programs that have a bug (or are
long-running) and go into a loop without printing
anything.

I wasn't aware that that wasn't already in place.

What's the technical barrier?

Thanks. Paul.

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 16:19 -0700
  Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 18:26 -0600
    Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 18:47 -0700
      Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 20:08 -0600
        Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 20:40 -0700
      Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 20:14 -0600
      Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-24 10:07 +0200
        Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-24 15:04 -0700
          Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-25 10:32 +0200
            Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 01:32 -0700
              Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-26 11:42 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 04:42 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-26 14:54 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 14:10 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-27 11:40 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-27 03:56 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-05-01 21:56 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-05-01 14:36 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-05-02 10:29 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-05-02 02:14 -0700
    Re: MSDOS 3.2 COM ports Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2021-04-28 14:15 +1000

csiph-web