Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"May the forces of evil become confused on the way to your house." -- George Carlin


devel / comp.os.msdos.programmer / Re: MSDOS 3.2 COM ports

SubjectAuthor
* Re: MSDOS 3.2 COM portsR.Wieser
`* Re: MSDOS 3.2 COM portsmuta...@gmail.com
 `* Re: MSDOS 3.2 COM portsR.Wieser
  `* Re: MSDOS 3.2 COM portsmuta...@gmail.com
   `* Re: MSDOS 3.2 COM portsR.Wieser
    `- Re: MSDOS 3.2 COM portsmuta...@gmail.com

1
Re: MSDOS 3.2 COM ports

<s68m63$o6s$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9919&group=comp.os.msdos.programmer#9919

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: MSDOS 3.2 COM ports
Date: Tue, 27 Apr 2021 11:40:07 +0200
Organization: Aioe.org NNTP Server
Lines: 80
Message-ID: <s68m63$o6s$1@gioia.aioe.org>
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com> <s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com> <s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com> <s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com> <s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com> <s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-Priority: 3
X-Notice: Filtered by postfilter v. 0.9.2
X-MSMail-Priority: Normal
 by: R.Wieser - Tue, 27 Apr 2021 09:40 UTC

Muta,

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

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

And I'm not even going to try to answer this. You're throwing apples and
eggs together and expect a single explanation.

What happens on your local machine is one thing.
Your (client programs) communication with a server (the BBS) is another
How the server (your BBS) responds to your clients communication is a third.

Don't throw them all on a heap. You're just end up confusing
yourself.(and me for that matter)

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

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

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

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 ?

Remark: if you can find a "wait for data *but use a time-out*" method you
can mitigate /some/ of it - even though the user will still have the
"pleasure" of experiencing freeze-stutter. Not funny when you try to use
the keyboard...

> I guess it depends on what we're trying to achieve.
>
> What would be a sensible achievement in your eyes?

And as far as I'm concerned ? Anything. As long as you learn from it it
doesn't even matter if you can / will actually finish the program. IOW,
I consider the road traveled more important that arriving at the
destination.

So yes, you can definitily create a client that uses blocking I/O to talk
with a BBS. No doubt about it. And it will work well too. It just has
a certain behaviour not everyone might like ...

> BTW, I started this project in 1994.

I got my first PC a few years later : a 286 with turbo button (8 -> 12 MHz)
:-)

Regards,
Rudy Wieser

Re: MSDOS 3.2 COM ports

<beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9920&group=comp.os.msdos.programmer#9920

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a37:bcc:: with SMTP id 195mr10356317qkl.329.1619520998624;
Tue, 27 Apr 2021 03:56:38 -0700 (PDT)
X-Received: by 2002:ac8:5a46:: with SMTP id o6mr21145905qta.289.1619520998438;
Tue, 27 Apr 2021 03:56:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Tue, 27 Apr 2021 03:56:38 -0700 (PDT)
In-Reply-To: <s68m63$o6s$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com>
<s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com>
<s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com>
<s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com>
<s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com>
<s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com>
<s68m63$o6s$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com>
Subject: Re: MSDOS 3.2 COM ports
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Tue, 27 Apr 2021 10:56:38 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Tue, 27 Apr 2021 10:56 UTC

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.

Re: MSDOS 3.2 COM ports

<s6kfg6$9ko$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9940&group=comp.os.msdos.programmer#9940

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: MSDOS 3.2 COM ports
Date: Sat, 1 May 2021 21:56:44 +0200
Organization: Aioe.org NNTP Server
Lines: 38
Message-ID: <s6kfg6$9ko$1@gioia.aioe.org>
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com> <s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com> <s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com> <s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com> <s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com> <s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com> <s68m63$o6s$1@gioia.aioe.org> <beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-MSMail-Priority: Normal
X-RFC2646: Format=Flowed; Original
X-Notice: Filtered by postfilter v. 0.9.2
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
 by: R.Wieser - Sat, 1 May 2021 19:56 UTC

Muta,

> I thought all keyboard strokes resulted in
> an interrupt?

Yeah, they do. A *hardware* one. Which dumps the keystroke into a small
buffer which you than read from with a few of the BIOS INTs.

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

Yeah, thats a good idea : you just, somewhere in the middle of whatever your
'puter is busy with - even harddisk writing ! - hard-abort it. Nope, I
would not suggest doing that.

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

I don't think you understood the question ...

> What's the technical barrier?

I already mentioned that : while you can just have your client program
crash-and-burn by pressing ctrl-c, it won't stop the server (the BBS) from
continuing what its busy with.

IOW, you need to figure out a "soft" method to stop whatever your client is
doing (*not* aborting the program or interrupting it in the middle of
something important), and than *ask* the server to stop what it busy with -
'cause thats the only thing you can do : ask..

Regards,
Rudy Wieser

Re: MSDOS 3.2 COM ports

<39e49d77-c97f-4e9d-bff6-5a891036c271n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9942&group=comp.os.msdos.programmer#9942

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a37:8b86:: with SMTP id n128mr11725792qkd.151.1619904965574;
Sat, 01 May 2021 14:36:05 -0700 (PDT)
X-Received: by 2002:ae9:e201:: with SMTP id c1mr4773509qkc.493.1619904965382;
Sat, 01 May 2021 14:36:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sat, 1 May 2021 14:36:05 -0700 (PDT)
In-Reply-To: <s6kfg6$9ko$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com>
<s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com>
<s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com>
<s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com>
<s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com>
<s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com>
<s68m63$o6s$1@gioia.aioe.org> <beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com>
<s6kfg6$9ko$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <39e49d77-c97f-4e9d-bff6-5a891036c271n@googlegroups.com>
Subject: Re: MSDOS 3.2 COM ports
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sat, 01 May 2021 21:36:05 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Sat, 1 May 2021 21:36 UTC

On Sunday, May 2, 2021 at 6:59:59 AM UTC+10, R.Wieser wrote:

> > I thought all keyboard strokes resulted in
> > an interrupt?

> Yeah, they do. A *hardware* one. Which dumps the keystroke into a small
> buffer which you than read from with a few of the BIOS INTs.

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

> Yeah, thats a good idea : you just, somewhere in the middle of whatever your
> 'puter is busy with - even harddisk writing ! - hard-abort it. Nope, I
> would not suggest doing that.

Ok, great! Now I'm learning something.

> I already mentioned that : while you can just have your client program
> crash-and-burn by pressing ctrl-c, it won't stop the server (the BBS) from
> continuing what its busy with.
>
> IOW, you need to figure out a "soft" method to stop whatever your client is
> doing (*not* aborting the program or interrupting it in the middle of
> something important), and than *ask* the server to stop what it busy with -
> 'cause thats the only thing you can do : ask..

Ok, let's do one thing at a time.

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?

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.

You mentioned that you shouldn't be aborting a hard disk
write. The OS will always be the one who initiates that. So
the OS can mark that operation as "do not interrupt until
complete".

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. If it is in application code, then it can be safely
aborted. OS work should not be aborted, at least by default.

When doing a blocked read from a COM port (assuming
such a BIOS call exists, which doesn't seem to be the
case), the specific BIOS call to read from a COM port
could be marked as interruptable, meaning whenever
a ctrl-c comes in, the OS can forget about the COM port
read and abort the application that ultimately requested
the operation in the first place. The OS can have further
knowledge that that interruptable operation needs to be
followed up with a reset of the COM port if required.

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.

Would that work?

Thanks. Paul.

Re: MSDOS 3.2 COM ports

<s6lnsn$1c3q$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9944&group=comp.os.msdos.programmer#9944

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: MSDOS 3.2 COM ports
Date: Sun, 2 May 2021 10:29:00 +0200
Organization: Aioe.org NNTP Server
Lines: 88
Message-ID: <s6lnsn$1c3q$1@gioia.aioe.org>
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com> <s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com> <s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com> <s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com> <s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com> <s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com> <s68m63$o6s$1@gioia.aioe.org> <beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com> <s6kfg6$9ko$1@gioia.aioe.org> <39e49d77-c97f-4e9d-bff6-5a891036c271n@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-Priority: 3
X-RFC2646: Format=Flowed; Original
X-Notice: Filtered by postfilter v. 0.9.2
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
 by: R.Wieser - Sun, 2 May 2021 08:29 UTC

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

Re: MSDOS 3.2 COM ports

<623655be-e243-4e61-9512-263bd6542fe7n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9945&group=comp.os.msdos.programmer#9945

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a05:620a:40ce:: with SMTP id g14mr13448830qko.190.1619946852320; Sun, 02 May 2021 02:14:12 -0700 (PDT)
X-Received: by 2002:ac8:1098:: with SMTP id a24mr11348450qtj.291.1619946852133; Sun, 02 May 2021 02:14:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sun, 2 May 2021 02:14:11 -0700 (PDT)
In-Reply-To: <s6lnsn$1c3q$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <4d505ede-ceb0-4556-9255-5533c987e91fn@googlegroups.com> <s5vomk$41j$1@tncsrv09.home.tnetconsulting.net> <db363ce1-051e-4663-b2cb-e64a81a5d91bn@googlegroups.com> <s60jkf$11j5$1@gioia.aioe.org> <80bdb037-707d-4eac-b5f6-050f3d775761n@googlegroups.com> <s639fu$ag9$1@gioia.aioe.org> <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com> <s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com> <s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com> <s68m63$o6s$1@gioia.aioe.org> <beaf99c6-6e20-4e1c-95fe-7dbaff34d2ebn@googlegroups.com> <s6kfg6$9ko$1@gioia.aioe.org> <39e49d77-c97f-4e9d-bff6-5a891036c271n@googlegroups.com> <s6lnsn$1c3q$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <623655be-e243-4e61-9512-263bd6542fe7n@googlegroups.com>
Subject: Re: MSDOS 3.2 COM ports
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sun, 02 May 2021 09:14:12 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 208
 by: muta...@gmail.com - Sun, 2 May 2021 09:14 UTC

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.


devel / comp.os.msdos.programmer / Re: MSDOS 3.2 COM ports

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor