BEL

[Grant Taylor]

What is the logic behind this functionality? Bells have nothing
to do with display. Meaning stdout is not a display stream.

Teletypes, a descendant of typewriters, /did/ have a physical bell on them.

The bell was used to get someone's attention for one reason or another.

[[e-mail]]

Post by Grant Taylor

What is the logic behind this functionality? Bells have nothing
to do with display. Meaning stdout is not a display stream.

Teletypes, a descendant of typewriters, /did/ have a physical bell on them.
The bell was used to get someone's attention for one reason or another.

And if I had designed a teletype in the same era that had a
coffee maker attached, would the designers of ASCII have
reserved a control character to switch it on?

It's not to get someone's attention, it's to keep them awake.
A similar principle. What is the principle of the data stream
that is sent to a terminal?

BFN. Paul.

[Frank Kotler]

Post by ***@gmail.com

Post by Grant Taylor

What is the logic behind this functionality? Bells have nothing
to do with display. Meaning stdout is not a display stream.

Teletypes, a descendant of typewriters, /did/ have a physical bell on them.
The bell was used to get someone's attention for one reason or another.

And if I had designed a teletype in the same era that had a
coffee maker attached, would the designers of ASCII have
reserved a control character to switch it on?

We don't know.

Best,
Frank

[[e-mail]]

Post by Frank Kotler

Post by ***@gmail.com
And if I had designed a teletype in the same era that had a
coffee maker attached, would the designers of ASCII have
reserved a control character to switch it on?

We don't know.

You don't need to take my question so literally.

If YOU were designing ASCII back in 1960 or whenever, and
a teletype existed that had a coffee machine, would YOU have
reserved a control character (or sequence, like the ANSI
escapes) to switch it on?

What makes sense to put in a stream?

BFN. Paul.

[wolfgang kern]

Post by ***@gmail.com

Post by Frank Kotler

Post by ***@gmail.com
And if I had designed a teletype in the same era that had a
coffee maker attached, would the designers of ASCII have
reserved a control character to switch it on?

We don't know.

You don't need to take my question so literally.
If YOU were designing ASCII back in 1960 or whenever, and
a teletype existed that had a coffee machine, would YOU have
reserved a control character (or sequence, like the ANSI
escapes) to switch it on?
What makes sense to put in a stream?

there actually were Tele-Type codes (taken over by ASCII later on)
defined DC1..DC4 as special purpose because they were rare used for
communication controls.
I remember that some folks connected their TTY-receiver to household
equipment to turn on heat or light or remote open the garage door by
using a sequence of BELL and various DC for such.
This gimmicks didn't last very long because good friends often played
silly games and made the story pretty unsafe.

I still use code 07 for error beep, but ignore it on incoming strings.
__
wolfgang

[Frank Kotler]

On 12/05/2021 01:23 AM, ***@gmail.com wrote:
...

Post by ***@gmail.com
If YOU were designing ASCII back in 1960 or whenever, and
a teletype existed that had a coffee machine, would YOU have
reserved a control character (or sequence, like the ANSI
escapes) to switch it on?

Quite possibly, yeah. I don't have a coffee machine attached. They did
have a bell...

Best,
Frank

[[e-mail]]

On a serious note, the 64, 128 or 256 characters etc in an early
character set was rather limiting. As such, I'd only place things in
the character set which were actually needed for something useful. At
the time, bells were useful. While the argument over whether coffee
is more useful than a bell would have merit with a coffee drinker, I'm
not a coffee drinker.

1. My point is more "bells have nothing to do with displays,
and I have previously been under the impression that stdout
was for the display, not the audio system".

2. The "activate coffee machine doesn't necessarily have to be
a single control character, because of the limited room. It could
have been an ANSI escape sequence. Given that we're apparently
piling everything including the kitchen sink into stdout, why not
the coffee machine activation sequence too?

Apparently, as others noted you never used a typewriter (annoying
pieces of ....), nor a teletype (me neither), nor have you ever seen a
ticker tape (me neither).

I learnt touch-typing on a manual typewriter in about 1981-82.
I was allowed to quit the course when it started delving into
secretarial markup instructions.

No, that would be "play Metallica - Fade to Black" here.

I just listened to it, but didn't resonate with me.

BFN. Paul.

[wolfgang kern]

On 06/12/2021 23:42, ***@gmail.com wrote:
...

Post by ***@gmail.com
1. My point is more "bells have nothing to do with displays,
and I have previously been under the impression that stdout
was for the display, not the audio system".

stdout was/is for the console which implies a buzzer, which can be a
tiny speaker [connected to an I/O port apart from audio system].

Post by ***@gmail.com
2. The "activate coffee machine doesn't necessarily have to be
a single control character, because of the limited room. It could
have been an ANSI escape sequence. Given that we're apparently
piling everything including the kitchen sink into stdout, why not
the coffee machine activation sequence too?

it was done that way back then. you may not find much documents on the
net because tty existed long before www. But Ann&Lynn at comp.folklore
could answer your questions about old stuff in deep detail.
__
wolfgang

[[e-mail]]

Post by wolfgang kern

Post by ***@gmail.com
2. The "activate coffee machine doesn't necessarily have to be
a single control character, because of the limited room. It could
have been an ANSI escape sequence. Given that we're apparently
piling everything including the kitchen sink into stdout, why not
the coffee machine activation sequence too?

it was done that way back then. you may not find much documents on the
net because tty existed long before www. But Ann&Lynn at comp.folklore
could answer your questions about old stuff in deep detail.

I'm more interested in what makes sense in retrospect,
if we are doing Life on Earth v2, than the logic used back
then. But if there was a valid reason back then, that is fine.

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com

Post by wolfgang kern

Post by ***@gmail.com
2. The "activate coffee machine doesn't necessarily have to be
a single control character, because of the limited room. It could
have been an ANSI escape sequence. Given that we're apparently
piling everything including the kitchen sink into stdout, why not
the coffee machine activation sequence too?

it was done that way back then. you may not find much documents on the
net because tty existed long before www. But Ann&Lynn at comp.folklore
could answer your questions about old stuff in deep detail.

I'm more interested in what makes sense in retrospect,

If that were the case, you'd dump MSDOS in a skinny minute.

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
I'm more interested in what makes sense in retrospect,

If that were the case, you'd dump MSDOS in a skinny minute.

The core of MSDOS is Unix-like handles and open/read/write/close.

It's designed to work in small amounts of RAM.

What specifically was wrong with it when 2.0 was released in 1983?

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com

Post by Scott Lurndal

Post by ***@gmail.com
I'm more interested in what makes sense in retrospect,

If that were the case, you'd dump MSDOS in a skinny minute.

The core of MSDOS is Unix-like handles and open/read/write/close.
It's designed to work in small amounts of RAM.
What specifically was wrong with it when 2.0 was released in 1983?

It was already 20 years behind the state of the art in 1983.

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

It was already 20 years behind the state of the art in 1983.

In what way?

Thanks. Paul.

[Scott Lurndal]

Post by ***@gmail.com

Post by Scott Lurndal

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

It was already 20 years behind the state of the art in 1983.

In what way?

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

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com

Post by Scott Lurndal

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

It was already 20 years behind the state of the art in 1983.

In what way?

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

From your link:

Ken Thompson, in a transcribed 2007 interview with Peter Seibel[29] refers to Multics as "overdesigned and overbuilt and over everything. It was close to unusable. They [Massachusetts Institute of Technology] still claim it's a monstrous success, but it just clearly wasn't". On the influence of Multics on Unix, Thompson stated that "the things that I liked enough (about Multics) to actually take were the hierarchical file system and the shell — a separate process that you can replace with some other process".


And as I said - I'm mainly interested in MSDOS from a
programming point of view.

Hell, I'm mainly interested in a specific C90 point of view,
and that pretty much makes all systems interchangeable.

BFN. Paul.

[Grant Taylor]

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

Did (MS|PC)-DOS 2.x support hard drives? If it did, did it support file
systems larger than 32 MB? (I don't remember when the features were added.)

I know that the underlying features required for networking and CD-ROM
support (which abuses the networking feature) were added in DOS 3.x.
Hence why you see DOS 3.x as the minimum requirement on a lot of things.

[[e-mail]]

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

Did (MS|PC)-DOS 2.x support hard drives? If it did, did it support file
systems larger than 32 MB? (I don't remember when the features were added.)

I am interested from the programming perspective.
MSDOS 2.0 supports open/read/write/seek/close
calls which can be used for hard disks up to 2 GiB,
even if there were underlying problems with the FAT
filesystem implementation that prevented large drives
from being used.

That's very close to everything you need to write portable
programs.

You can almost say it's just another flavor of Unix.

BFN. Paul.

[Grant Taylor]

Post by ***@gmail.com
You can almost say it's just another flavor of Unix.

Hardly.

[Rod Pemberton]

On Sun, 12 Dec 2021 11:34:02 -0700

Post by Grant Taylor

Post by ***@gmail.com
What specifically was wrong with it when 2.0 was released in 1983?

Did (MS|PC)-DOS 2.x support hard drives?

My notes say that MS-DOS 2.00 is the first version that supported hard
disks.

Post by Grant Taylor
If it did, did it support file systems larger than 32 MB?
(I don't remember when the features were added.)

In general, I don't information on the capacity of hard disks by MS-DOS
version. Usually, you can find a list of capacities by FAT type.

My notes say FAT12 was MS-DOS 1.00, FAT 16 was MS-DOS 3.00, and up to
2GB FAT 16 (primary partition) was MS-DOS 4.00.

Post by Grant Taylor
I know that the underlying features required for networking and
CD-ROM support (which abuses the networking feature) were added in
DOS 3.x. Hence why you see DOS 3.x as the minimum requirement on a
lot of things.

According to my notes, MS-DOS 3.10 was the first version with
networking, not 3.00.

I wouldn't doubt it if Wikipedia has a page with a list of DOS features
by version to confirm. I didn't check, but I'm 98% certain it's there.


--

[Scott Lurndal]

Post by ***@gmail.com

Post by Grant Taylor

What is the logic behind this functionality? Bells have nothing
to do with display. Meaning stdout is not a display stream.

Teletypes, a descendant of typewriters, /did/ have a physical bell on them.
The bell was used to get someone's attention for one reason or another.

And if I had designed a teletype in the same era that had a
coffee maker attached, would the designers of ASCII have
reserved a control character to switch it on?

If you can recall back to the days of typewriters, two
words spring immediately to mind.

"margin bell"

It allows touch typists to know when the end of a line
has been reached. Adding the BEL character allowed
the margin bell to be controlled by the computer.

[[e-mail]]

Post by ***@gmail.com
A similar principle. What is the principle of the data stream
that is sent to a terminal?

What layer are you talking about?
Purely application data?
Control characters (below application data)?

If a program does printf of ESC [ 2 J to clear the screen,
which one of the above is it?

Line encoding (below control characters)?

I'm not entirely sure what this actually is, but I'm pretty
sure I'm not interested in that.

Thanks. Paul.

[JJ]

When you send a data stream to stdout, you can include
a '\a' (alert) which in ASCII is ctrl-G, BEL, to sound an alarm
at the destination terminal.
What is the logic behind this functionality? Bells have nothing
to do with display. Meaning stdout is not a display stream.
You may as well have control codes for "put the coffee
machine on" and "play AC/DC - Back in Black". If this was
a "smart home" you could have these things available. But
is the stdout stream the appropriate place to drive them?
Thanks. Paul.

ASCII specification doesn't state that its control characters are just for
display. It's why there are many other non display related control
characters. e.g. EOF, DC1, SYN, etc.

Technologies are always evolving. Do not judge old specifications based on
current technology standard. They may not make sense now, but they are back
then - and for very good reasons.