On 2023-06-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <u5l89k$ddca$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>_If_ I understand what you are saying correctly, then that would
>>appear to mean existing versions of 64-bit operating systems are
>>not compatible with this proposed new architecture, which means
>>that you will need a new version of your existing 64-bit operating
>>systems before it will boot on the new architecture.
>
> Not necessarily, but with caveats.
>
> In particular, this is not true if the OS in question already
> supports direct entry in 64-bit mode.
>

[snip]

Thank you for the writeup Dan as it has clarified some things.

Simon.

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

On 2023-06-05, Chris Townley <news@cct-net.co.uk> wrote:
>
> On E9.2-1
>
> $ edit/teco
> %DCL-W-ACTIMAGE, error activating image TECO32_TV
> -CLI-E-IMAGEFNF, image file not found
> VMS2$DKA0:[SYS0.SYSCOMMON.][SYSEXE]TECO32_
> TV.EXE;
> $
>

Thanks to you and others for checking.

Simon.

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

On 2023-06-05, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2023-06-05 17:50:41 +0000, Simon Clubley said:
>
>> ...EDIT/TECO...
>
> I'll just leave this here: https://github.com/blakemcbride/TECOC
>

I wonder if that is what VSI will end up shipping as the TECO for
x86-64 VMS. :-)

According to the change history, they appear to have enabled video
support so I wonder if vtedit will now run (it didn't in the past).

Simon.

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

On 2023-06-06 14:12, Simon Clubley wrote:
> On 2023-06-05, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2023-06-05 17:50:41 +0000, Simon Clubley said:
>>
>>> ...EDIT/TECO...
>>
>> I'll just leave this here: https://github.com/blakemcbride/TECOC
>>
>
> I wonder if that is what VSI will end up shipping as the TECO for
> x86-64 VMS. :-)
>
> According to the change history, they appear to have enabled video
> support so I wonder if vtedit will now run (it didn't in the past).

I think that would require some additional work.

The VMS TECO was made into a callable editor unless my memory fails me.
The C implementation I wouldn't expect to work like that out of the box.

Isn't Andrew Goldstein around anymore? I believe he was pushing a lot
for TECO on VMS in the past...

Johnny

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....
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <u5nru2$8od$1@panix2.panix.com>,
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....

Sadly, though, x86 rings other than 0 and 3 haven't had much
effect since paging was introduced in the 80386. It's not like
either the VAX or Alpha, where the execution mode affected, say,
page table access permissions. With the port-IO mechanism
mainly relegated to legacy devices, and segmentation becoming
basically meaningless, there just isn't much you can do with it.

- Dan C.

Den 2023-06-06 kl. 16:39, skrev Johnny Billquist:
> On 2023-06-06 14:12, Simon Clubley wrote:
>> On 2023-06-05, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>> On 2023-06-05 17:50:41 +0000, Simon Clubley said:
>>>
>>>> ...EDIT/TECO...
>>>
>>> I'll just leave this here: https://github.com/blakemcbride/TECOC
>>>
>>
>> I wonder if that is what VSI will end up shipping as the TECO for
>> x86-64 VMS. :-)
>>
>> According to the change history, they appear to have enabled video
>> support so I wonder if vtedit will now run (it didn't in the past).
>
> I think that would require some additional work.
>
> The VMS TECO was made into a callable editor unless my memory fails me. The
> C implementation I wouldn't expect to work like that out of the box.
>
> Isn't Andrew Goldstein around anymore? I believe he was pushing a lot for
> TECO on VMS in the past...
>
>   Johnny
>

Andy.

https://www.linkedin.com/in/andygoldstein/

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

But the difference are really just what the access rights to different
pages are. Kernel is the only one that truly is a bit more special.

Johnny

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.

>But the difference are really just what the access rights to different
>pages are. Kernel is the only one that truly is a bit more special.

Yes.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

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.

Arne

On 6/6/2023 5:42 AM, Hans Bachner wrote:
> Jan-Erik Söderholm schrieb am 05.06.2023 um 23:52:
>> Den 2023-06-05 kl. 22:02, skrev Hans Bachner:
>>> Simon Clubley schrieb am 05.06.2023 um 19:50:
>>>> On 2023-06-05, John H Reinhardt <johnhreinhardt@thereinhardts.org>
>>>> wrote:
>>>>> $ teco
>>>>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>>>>>    \TECO\
>>>>
>>>> On VMS, the usual command is "EDIT/TECO".

>>>> X86005> edit /teco login.com
>>>> %DCL-W-ACTIMAGE, error activating image TECO32_TV
>>>> -CLI-E-IMAGEFNF, image file not found
>>>> $65$DKA0:[SYS0.SYSCOMMON.][SYSEXE]TECO32_TV.EXE;

>>>> Is there a placeholder
>>>> command
>>>> table entry for it ?
>>>
>>> No.
>>
>> Isn't the fact that it tries to start TECO32_TV a proof
>> of that there *is* a command table entry for that command?
>
> I probably mis-interpreted the term "placeholder command table entry".
> Sounded to me like "does it invoke an image telling you that TECO is not
> (yet) available". I should improve my English :-)
>
>> But then, I would not take the fact that some command has been
>> copied from earlier platforms as a fact that it will be available.
>
> I agree.

DCLTABLES has EDIT /TECO and it points to
SYS$SYSTEM:TECO32_TV.EXE that does not exist.

I believe the _TV suffix indicates that it is
a translated VAX image.

VSI has states that they will *not* provide an
IEST utility (similar to VEST and AEST).

Yes - it very much look like a left over in DCLTABLES.

And if TECO on Alpha indeed was VEST'ed (and AEST'ed to Itanium????)
then it seems rather unlikely that it will ever show up on
x86-64.

Arne

On 6/6/2023 7:55 PM, Arne Vajhøj wrote:

> VSI has states that they will *not* provide an
> IEST utility (similar to VEST and AEST).

Correct; work had started on an Alpha-to-X86_64 tool, but
that did not continue; I'm not sure how much progress
was made.

> And if TECO on Alpha indeed was VEST'ed (and AEST'ed to Itanium????)
> then it seems rather unlikely that it will ever show up on
> x86-64.
VSI will definitely not provide a TECO for X86_64 based on the VAX/Alpha/IA64
lineage.

Yes, Andy Goldstein is still around, but mostly retired.

--

--- Rob

Den 2023-06-07 kl. 04:32, skrev Robert A. Brooks:
> On 6/6/2023 7:55 PM, Arne Vajhøj wrote:
>
>> VSI has states that they will *not* provide an
>> IEST utility (similar to VEST and AEST).
>
> Correct; work had started on an Alpha-to-X86_64 tool, but
> that did not continue; I'm not sure how much progress
> was made.
>
>> And if TECO on Alpha indeed was VEST'ed (and AEST'ed to Itanium????)
>> then it seems rather unlikely that it will ever show up on
>> x86-64.
>  VSI will definitely not provide a TECO for X86_64 based on the
> VAX/Alpha/IA64 lineage.
>
> Yes, Andy Goldstein is still around, but mostly retired.
>

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

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.

Johnny

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

Johnny

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

Johnny

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

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.

On Sunday, June 4, 2023 at 3:31:55 PM UTC-4, John Dallman wrote:
> In article <630361da-4c95-4556...@googlegroups.com>,
> n.r...@bell.net (Neil Rieck) wrote:
>
> > As far as the Intel proposal is concerned, "I thought" that
> > Microsoft has already blocked running 16-bit programs on their
> > 64-bit OS for a few years now.
> They deliberately left it out of 64-bit Windows from the beginning of
> that OS. The hardware has been capable of running 16-bit code since AMD
> first designed x86-64, but Microsoft only exploited that in 32-bit
> Windows.
>
> John

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)

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

On Monday, June 5, 2023 at 1:05:05 AM UTC-4, terry-...@glaver.org wrote:

> The 8600 / 8650 also had full compatibility mode (but the 8600 was originally the VAX-11/790 before being renamed).
>
> Work on the MicroVAX showed that infrequently-used parts of the VAX instruction set could be emulated with minor hardware assists. The same sort of thing was done with the PDP-11 instruction set. Later versions of the VAX RSX layered product implemented PDP-11 emulation for CPUs that didn't have it natively.
>

Thanks for this. Although I began working on VAX systems in 1987 but didn't know about VAX-11/790 or that it had been renamed 8600.

We migrated to a dual host VAX-8550 VAXcluster in 1988 and I recall one of the older guys on our team crabbing that RSX applications were no longer available. Based upon your comment it appears that our machine was missing the VAX RSX layered product. (this is something else I didn't know about until now)

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

On 2023-06-07, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> I must ask (since I have never used TECO).
>

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.

> 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, in the same way as I use the EDT
keypad while editing on Linux boxes.

Simon.

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

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.

Simon.

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

On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>
> 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.
>

QNX.

> I guess Honeywell did, but can't say they were overly successful. MACH
> also did, but that part seems to not live on anywhere.
>

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.

BTW, note that I said "safer" computing. I did not say "safe" computing.

There is no such thing as absolutely safe computing, especially when the
attacker is determined enough and resourced enough. The goal is to put
enough barriers in the way of most attackers that they cannot achieve
their goals and to make it expensive and painful for those attackers
who work for nation state authorities.

Simon.

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

In article <u5pj2u$v2q$2@news.misty.com>,
Johnny Billquist <bqt@softjar.se> 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.

Believe it or not, `sed` is actually Turing complete; I imagine
that TECO is as well. So in some absolute sense, both are
equally powerful.

Whether it's more or less painful to accomplish a given task in
sed versus TECO is of course another matter, and I'd imagine
that for most non-trivial tasks, TECO is easier.

Perhaps a better comparison vis Unix tools is with `ed`, though.

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

Well put. I feel like TECO has more purchase on PDPs of various
types than on VMS, as well.

- Dan C.

On 2023-06-07 12:21, Neil Rieck wrote:
> On Monday, June 5, 2023 at 1:05:05 AM UTC-4, terry-...@glaver.org wrote:
>
>> The 8600 / 8650 also had full compatibility mode (but the 8600 was originally the VAX-11/790 before being renamed).
>>
>> Work on the MicroVAX showed that infrequently-used parts of the VAX instruction set could be emulated with minor hardware assists. The same sort of thing was done with the PDP-11 instruction set. Later versions of the VAX RSX layered product implemented PDP-11 emulation for CPUs that didn't have it natively.
>>
>
> Thanks for this. Although I began working on VAX systems in 1987 but didn't know about VAX-11/790 or that it had been renamed 8600.

If you go hunting on Bitsavers for documents about the 8600, you'll find
some early ones that still says VAX-11/790.

> We migrated to a dual host VAX-8550 VAXcluster in 1988 and I recall one of the older guys on our team crabbing that RSX applications were no longer available. Based upon your comment it appears that our machine was missing the VAX RSX layered product. (this is something else I didn't know about until now)

It went along with the PDP-11 software itself to Mentec in 1994.
Here is the SPD:
https://web.archive.org/web/20040408022505/http://www.mentec-inc.com/pdfs/vaxrsx.pdf

Johnny

On 2023-06-07 14:16, Simon Clubley wrote:
> On 2023-06-07, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> 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.
>>
>
> QNX.

Good point. There are a few more implementations, indeed.

>> I guess Honeywell did, but can't say they were overly successful. MACH
>> also did, but that part seems to not live on anywhere.
>>
>
> 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:

"All I/O operations, file system operations, and network operations were
meant to work through this mechanism, and the data transferred was
copied during message passing. Later versions of QNX reduce the number
of separate processes and integrate the network stack and other function
blocks into single applications for performance reasons."

> BTW, note that I said "safer" computing. I did not say "safe" computing.
>
> There is no such thing as absolutely safe computing, especially when the
> attacker is determined enough and resourced enough. The goal is to put
> enough barriers in the way of most attackers that they cannot achieve
> their goals and to make it expensive and painful for those attackers
> who work for nation state authorities.

True...

Johnny