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

On Sunday, May 2, 2021 at 6:29:13 PM UTC+10, R.Wieser wrote:

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

The current alternative is to hang the PC requiring a reboot.

ie that is how Freedos is currently behaving.

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

I'm trying to improve on Freedos/MSDOS, not solve
all the world's problems in one release.

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

BBSes are quite used to remotes dropping carrier.

My BBS in particular, running on Windows, will be
designed around the fact that the caller is primitive.

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

Not sure what you're talking about here. That's
exactly what ctrl-c means, isn't 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.

Not sure what the issue is here either. The application
will be dead. That's the whole point of ctrl-c.

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

I'm not sure if we're talking cross-purposes or what.

Here is my project:

http://pdos.sourceforge.net/

I have a 16-bit and 32-bit version of MSDOS. And 32-bit
Windows too. And the mainframe hardware as well. This
isn't future, it's current.

I also have my own C library for both of the above
environments. And many more environments too.

I've been working on it off and on for more than
25 years.

I provide my own version of GCC 3.2.3 to target all
of those platforms.

I don't control the BIOS, except, sort of, in 32-bit mode.

I don't control the hardware either, except, sort of, on
the mainframe.

Other than that, every byte of code that is executed
when you boot PDOS, on either 8086 or 80386, is
part of my project. At least if you boot from floppy.
Booting from hard disk uses an MBR put in by
someone else. I have a public domain MBR (not
written by me) standing by though.

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

All I know is that under Freedos I tried to do a read from
COM1 and it returned immediately with a timeout and
I had to put my application into a loop for me to get
any data. Here is the code that I used:

static int testBosSerialReadChar(void)
{ unsigned int x;

while (1)
{
x = BosSerialReadChar(0);
if ((x & 0x8000U) == 0)
{
printf("%c", (x & 0xff));
fflush(stdout);
}
}
printf("received %x\n", x);
return (0);
}

That BiosSerialReadChar() function is my own, which
you can see here:

/* BosSerialReadChar BIOS Int 14h Function 02h */

unsigned int BosSerialReadChar(unsigned int port)
{ union REGS regsin;
union REGS regsout;

regsin.h.ah = 0x02;
regsin.h.al = 0;
regsin.x.dx = port;

int86(0x14 + BIOS_INT_OFFSET, &regsin, &regsout);
return (regsout.x.ax);
}

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

Not unless I write it myself. I didn't.

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

The BIOS does.

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

I don't understand.

> Also, how would that OS know that there is a serial connection active, or

Because it would have been fopen'ed as "COM1".

> what exactly to say (and when!) to that BBS ?

The BBS and the OS will have an agreed protocol
that allows the OS to do a blocked read and the
BBS is expecting that and will coddle the OS (PDOS).

> No, you're fantasizing about OS capabilities I'm afraid.

It's not a fantasy. I'm trying to add it to existing PDOS.

> *You* have to write it.

Yes, of course. That's what I'm doing right now. Adding
ctrl-c handling after understanding why Freedos and
MSDOS don't do this already and require the user to
reboot the machine, when both keyboard and timer
interrupts are available to the OS, even in 8086 mode.

> Either as part of your client, or as part of your future OS.
> I suggest you keep focussed on your client.

They are all growing together, and have been doing so
for over 25 years. Just today I made changes to both
the C library and the OS, as I found issues in both.
This is not abnormal. It's a near-daily occurrence.

It is the BBS that is the future, and the comms program
that is sort of in the future. I'm just going through the
motions of understanding what is required to support
that so that I don't paint myself into a corner in either
PDPCLIB or PDOS.

BFN. Paul.