On 2023-06-07 14:08, Simon Clubley wrote:
> On 2023-06-06, Scott Dorsey <kludge@panix.com> wrote:
>> John Dallman <jgd@cix.co.uk> wrote:
>>> In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n@googlegroups.com>,
>>> xyzzy1959@gmail.com (John Reagan) wrote:
>>>
>>>> Other than an impact on the boot loader due to the change in
>>>> startup mode, it has essentially no impact on OpenVMS
>>>>
>>>> OpenVMS does not use ring 1 or 2. The 64-bit mode PTEs don't
>>>> include support for ring 1 or 2 today, just ring 0 and 3.
>>>
>>> Thanks, glad to hear it.
>>
>> I'm not necessarily glad to hear it because I like the idea of keeping
>> device drivers in a different ring than user processes or kernel....
>
> Microkernels are a far better solution for that and have the major
> advantage of conceptually being architecture neutral.

Pros and cons, as usual...

Slightly related, I could argue that RSX (and maybe to some extent VMS)
are already slightly down the path of microkernels.

In RSX, the file system operations are done in a separate user level
process, which is the F11ACP. And networking is done in yet another user
level process, the NETACP. Task activation as well as rundown are yet
again done by other user level processes (INS and TKTN).

This also means that in theory adding support for new file systems is
just a question of writing another ACP and off you go. Unfortunately
there are a few places where there are some assumptions in the system,
making it not that easy to do absolutely everything in another file
system. But for normal file accesses, it works just fine. (In RSX, the
problem is that task checkpointing is done outside of the ACP, but to
the file system.)

Which is way more separation than you'll find in any kind of Unix like
system. But it's not as far as true microkernels go.

Johnny

In article <u5oe7n$9s6$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Johnny Billquist <bqt@softjar.se> wrote:
>>On 2023-06-06 19:55, Scott Dorsey wrote:
>>> John Dallman <jgd@cix.co.uk> wrote:
>>>> In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n@googlegroups.com>,
>>>> xyzzy1959@gmail.com (John Reagan) wrote:
>>>>
>>>>> Other than an impact on the boot loader due to the change in
>>>>> startup mode, it has essentially no impact on OpenVMS
>>>>>
>>>>> OpenVMS does not use ring 1 or 2. The 64-bit mode PTEs don't
>>>>> include support for ring 1 or 2 today, just ring 0 and 3.
>>>>
>>>> Thanks, glad to hear it.
>>>
>>> I'm not necessarily glad to hear it because I like the idea of keeping
>>> device drivers in a different ring than user processes or kernel....
>>
>>Hmm. Am I misremembering something? As far as I can recall, device
>>drivers in VMS (at least on VAX) are running in kernel mode. RMS in EXEC
>>and DCL in SUPER (or was it the other way around?).
>
>Yes. It's a shame. When the new i386 rings came out I was thinking
>"Wow, we could do Honeywell-style stuff and it's not a mess like the
>286 but... then nobody ever did.

I guess I don't really see how.

If you look at the ring architecture of, say, the GE-645
machines, the ring was an attribute of a segment for permission
checking by the hardware, but each segment was independently
paged (with its own page table). Put another way, the Honeywell
architectures built paging on top of segmentation, allowing them
to easily support paged segments: necessary when multiplexing a
large virtual address space over a limited physical memory.
Furthermore, Multics-style segments can exist in multiple rings
at one time.

The 80386 had no such provisions. And while x86 segment
descriptors do encode a ring level for privilege checking, and
the granularity bit introduced in the '386 allows segments to
address more than 64k of memory, segments are neither
independently paged nor do they support the Honeywell
bracketing technqiue, so sharing segments between tasks without
call gating is hard.

Further, x86 segments don't compose well with paging, and thus
aren't well-suited for multiplexing over a smaller physical
memory. Unlike the DPS-8/M, when paging is enabled on x86, the
paged virtual address space creates a large linear address space
that segments sit on top of. That is, x86 segments are
structurally the inverse of independently-paged Multics machine
segments. This means you can't have, say, copy-on-write at
page granularity across different segments: all segments
containing a page either map that page or don't.

Also, since the paging structure itself is practically unaware
of the ring architecture, providing only a single bit to select
between user (ring 3) or supervisor (ring <3) access,
the implication is that paged segments in any ring other than 3
can access any page in the linear space; there's no way to
enforce that, say, a page accessible at ring 0 is not accessible
at ring 1 or 2. This makes sharing between segments at the page
granularity practically impossible; see also no ring bracketing.

Of course, one can ignore paging entirely and _just_ use
segments, but now you essentially cannot mux them over a
relatively small physical memory at less than segment
granularity.

So what really is the point?

- Dan C.

In article <u5pi81$v2q$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-06-07 01:07, Scott Dorsey wrote:
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2023-06-06 19:55, Scott Dorsey wrote:
>>>> John Dallman <jgd@cix.co.uk> wrote:
>>>>> In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n@googlegroups.com>,
>>>>> xyzzy1959@gmail.com (John Reagan) wrote:
>>>>>
>>>>>> Other than an impact on the boot loader due to the change in
>>>>>> startup mode, it has essentially no impact on OpenVMS
>>>>>>
>>>>>> OpenVMS does not use ring 1 or 2. The 64-bit mode PTEs don't
>>>>>> include support for ring 1 or 2 today, just ring 0 and 3.
>>>>>
>>>>> Thanks, glad to hear it.
>>>>
>>>> I'm not necessarily glad to hear it because I like the idea of keeping
>>>> device drivers in a different ring than user processes or kernel....
>>>
>>> Hmm. Am I misremembering something? As far as I can recall, device
>>> drivers in VMS (at least on VAX) are running in kernel mode. RMS in EXEC
>>> and DCL in SUPER (or was it the other way around?).
>>
>> Yes. It's a shame. When the new i386 rings came out I was thinking
>> "Wow, we could do Honeywell-style stuff and it's not a mess like the
>> 286 but... then nobody ever did.
>
>Well. If you want full isolation between different parts of the kernel,
>going fully microkernel and message passing and all that, it's perfectly
>doable on pretty much any hardware. It's just that in general, whenever
>it has been done, performance always suffer. Which is why pretty much
>noone is doing it. And it's not because of issues in the hardware that
>it suffers. It's just that you can't avoid a lot more overhead when
>doing things this way. A lot of data copying first and foremost.
>
>I guess Honeywell did, but can't say they were overly successful. MACH
>also did, but that part seems to not live on anywhere.

Hmm. The Honeywell systems, perhaps exemplified by Multics,
were rather the inverse of a microkernel: they used a single
shared store for _everything_; sharing was at the granularity of
a segment, with direct call-gating between segments at different
protection rings.

- Dan C.

On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-06-07 14:16, Simon Clubley wrote:
>>
>> QNX.
>
> Good point. There are a few more implementations, indeed.
>

seL4 is also doing some serious stuff with microkernels as well:

https://sel4.systems/

>>
>> We have long moved past the point where absolute speed is the primary
>> driver in software design. Today, the focus should be on safer computing,
>> even at the expense of some overhead. To do otherwise is utterly
>> irresponsible in today's world IMHO.
>
> You might think so, and argue for that. Seems most other people are
> disagreeing, even to the point of QNX slightly moving away from it for
> performance reasons. To quote wikipedia:
>

That's disappointing. I didn't know that.

Hope that works out better than the time someone decided to move the
graphics subsystem into the kernel on a certain OS "for performance
reasons."

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <u5qfau$16j37$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-06-07 14:16, Simon Clubley wrote:
>>>
>>> QNX.
>>
>> Good point. There are a few more implementations, indeed.
>>
>
>seL4 is also doing some serious stuff with microkernels as well:
>
>https://sel4.systems/
>
>>> We have long moved past the point where absolute speed is the primary
>>> driver in software design. Today, the focus should be on safer computing,
>>> even at the expense of some overhead. To do otherwise is utterly
>>> irresponsible in today's world IMHO.
>>
>> You might think so, and argue for that. Seems most other people are
>> disagreeing, even to the point of QNX slightly moving away from it for
>> performance reasons. To quote wikipedia:
>>
>
>That's disappointing. I didn't know that.
>
>Hope that works out better than the time someone decided to move the
>graphics subsystem into the kernel on a certain OS "for performance
>reasons."

Microkernel designs are great for a lot of different reasons,
notably isolation and fault tolerance, but when you have to have
complex protocols between different components, that brings its
own kinds of risk in addition to the obvious performance
degradations. See some of the sequence diagrams for, say, doing
a read from a file in minix3, for example. In that kind of
situation, the advantages are far less clear.

But I don't know that this argues against the ukernel approach
so much as for a different division of responsibilities for the
various components. For example, a hypervisor is a good example
of the type of system where this may make a lot of sense, since
an explicit goal should be to minimize the amount of time one
spends in the HV itself (as otherwise you are stealing cycles
from guests), and one needn't provide general operating system
services like a filesystem or block-storage layer anyway. The
isolation and fault-tolerance properties are particularly
attractive in that environment, particularly for multi-tenant
scenarios. E.g, https://hypervisor.org/eurosys2010.pdf

- Dan C.

On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>
> Slightly related, I could argue that RSX (and maybe to some extent VMS)
> are already slightly down the path of microkernels.
>
> In RSX, the file system operations are done in a separate user level
> process, which is the F11ACP. And networking is done in yet another user
> level process, the NETACP. Task activation as well as rundown are yet
> again done by other user level processes (INS and TKTN).
>
> This also means that in theory adding support for new file systems is
> just a question of writing another ACP and off you go. Unfortunately
> there are a few places where there are some assumptions in the system,
> making it not that easy to do absolutely everything in another file
> system. But for normal file accesses, it works just fine. (In RSX, the
> problem is that task checkpointing is done outside of the ACP, but to
> the file system.)
>
> Which is way more separation than you'll find in any kind of Unix like
> system. But it's not as far as true microkernels go.
>

User mode filesystems are available for a subset of Unix systems however:

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

You can also access some USB devices from user mode as well:

https://libusb.info/

And finally, you can implement network protocols in user mode using
the TUN/TAP device drivers.

But you are right in that none of this is the same as a proper
microkernel however.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <u5qggo$16np4$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>> Slightly related, I could argue that RSX (and maybe to some extent VMS)
>> are already slightly down the path of microkernels.
>>
>> In RSX, the file system operations are done in a separate user level
>> process, which is the F11ACP. And networking is done in yet another user
>> level process, the NETACP. Task activation as well as rundown are yet
>> again done by other user level processes (INS and TKTN).
>>
>> This also means that in theory adding support for new file systems is
>> just a question of writing another ACP and off you go. Unfortunately
>> there are a few places where there are some assumptions in the system,
>> making it not that easy to do absolutely everything in another file
>> system. But for normal file accesses, it works just fine. (In RSX, the
>> problem is that task checkpointing is done outside of the ACP, but to
>> the file system.)
>>
>> Which is way more separation than you'll find in any kind of Unix like
>> system. But it's not as far as true microkernels go.
>
>User mode filesystems are available for a subset of Unix systems however:
>
>https://en.wikipedia.org/wiki/Filesystem_in_Userspace
>
>You can also access some USB devices from user mode as well:
>
>https://libusb.info/
>
>And finally, you can implement network protocols in user mode using
>the TUN/TAP device drivers.
>
>But you are right in that none of this is the same as a proper
>microkernel however.

Userspace filesystems were ubiquitous in Unix's successor
system, Plan 9. This followed work done in the Research Unix
systems post 7th Edition (e.g., streams and the filesystem
switch in 8th Edition and mountable file descriptors in the 9th:
https://www.bell-labs.com/usr/dmr/www/ipcpaper.html)

Plan 9 extended this with mutable, per-process (group)
namespaces, utilities to manipulate these, and a file protocol
that was used to implement all kinds of things. The window
system was implemented as a (userspace) file server, as was the
persistent file system (kinda: there were a couple of versions.
The original was actually a dedicated kernel; the one that came
later was a normal userspace process). The network stack was a
filesystem that was provided by the kernel.

Regardless, Plan 9's kernel implemented a fairly traditional
monolithic model. When asked why, Dave Presotto infamously
quipped:

"Because you need a brain the size of a planet to design a
microkernel based system and we only have egos that big."
(https://marc.info/?l=9fans&m=111558798106759&w=2)

The issue of userspace access to filesystems is mostly
orthogonal to microkernel implementation.

- Dan C.

=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com> writes:

> I must ask (since I have never used TECO).

> What is the unique feature of TECO that cannot be done with some other
> tool(s)?

The other responses to your question have most of it right. I'm here to start
a meta-discussion.

In the context of c.o.v., of course, there is only a single TECO, but that's
not actually true.

The original (paper) Tape Editor and COrrector--TECO--was a program written by
a user/customer for the PDP-1 systems at BBN and MIT. That programmer later
moved to DEC.

TECO was useful enough that it was reimplemented on later systems, both by DEC
and by the MIT hackers. DEC provided a nearly common set of commands for the
PDP-8, PDP-11, and PDP-10 (running the Tops-10 operating system); at MIT, a
separate implementation for the PDP-6 and PDP-10 running the ITS operating
system was created. (The VMS version grew out of the PDP-11 version, of course.)

One of the features of later TECO implementations is that they are Turing
complete, sopeople wrote functions and complete programs to perform complex
tasks; part of the Tops-10 installation procedure, for example, uses a TECO
program to install user options into the operating system configuration prior
to assembling the sources.

In the mid-1970s, a "real time editing" feature was created in the MIT version.
This included the capability to assign compiled functions ("macros") to
individual keystrokes; a number of people created libraries of such editing
macros for their own use. An enterprising junior hacker decided to collect all
those libraries, resolve duplications, and make a general library that everyone
could use. The result was eventually named "EMACS", short for "Editing MACroS".

No other version of TECO has all the features of the MIT PDP-10 version, so no
other TECO could host an EMACS.

Reimplementations of EMACS using Lisp dialects instead of TECO have come to be
the norm. Perhaps a Lisp implementation of VAX TECO would be of interest...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

In article <8c1ef3a0-de0a-4126-9024-99237841b087n@googlegroups.com>,
n.rieck@bell.net (Neil Rieck) wrote:

> Agreed. It has been a long time since I developed commercial
> compilable applications for Windows but I seem to recall that
> Windows developer docs referred to running 8-bit code on a 16-bit
> OS (or running 16-bit code on a 32-bit OS) as "thunking" (I have no
> idea why)

There's a decent explanation at <https://en.wikipedia.org/wiki/Thunk>.
Scroll down to "Interoperability" for their use in bridging between
different address sizes.

John

On 6/7/2023 5:36 AM, Johnny Billquist wrote:
> On 2023-06-07 11:09, Jan-Erik Söderholm wrote:
>> I must ask (since I have never used TECO).
>>
>> What is the unique feature of TECO that cannot be done
>> with some other tool(s)?
>
> I don't think there is anything that is that unique.
> However, depending on how you use it, you might need a bunch of other
> tools to accomplish the same.
>
> It obviously is an editor. But it's also a programming language that can
> be twisted into doing a lot of stuff. If you are familiar with sed (a
> Unix tool), it is somewhat similar. But I'd say TECO can do more.
> Obviously the original Emacs was written in TECO. There are other
> editors written in TECO as well. I sometimes use it when I want to do
> somewhat more complex operations over larger text files where the
> changes are a bit more complex than just search and replace.

Many editors come with "programming capabilities".

If we focus on VMS then EDT is a bit primitive, but
EVE not so - TPU is very much a full programming language.

I cannot imagine any text manipulation functionality that
could not be implemented in TPU in relative clean code.

(for those that does not know TPU then it is a procedural
language in the "Pascal family" with a bunch of editor
builtins)

Arne

On 6/7/2023 5:50 AM, Jan-Erik Söderholm wrote:
> Den 2023-06-07 kl. 11:36, skrev Johnny Billquist:
>> On 2023-06-07 11:09, Jan-Erik Söderholm wrote:
>>> I must ask (since I have never used TECO).
>>>
>>> What is the unique feature of TECO that cannot be done
>>> with some other tool(s)?
>>
>> I don't think there is anything that is that unique.
>> However, depending on how you use it, you might need a bunch of other
>> tools to accomplish the same.
>>
>> It obviously is an editor. But it's also a programming language that
>> can be twisted into doing a lot of stuff. If you are familiar with sed
>> (a Unix tool), it is somewhat similar. But I'd say TECO can do more.
>> Obviously the original Emacs was written in TECO. There are other
>> editors written in TECO as well. I sometimes use it when I want to do
>> somewhat more complex operations over larger text files where the
>> changes are a bit more complex than just search and replace.
>>
>> But writing code in TECO is arcane. It has been described (and not
>> without merit) as a write-only language. Reading it, it looks mostly
>> like line noise. So it's unlikely that most people know it, or want to
>> learn it. So these days, it's mostly old and weird people who might
>> ever use TECO. There might, of course, be various tools and programs
>> existing that are written in TECO, that people use, without knowing
>> how to write TECO themselves...
>
> So I guess it boils down to what priority VSI should put on TECO.
> How many paying custumers are asking for TECO throught official channels.

How many existing customers or potential new customers will
determine to buy or not to buy VMS based on the availability
of TECO.

My guess: zero.

Arne

On 6/7/2023 8:06 AM, Simon Clubley wrote:
> On 2023-06-07, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> What is the unique feature of TECO that cannot be done
>> with some other tool(s)?
>
> Nothing.
>
> It's for people who are used to it,

I suspect that VMS editor choice somewhat correlates
with year of birth.

TECO EDT EVE VMS IDE
-1960 few/none most some none
1960-1970 none some most few
1970-1980 none few most some
1980-1990 none none most some
1990- none none some most

:-)

And if VSI has the same impression then they know what to focus
on to be ready for in 5 years, in 10 years and in 20 years!

Arne

On 08/06/2023 00:29, Arne Vajhøj wrote:
> On 6/7/2023 8:06 AM, Simon Clubley wrote:
>> On 2023-06-07, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>> What is the unique feature of TECO that cannot be done
>>> with some other tool(s)?
>>
>> Nothing.
>>
>> It's for people who are used to it,
>
> I suspect that VMS editor choice somewhat correlates
> with year of birth.
>
>              TECO           EDT          EVE          VMS IDE
>     -1960    few/none       most         some         none
> 1960-1970    none           some         most         few
> 1970-1980    none           few          most         some
> 1980-1990    none           none         most         some
> 1990-        none           none         some         most
>
> :-)
>
> And if VSI has the same impression then they know what to focus
> on to be ready for in 5 years, in 10 years and in 20 years!
>
> Arne

I would guess that many more would EVE since 1990, and possibly LSE as
well, which of course is based in EVE

Although I did have a sysadmin who even tried to load Vi(m) onto out
Itanium in the late noughties. Silly bu$$er!

--
Chris

On 6/7/2023 5:38 AM, Johnny Billquist wrote:
> On 2023-06-07 01:16, Arne Vajhøj wrote:
>> On 6/6/2023 10:39 AM, Johnny Billquist wrote:
>>> The VMS TECO was made into a callable editor unless my memory fails me.
>>
>> Only callable EDT and callable TPU are documented in the
>> utility routines manual:
>>
>> https://docs.vmssoftware.com/vsi-openvms-utility-routines/
>>
>> Obviously "documented" and "exist" are different.
>
> It's documented in the TECO manual:
>
> https://www.livingcomputers.org/UI/UserDocs/OpenVMS-7-3/3_(Editor)_DEC_Standard_TECO.pdf
>
> Section G.17

Oh. It is.

(never looked in that manual)

And it still works on VMS Alpha.

$ type myteco.for
program myteco
integer*4 dot, z
character*255 text
call lib$get_foreign(fnm,,fnmlen)
call teco$init()
call teco$load_text('ABCDE')
call teco$set_dot(1)
call teco$delete_text(3)
call teco$set_dot(0)
call teco$pointers(dot, z)
call teco$get_text(text)
write(*,*) z, text(1:z)
end
$ for/tie myteco
$ link/nonative myteco + sys$input/opt
sys$library:tecoshr_tv/share
$ $ run myteco
2 AE

(the code is not using TECO commands, but that is because
I don't know TECO commands)

Arne

On 6/7/2023 8:00 PM, Chris Townley wrote:
> On 08/06/2023 00:29, Arne Vajhøj wrote:
>> I suspect that VMS editor choice somewhat correlates
>> with year of birth.
>>
>>               TECO           EDT          EVE          VMS IDE
>>      -1960    few/none       most         some         none
>> 1960-1970    none           some         most         few
>> 1970-1980    none           few          most         some
>> 1980-1990    none           none         most         some
>> 1990-        none           none         some         most
>>
>> :-)
>>
>> And if VSI has the same impression then they know what to focus
>> on to be ready for in 5 years, in 10 years and in 20 years!
>
> I would guess that many more would EVE since 1990, and possibly LSE as
> well, which of course is based in EVE

I totally forgot about LSE. But I guess we can lump EVE and LSE
together as they are from the same era.

I don't think LSE ever became super popular. Not that great. And
in the old days pretty expensive.

> Although I did have a sysadmin who even tried to load Vi(m) onto out
> Itanium in the late noughties. Silly bu$$er!

There has always been a few vi and emacs users on VMS.

Arne

On 6/7/2023 8:10 PM, Arne Vajhøj wrote:
>       program myteco
>       integer*4 dot, z
>       character*255 text

Drop the following line as it is a leftover from something not used:

>       call lib$get_foreign(fnm,,fnmlen)
>       call teco$init()
>       call teco$load_text('ABCDE')
>       call teco$set_dot(1)
>       call teco$delete_text(3)
>       call teco$set_dot(0)
>       call teco$pointers(dot, z)
>       call teco$get_text(text)
>       write(*,*) z, text(1:z)
>       end

Arne

On 2023-06-08 01:19, Arne Vajhøj wrote:
> On 6/7/2023 5:36 AM, Johnny Billquist wrote:
>> On 2023-06-07 11:09, Jan-Erik Söderholm wrote:
>>> I must ask (since I have never used TECO).
>>>
>>> What is the unique feature of TECO that cannot be done
>>> with some other tool(s)?
>>
>> I don't think there is anything that is that unique.
>> However, depending on how you use it, you might need a bunch of other
>> tools to accomplish the same.
>>
>> It obviously is an editor. But it's also a programming language that
>> can be twisted into doing a lot of stuff. If you are familiar with sed
>> (a Unix tool), it is somewhat similar. But I'd say TECO can do more.
>> Obviously the original Emacs was written in TECO. There are other
>> editors written in TECO as well. I sometimes use it when I want to do
>> somewhat more complex operations over larger text files where the
>> changes are a bit more complex than just search and replace.
>
> Many editors come with "programming capabilities".
>
> If we focus on VMS then EDT is a bit primitive, but
> EVE not so - TPU is very much a full programming language.
>
> I cannot imagine any text manipulation functionality that
> could not be implemented in TPU in relative clean code.
>
> (for those that does not know TPU then it is a procedural
> language in the "Pascal family" with a bunch of editor
> builtins)

I don't think we need to dive into the pros and cons of different
language or environments.

Suffice to say that I wrote a fairly feature rich Emacs clone in TECO-8.
TPU would not even get close to running on a PDP-8...

Not a direct argument for TECO on VMS, but it might say a little about
how complicated or easy it is to write a screen oriented editor in TECO.

Johnny

On 2023-06-07 21:34, Rich Alderson wrote:
> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com> writes:
>
>> I must ask (since I have never used TECO).
>
>> What is the unique feature of TECO that cannot be done with some other
>> tool(s)?
>
> The other responses to your question have most of it right. I'm here to start
> a meta-discussion.
>
> In the context of c.o.v., of course, there is only a single TECO, but that's
> not actually true.
>
> The original (paper) Tape Editor and COrrector--TECO--was a program written by
> a user/customer for the PDP-1 systems at BBN and MIT. That programmer later
> moved to DEC.
>
> TECO was useful enough that it was reimplemented on later systems, both by DEC
> and by the MIT hackers. DEC provided a nearly common set of commands for the
> PDP-8, PDP-11, and PDP-10 (running the Tops-10 operating system); at MIT, a
> separate implementation for the PDP-6 and PDP-10 running the ITS operating
> system was created. (The VMS version grew out of the PDP-11 version, of course.)
>
> One of the features of later TECO implementations is that they are Turing
> complete, sopeople wrote functions and complete programs to perform complex
> tasks; part of the Tops-10 installation procedure, for example, uses a TECO
> program to install user options into the operating system configuration prior
> to assembling the sources.
>
> In the mid-1970s, a "real time editing" feature was created in the MIT version.
> This included the capability to assign compiled functions ("macros") to
> individual keystrokes; a number of people created libraries of such editing
> macros for their own use. An enterprising junior hacker decided to collect all
> those libraries, resolve duplications, and make a general library that everyone
> could use. The result was eventually named "EMACS", short for "Editing MACroS".
>
> No other version of TECO has all the features of the MIT PDP-10 version, so no
> other TECO could host an EMACS.
>
> Reimplementations of EMACS using Lisp dialects instead of TECO have come to be
> the norm. Perhaps a Lisp implementation of VAX TECO would be of interest...

Not going to argue any part of this except that you can certainly do an
EMACS in DEC TECO as well, but the original EMACS won't run on DEC TECO.

Johnny

On 2023-06-08 02:10, Arne Vajhøj wrote:
> On 6/7/2023 5:38 AM, Johnny Billquist wrote:
>> On 2023-06-07 01:16, Arne Vajhøj wrote:
>>> On 6/6/2023 10:39 AM, Johnny Billquist wrote:
>>>> The VMS TECO was made into a callable editor unless my memory fails me.
>>>
>>> Only callable EDT and callable TPU are documented in the
>>> utility routines manual:
>>>
>>> https://docs.vmssoftware.com/vsi-openvms-utility-routines/
>>>
>>> Obviously "documented" and "exist" are different.
>>
>> It's documented in the TECO manual:
>>
>> https://www.livingcomputers.org/UI/UserDocs/OpenVMS-7-3/3_(Editor)_DEC_Standard_TECO.pdf
>>
>> Section G.17
>
> Oh. It is.
>
> (never looked in that manual)
>
> And it still works on VMS Alpha.
>
> $ type myteco.for
>       program myteco
>       integer*4 dot, z
>       character*255 text
>       call lib$get_foreign(fnm,,fnmlen)
>       call teco$init()
>       call teco$load_text('ABCDE')
>       call teco$set_dot(1)
>       call teco$delete_text(3)
>       call teco$set_dot(0)
>       call teco$pointers(dot, z)
>       call teco$get_text(text)
>       write(*,*) z, text(1:z)
>       end
> $ for/tie myteco
> $ link/nonative myteco + sys$input/opt
> sys$library:tecoshr_tv/share
> $
> $ run myteco
>           2 AE
>
> (the code is not using TECO commands, but that is because
> I don't know TECO commands)

Oh! This is so much fun. Thanks for checking that one out. :-D

Next you need to figure out what your name does in TECO. ;-)

Johnny

On 2023-06-07 19:58, Simon Clubley wrote:
> On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> Slightly related, I could argue that RSX (and maybe to some extent VMS)
>> are already slightly down the path of microkernels.
>>
>> In RSX, the file system operations are done in a separate user level
>> process, which is the F11ACP. And networking is done in yet another user
>> level process, the NETACP. Task activation as well as rundown are yet
>> again done by other user level processes (INS and TKTN).
>>
>> This also means that in theory adding support for new file systems is
>> just a question of writing another ACP and off you go. Unfortunately
>> there are a few places where there are some assumptions in the system,
>> making it not that easy to do absolutely everything in another file
>> system. But for normal file accesses, it works just fine. (In RSX, the
>> problem is that task checkpointing is done outside of the ACP, but to
>> the file system.)
>>
>> Which is way more separation than you'll find in any kind of Unix like
>> system. But it's not as far as true microkernels go.
>>
>
> User mode filesystems are available for a subset of Unix systems however:
>
> https://en.wikipedia.org/wiki/Filesystem_in_Userspace
>
> You can also access some USB devices from user mode as well:
>
> https://libusb.info/
>
> And finally, you can implement network protocols in user mode using
> the TUN/TAP device drivers.

Fair enough. *These days*, *some* Unix-like systems do allow you to
implement parts in user space.

Definitely wasn't the case 30 years ago... :-)

Johnny

On Wednesday, June 7, 2023 at 5:06:09 AM UTC-7, Simon Clubley wrote:

(snip)

> The last time I really used it was decades ago, back when I started in
> the DEC world on RSTS/E at the very start of my career. When I moved to
> VMS and saw TPU, that's when I stopped using TECO.

I am surprised that there isn't a port to C for Unix and Windows.

Then that one could be ported to VMS.

OK, there is one here:

Which is in C for Ultrix, and also ported to SunOS.

https://github.com/matthiasr/teco/blob/master/READ.ME

On Thu, 2023-06-08 at 01:00 +0100, Chris Townley wrote:
> Although I did have a sysadmin who even tried to load Vi(m) onto out
> Itanium in the late noughties. Silly bu$$er!

Anyone who's worth their salt should know how to vim :-D
--
Tactical Nuclear Kittens

On 08/06/2023 09:23, Single Stage to Orbit wrote:
> On Thu, 2023-06-08 at 01:00 +0100, Chris Townley wrote:
>> Although I did have a sysadmin who even tried to load Vi(m) onto out
>> Itanium in the late noughties. Silly bu$$er!
>
> Anyone who's worth their salt should know how to vim :-D

I do know vi(m) and use it a lot on Unix/Linux systems - like EVE on VMS
it is always there. However I choose not to use it for more than simple
changes - I would never use it to write any code

--
Chris

In article <u5r9on$1k1$4@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-06-07 19:58, Simon Clubley wrote:
>> On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>>> Slightly related, I could argue that RSX (and maybe to some extent VMS)
>>> are already slightly down the path of microkernels.
>>>
>>> In RSX, the file system operations are done in a separate user level
>>> process, which is the F11ACP. And networking is done in yet another user
>>> level process, the NETACP. Task activation as well as rundown are yet
>>> again done by other user level processes (INS and TKTN).
>>>
>>> This also means that in theory adding support for new file systems is
>>> just a question of writing another ACP and off you go. Unfortunately
>>> there are a few places where there are some assumptions in the system,
>>> making it not that easy to do absolutely everything in another file
>>> system. But for normal file accesses, it works just fine. (In RSX, the
>>> problem is that task checkpointing is done outside of the ACP, but to
>>> the file system.)
>>>
>>> Which is way more separation than you'll find in any kind of Unix like
>>> system. But it's not as far as true microkernels go.
>>
>> User mode filesystems are available for a subset of Unix systems however:
>>
>> https://en.wikipedia.org/wiki/Filesystem_in_Userspace
>>
>> You can also access some USB devices from user mode as well:
>>
>> https://libusb.info/
>>
>> And finally, you can implement network protocols in user mode using
>> the TUN/TAP device drivers.
>
>Fair enough. *These days*, *some* Unix-like systems do allow you to
>implement parts in user space.
>
>Definitely wasn't the case 30 years ago... :-)

No, Unix 9th Edition was closer to 40 years ago. :-D

- Dan C.