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

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

Re: MSDOS 3.2 COM ports

Show all headers | View raw

Muta,

> The first thing I'd like to know is if my program goes
> into a hard loop, with:
>
> for (;;) ;
>
> ie no input or output I/O to any device, is there a technical
> barrier on either 8086 or 80386 to allowing the hardware
> interrupt of ctrl-c being pressed aborting the application?

That fully depends on how you define "technical".   Using it that way and 
leaving your (and perhaps another) machine in an unstable state is what I 
would definitily call a technical barrier.

> Or at least letting the timer interrupt detect that ctrl-c has
> been pressed and waiting two more timer interrupts and
> then actioning the abort.

Sigh.  You do *NOT* leave it up to some random factor to force your program 
to abort whatever it is busy with.  Doing so is simply asking for trouble.

> You mentioned that you shouldn't be aborting a hard \
> disk write.

As an example, yes.   Same goes for your connection to that BBS of yours too 
though

> The OS will always be the one who initiates that.

No.  *Your program* initiates it.   It also holds the to-be-written data. 
Just imagine what happens when the OS-based disk-write routine is reading 
whatever you want to have written, and you just yank that buffer away from 
under it.

Have you ever heard about how a use-after-free is something that should 
/never/ happen ?  You would be opening up yourself to the same.   Bonus 
points if some other program allocates that same buffer space and overwrites 
it.

> Or alternatively, the OS will know whether it is in the
> middle of doing any OS work at all, or whether it is an
> application being run.

:-)  Now you are trying to offload the problem to an imaginary (future) 
(D)OS.    Thats not the way to go I'm afraid.    For one, further 
development of your client would need to stop until those OS features are 
available ...

> When doing a blocked read from a COM port (assuming
> such a BIOS call exists, which doesn't seem to be the
> case),

Actually, its the opposite.  Blocking calls are the default.  The 
non-blocking ones - or the ones that have a timeout - are, especially under 
BIOS / DOS, the exception of the rule.

You might not directly notice a COM port blocking I/O effect, but thats most 
likely either because most of todays UARTs have a (small) internal buffer, 
or your C{something} function-library is buffering it for you  (yes, your 
C{something} programming environment might actually already carry an 
interrupt-driven COM library).

But yes, there is a possibility that your C{something} based COM access will 
(be configured to) return immediatily - regardless of if all the data has 
been received or not.    And that ofcourse means that you (again) need to 
poll to get all the transmitted-to-you data ...

> And then finally moving on to the BBS - remembering
> that it is a cooperative BBS - the OS can be set to
> send the ctrl-c out the COM port as part of aborting
> the application.

:-)  You *say* you're "moving on to the BBS", but directly mock those words 
by only talking about something the OS your client is running on is supposed 
to be doing.

Also, how would that OS know that there is a serial connection active, or 
what exactly to say (and when!) to that BBS ?

No, you're fantasizing about OS capabilities I'm afraid.  *You* have to 
write it.    Either as part of your client, or as part of your future OS. 
I suggest you keep focussed on your client.

Regards,
Rudy Wieser

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