terminals galore

17 views
Skip to first unread message

muta...@gmail.com

unread,
Jun 16, 2021, 12:44:19 AMJun 16
to
First imagine (in some cases, it is a reality), that the
following things exist as physical objects that may
have been there since 1990:

ASCII ANSI terminal
EBCDIC ANSI terminal
ASCII 3270 terminal
EBCDIC 3270 terminal
ASCII HTML terminal
EBCDIC HTML terminal

ASCII Telnet+ terminal
EBCDIC Telnet+ terminal

And I have emulators for all of the above, called
termansi.exe, term3270.exe, termhtml.exe and
termtel.exe. The terminal emulators are mainly
focused on running on PDOS/386.

The name Telnet+ may be confusing.

What I'm looking for is a magical terminal, that, when
given an appropriate control sequence, will switch
between any of the "big 3" terminal types above, ie
ANSI, 3270, HTML.

This way I can have one C program on PDOS/3X0 that
emits ANSI control characters, and another that emits
3270 control characters, and at the command prompt
I can issue some sort of command (tset?) that switches
between the terminal types dynamically.

But let's focus on EBCDIC ANSI first. That will be the
standard control sequence that any of my applications
emit.

Rather than burden the OS with the need to support
multiple application-generated control sequences, I
was thinking that what I need is a "terminal controller".

PDOS/3X0 will not speak directly (via CCW) to some
terminal calling via the internet, but will instead speak
to a termcont.exe running on my Windows machine,
which accepts e.g. a term3270 caller, and will translate
the application EBCDIC ANSI stream into an EBCDIC
3270 stream.

Even though my terminal controller will only accept
(somehow) one connection at a time, it will accept
different terminal types by if they use port 80 it is
assumed that they are ASCII HTML. Port 64000 is
assumed to be EBCDIC ANSI.

Most interesting to me at the moment is the EBCDIC
ANSI to ASCII HTML conversion.

If my PDOS/3X0 application does 3 printfs with newline,
I am expecting (my requirements at the moment)
fresh HTML pages to be generated. The first page will
have the <HTML> marker with just one line (with <br>
in it). The second page will be the same HTML marker
with 2 <br> etc. Now the bit that is outside my knowledge.
What is the simplest way, after having finished outputting
all HTML pages, to then turn around and request a single
character to be entered? I am happy to put out another
HTML page, perhaps this time with the "javascript"
keyword to solicit a function to input a key. I want all
keys to be able to be entered by the user, e.g. 'A' or
ctrl-a or cursor up. I don't care what HTML response
that generates, so long as it is standard. That HTML
response will be converted into EBCDIC ANSI by the
terminal controller, then fed back to PDOS/3X0, and
finally into some PDOS/3X0 application, and my eye
is on micro-emacs. In other words, I want to drive my
existing micro-emacs executable that produces
EBCDIC ANSI sequences, from a browser.

Is that possible or am I missing something?

Thanks. Paul.

Rod Pemberton

unread,
Jun 16, 2021, 1:59:50 AMJun 16
to
No idea.

All I know is that the most powerful terminal I ever
used was a VT220. Of course, that was pre-html.

VT220
-ANSI escape sequences
-international character sets
-define new character sets

https://en.wikipedia.org/wiki/VT220

--
What is hidden in the ground, when found, is hidden there again?

muta...@gmail.com

unread,
Jun 16, 2021, 2:22:39 AMJun 16
to
On Wednesday, June 16, 2021 at 3:59:50 PM UTC+10, Rod Pemberton wrote:

> All I know is that the most powerful terminal I ever
> used was a VT220. Of course, that was pre-html.
>
> VT220
> -ANSI escape sequences
> -international character sets
> -define new character sets

And would you consider HTML to be "just another
terminal like the VT220"?

Or is HTML considered to be a different paradigm?

It seems to me that life would be a whole lot simpler
if HTML was described in terms of just another
terminal type.

I think Unix has a termcap file - what if HTML were to
be added to that, if it wasn't already?

The internet has always seemed to be rather mysterious
to me. Introducing complications of MACing and other
things I have no knowledge of. But if you simply tell me
that a BBS can put out HTML instead of ANSI escape
sequences, well, that's no big deal. BBSes often gave the
user the choice of which terminal type they were using,
and ANSI was just one of several options. If HTML were
added to the Ten Minute Limit, no big deal.

BFN. Paul.

muta...@gmail.com

unread,
Jun 16, 2021, 2:54:22 AMJun 16
to
Maybe web browsers can be written to ignore a whole
lot of text after connection, and my BBS can be designed
so that if people start "typing" "GET ..." when I asked for
a number, I assume they are a dumb HTML terminal,
and switch to HTML mode.

BFN. Paul.

wolfgang kern

unread,
Jun 16, 2021, 6:54:42 AMJun 16
to
On 16.06.2021 08:22, muta...@gmail.com wrote:

> And would you consider HTML to be "just another
> terminal like the VT220"?
>
> Or is HTML considered to be a different paradigm?

It is NOT a terminal at all !
HTML is nothing else than a text-based script which
is interpreted by the receiving browser.
How it's transmitted is a complete other story.
__
wolfgang

muta...@gmail.com

unread,
Jun 16, 2021, 7:08:30 AMJun 16
to
On Wednesday, June 16, 2021 at 8:54:42 PM UTC+10, wolfgang kern wrote:

> > And would you consider HTML to be "just another
> > terminal like the VT220"?
> >
> > Or is HTML considered to be a different paradigm?

> It is NOT a terminal at all !
> HTML is nothing else than a text-based script which
> is interpreted by the receiving browser.

Is there any reason why sending a 3270 data stream
including Set Buffer Address etc to a 3270 terminal
is any different from sending an HTML data stream
including <HTML> and <br> to a theoretical HTML
terminal?

Are you saying that EBCDIC ANSI is illegitimate too?
ie sending x'27' [ 2 J etc in EBCDIC.

What's the technical definition of a "terminal"?

Thanks. Paul.

wolfgang kern

unread,
Jun 16, 2021, 9:56:54 AMJun 16
to
On 16.06.2021 13:08, muta...@gmail.com wrote:
> On Wednesday, June 16, 2021 at 8:54:42 PM UTC+10, wolfgang kern wrote:
>
>>> And would you consider HTML to be "just another
>>> terminal like the VT220"?
>>> Or is HTML considered to be a different paradigm?

>> It is NOT a terminal at all !
>> HTML is nothing else than a text-based script which
>> is interpreted by the receiving browser.

> Is there any reason why sending a 3270 data stream
> including Set Buffer Address etc to a 3270 terminal
> is any different from sending an HTML data stream
> including <HTML> and <br> to a theoretical HTML
> terminal?

see below.

> Are you saying that EBCDIC ANSI is illegitimate too?
> ie sending x'27' [ 2 J etc in EBCDIC.

> What's the technical definition of a "terminal"?

it means communication hardware, not a program nor a transfer protocol.

A device with a keyboard and/or screen is also called a terminal.

so a COM-port is hardware, following RS232 rules. this AT.. commands
control a phone modem and not the COM-port. A modem may use RS232.

LPT was hardware, (p2p bidirectional parallel, null-modem etc).
TTY was hardware, (phone-line) used (ASCII) transfer protocol.
IBM terminal connectors were hardware, used EBCD protocol.

HTML and JAVA are just text based scripts,

internet uses its own transfer protocol [query| etc.]

ANSI ESC codes belong to protocols [used in printers/codecs/modems]
and got nothing to do with the hardware where they may be used on.

you mix definitions because you don't know the difference.
__
wolfgang

James Harris

unread,
Jun 16, 2021, 1:32:43 PMJun 16
to
On 16/06/2021 07:22, muta...@gmail.com wrote:
> On Wednesday, June 16, 2021 at 3:59:50 PM UTC+10, Rod Pemberton wrote:
>
>> All I know is that the most powerful terminal I ever
>> used was a VT220. Of course, that was pre-html.
>>
>> VT220
>> -ANSI escape sequences
>> -international character sets
>> -define new character sets
>
> And would you consider HTML to be "just another
> terminal like the VT220"?
>
> Or is HTML considered to be a different paradigm?
>
> It seems to me that life would be a whole lot simpler
> if HTML was described in terms of just another
> terminal type.

Maybe it's not a terminal type. The OSI communications model recognised
the need for a presentation layer below applications. The Wikipedia page
about it

https://en.wikipedia.org/wiki/Presentation_layer

gives examples of EBCDIC-to-ASCII and text to XML. I don't see why HTML
and terminal types could not be included.

>
> I think Unix has a termcap file - what if HTML were to
> be added to that, if it wasn't already?
>
> The internet has always seemed to be rather mysterious
> to me. Introducing complications of MACing and other
> things I have no knowledge of. But if you simply tell me
> that a BBS can put out HTML instead of ANSI escape
> sequences, well, that's no big deal. BBSes often gave the
> user the choice of which terminal type they were using,
> and ANSI was just one of several options. If HTML were
> added to the Ten Minute Limit, no big deal.

AISI the idea of a presentation layer is a broader concept than just
terminal conversions. If it were to be implemented successfully then
applications would have to deal only with the logic of programs and
communicate in terms of objects, with the presentation layer translating
them for input and output.


--
James Harris

Rod Pemberton

unread,
Jun 16, 2021, 1:46:45 PMJun 16
to
On Tue, 15 Jun 2021 23:22:38 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Wednesday, June 16, 2021 at 3:59:50 PM UTC+10, Rod Pemberton wrote:
>
> > All I know is that the most powerful terminal I ever
> > used was a VT220. Of course, that was pre-html.
> >
> > VT220
> > -ANSI escape sequences
> > -international character sets
> > -define new character sets
>
> And would you consider HTML to be "just another
> terminal like the VT220"?
>

No. I'd consider it to be a layer or protocol
like ANSI escape sequences.

> Or is HTML considered to be a different paradigm?

The point was that, if an ancient terminal can handle
ANSI escape sequences, then a modern terminal could in
theory do html or postscript, or perhaps a sufficiently
useful limited subset of them.

Grant Taylor

unread,
Jun 16, 2021, 2:53:32 PMJun 16
to
On 6/16/21 5:08 AM, muta...@gmail.com wrote:
> Is there any reason why sending a 3270 data stream including Set Buffer
> Address etc to a 3270 terminal is any different from sending an HTML
> data stream including <HTML> and <br> to a theoretical HTML terminal?

There's a reason that I made the comparison between 3270 data stream and
HTML forms.

- Both are generated server side
- Both are submitted back to the server in one transaction
- Both are rendered client side
- Both have declarative security parameters
- Both can have said declarative security parameters ignored



--
Grant. . . .
unix || die

Grant Taylor

unread,
Jun 16, 2021, 2:55:47 PMJun 16
to
On 6/16/21 7:51 AM, wolfgang kern wrote:
> you mix definitions because you don't know the difference.

I don't mind taking a step back and asking the proverbial "why",
particularly why something was done the way that it was, or more
importantly why it was not done some other way.

But to be able to have a worthwhile conversation of such, one needs to
have a good working understanding of things to be able to serve as a
foundation for such a conversation.

muta...@gmail.com

unread,
Jun 17, 2021, 9:38:34 AMJun 17
to
On Wednesday, June 16, 2021 at 2:44:19 PM UTC+10, muta...@gmail.com wrote:

> What is the simplest way, after having finished outputting
> all HTML pages, to then turn around and request a single
> character to be entered? I am happy to put out another
> HTML page, perhaps this time with the "javascript"
> keyword to solicit a function to input a key. I want all
> keys to be able to be entered by the user, e.g. 'A' or
> ctrl-a or cursor up. I don't care what HTML response
> that generates, so long as it is standard. That HTML

I think the way that web pages work is that for each
printf() I need an extra line added to my internal buffer,
and the HTML sent with a <script language="javascript">
and then java will request for the same page to be
reloaded, giving control back to my HTML BBS.

Then when my BBS has finished doing printfs and is
doing a getc(), it needs to send the same, now-complete
HTML page, with a different javascript script which
first solicits a keystroke then does a "post" instead of
a "get", and then I'm not sure what happens, maybe
another "get".

BFN. Paul.
Reply all
Reply to author
Forward
0 new messages