Intel are considering a simplification of x86-64, removing the 16-bit and
32-bit modes, and changing the booting process, but retaining the ability
to run 32-bit applications under a 64-bit OS.

<https://www.intel.com/content/www/us/en/developer/articles/technical/envi
sioning-future-simplified-architecture.html>

Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
no longer be available at all. I don't know much about how VMS on x86-64
emulates the four ring-equivalents that were available on VAX, Alpha and
Itanium, but it seemed worth raising the issue, while Intel are taking
comments on the plan.

John

On Saturday, June 3, 2023 at 9:57:12 AM UTC-4, John Dallman wrote:
> Intel are considering a simplification of x86-64, removing the 16-bit and
> 32-bit modes, and changing the booting process, but retaining the ability
> to run 32-bit applications under a 64-bit OS.
>
> <https://www.intel.com/content/www/us/en/developer/articles/technical/envi
> sioning-future-simplified-architecture.html>
>
> Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
> no longer be available at all. I don't know much about how VMS on x86-64
> emulates the four ring-equivalents that were available on VAX, Alpha and
> Itanium, but it seemed worth raising the issue, while Intel are taking
> comments on the plan.
>
> John

What comes around goes around? How many here remember that VAX-11/780 (as well as 750 and 730) could run PDP-11 code natively in compatibility mode? This ended with the release of the 8000 series (I noticed it on our VAX-8550 which was the first machine I worked on after VAX-11)

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. I had been running museumware programs like QBASIC 1.1 ,GW-BASIC 3.23 , and QuickBASIC 7.1 ("I think" they are all 16-bit) on 32-bit Windows-7 but they all refused to run on 64-bit Windows-10. All the museumware just listed can run on Windows-10 if you first run dosbox ( https://www.dosbox.com/ )

Some BASIC enthusiasts have taken it upon themselves to make old BASICs work on Windows-10. Here are two examples:
https://robhagemans.github.io/pcbasic/
https://qb64.com/

But this post got me thinking, I wonder if dosbox (or anything listed after it) is employing 16-bit hardware in the CPU.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
https://neilrieck.net/links/cool_computer.html#windows

On 6/3/2023 9:57 AM, John Dallman wrote:
> Intel are considering a simplification of x86-64, removing the 16-bit and
> 32-bit modes, and changing the booting process, but retaining the ability
> to run 32-bit applications under a 64-bit OS.
>
> <https://www.intel.com/content/www/us/en/developer/articles/technical/envi
> sioning-future-simplified-architecture.html>
>
> Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
> no longer be available at all. I don't know much about how VMS on x86-64
> emulates the four ring-equivalents that were available on VAX, Alpha and
> Itanium, but it seemed worth raising the issue, while Intel are taking
> comments on the plan.

I am not an expert on such matters but it is my impression that:
- Intel only want to change 32 bit stuff
- VMS x86-64 does not use any 32 bit stuff

Arne

In article <630361da-4c95-4556-b7a6-40cc74829383n@googlegroups.com>,
n.rieck@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

On 6/4/2023 3:31 PM, John Dallman wrote:
> In article <630361da-4c95-4556-b7a6-40cc74829383n@googlegroups.com>,
> n.rieck@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.

Are you sure that was a MS choice?

16 bit programs are a AFAIK not run in "real mode"
but in "virtual 8086 mode".

And based on what I can read then "virtual 8086 mode"
is only available when the system is running in
"32 bit mode" / "protected mode" / "legacy mode" and
not when running in "64 bit mode" / "long mode".

Arne

On Sunday, June 4, 2023 at 7:57:02 AM UTC-4, Neil Rieck wrote:
> What comes around goes around? How many here remember that VAX-11/780 (as well as 750 and 730) could run PDP-11 code natively in compatibility mode? This ended with the release of the 8000 series (I noticed it on our VAX-8550 which was the first machine I worked on after VAX-11)

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.

TECO was one of the last holdouts of PDP-11 code on VMS. I think it finally "went native" in VMS 5.0, but it may have been earlier. TECO seems to be something that gets dragged along and sometimes fixed later. On Alpha, TECO is a VESTed VAX image. On Itanium, it appears to be a TIEd VESTed VAX image:

ALPHA::$ dir sys$system:teco*.*
Directory SYS$COMMON:[SYSEXE]
TECO32_TV.EXE;1
Total of 1 file.

ITANIC::$ dir sys$system:teco*.*
Directory SYS$COMMON:[SYSEXE]
TECO32_TV_AV.EXE;1
Total of 1 file.

Does anyone with a VSI x86 kit have TECO?

On 05/06/2023 02:02, Arne Vajhøj wrote:
> On 6/4/2023 3:31 PM, John Dallman wrote:
>> In article <630361da-4c95-4556-b7a6-40cc74829383n@googlegroups.com>,
>> n.rieck@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.
>
> Are you sure that was a MS choice?
>
> 16 bit programs are a AFAIK not run in "real mode"
> but in "virtual 8086 mode".
>
> And based on what I can read then "virtual 8086 mode"
> is only available when the system is running in
> "32 bit mode" / "protected mode" / "legacy mode" and
> not when running in "64 bit mode" / "long mode".
>
> Arne
>
>
>
I think it was more complexity. There is a version of wine that allows it:-

https://github.com/otya128/winevdm

and I thought wine did not contain a CPU emulator, but looking at the
readme.md perhaps I am wrong...

Dave

On 2023-06-05, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>
> Does anyone with a VSI x86 kit have TECO?

I wouldn't mind an answer to that question either. :-)

(Not because I use it these days, but simply because VSI said they were
going to offer TECO in some form on x86-64 and I wonder if they followed
through with that.)

Simon.

PS: I've been offered x86-64 access but am _way_ too busy with other
things at the moment, so will not be setting it up any time in the near
future. (Just mentioning this before someone makes the suggestion. :-))

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

On 2023-06-03, John Dallman <jgd@cix.co.uk> wrote:
> Intel are considering a simplification of x86-64, removing the 16-bit and
> 32-bit modes, and changing the booting process, but retaining the ability
> to run 32-bit applications under a 64-bit OS.
>
><https://www.intel.com/content/www/us/en/developer/articles/technical/envi
> sioning-future-simplified-architecture.html>
>
> Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
> no longer be available at all. I don't know much about how VMS on x86-64
> emulates the four ring-equivalents that were available on VAX, Alpha and
> Itanium, but it seemed worth raising the issue, while Intel are taking
> comments on the plan.
>

From what I can tell, VSI have completely ignored ring 1 and 2, unless
there's something going on which they have not made public yet.

Simon.

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

On 05/06/2023 13:11, Simon Clubley wrote:
> On 2023-06-05, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>>
>> Does anyone with a VSI x86 kit have TECO?
>
> I wouldn't mind an answer to that question either. :-)
>
> (Not because I use it these days, but simply because VSI said they were
> going to offer TECO in some form on x86-64 and I wonder if they followed
> through with that.)
>
> Simon.
>
> PS: I've been offered x86-64 access but am _way_ too busy with other
> things at the moment, so will not be setting it up any time in the near
> future. (Just mentioning this before someone makes the suggestion. :-))
>

The V9.2-1 release notes stated it does not include TECO

--
Chris

On 2023-06-05, Chris Townley <news@cct-net.co.uk> wrote:
> On 05/06/2023 13:11, Simon Clubley wrote:
>> On 2023-06-05, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>>>
>>> Does anyone with a VSI x86 kit have TECO?
>>
>> I wouldn't mind an answer to that question either. :-)
>>
>> (Not because I use it these days, but simply because VSI said they were
>> going to offer TECO in some form on x86-64 and I wonder if they followed
>> through with that.)
>>
>> Simon.
>>
>> PS: I've been offered x86-64 access but am _way_ too busy with other
>> things at the moment, so will not be setting it up any time in the near
>> future. (Just mentioning this before someone makes the suggestion. :-))
>>
>
> The V9.2-1 release notes stated it does not include TECO
>

Thanks.

Simon.

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

On 6/5/2023 7:21 AM, Simon Clubley wrote:
> On 2023-06-05, Chris Townley <news@cct-net.co.uk> wrote:
>> On 05/06/2023 13:11, Simon Clubley wrote:
>>> On 2023-06-05, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>>>>
>>>> Does anyone with a VSI x86 kit have TECO?
>>>
>>> I wouldn't mind an answer to that question either. :-)
>>>
>>> (Not because I use it these days, but simply because VSI said they were
>>> going to offer TECO in some form on x86-64 and I wonder if they followed
>>> through with that.)
>>>
>>> Simon.
>>>
>>> PS: I've been offered x86-64 access but am _way_ too busy with other
>>> things at the moment, so will not be setting it up any time in the near
>>> future. (Just mentioning this before someone makes the suggestion. :-))
>>>
>>
>> The V9.2-1 release notes stated it does not include TECO
>>
>
> Thanks.
>
> Simon.
>
Neither does the E9.2-1

$ show system/noproc
OpenVMS E9.2-1 on node SCALZI 5-JUN-2023 08:21:00.83 Uptime 21 08:35:01
$ teco
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\TECO\
$ dir sys$system:*TECO*
%DIRECT-W-NOFILES, no files found

I'm thinking TECO is probably a low priority item. If Compaq/HP had to VEST and TIE/VEST it then the source must be way out of date and not an easy upgrade.

John H. Reinhardt

In article <u5i3dr$3v85o$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 6/3/2023 9:57 AM, John Dallman wrote:
>> Intel are considering a simplification of x86-64, removing the 16-bit and
>> 32-bit modes, and changing the booting process, but retaining the ability
>> to run 32-bit applications under a 64-bit OS.
>>
>> <https://www.intel.com/content/www/us/en/developer/articles/technical/envi
>> sioning-future-simplified-architecture.html>
>>
>> Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
>> no longer be available at all. I don't know much about how VMS on x86-64
>> emulates the four ring-equivalents that were available on VAX, Alpha and
>> Itanium, but it seemed worth raising the issue, while Intel are taking
>> comments on the plan.
>
>I am not an expert on such matters but it is my impression that:
>- Intel only want to change 32 bit stuff
>- VMS x86-64 does not use any 32 bit stuff

Architecturally, current x86_64 cores start up in 16-bit "real"
mode when they come out of reset (or power-on), and software
must transition them into a 64-bit state with paging enabled.
Usually this is done by moving into 32-bit "protected" mode,
enabing paging, and then jumping into "long" mode.

Sometimes this is done in a bootloader before an operating
system proper is started; often, a loader will enter the OS in
32-bit mode with paging disabled and rely on the OS to set up
a paging environment as it sees fit.

Further, multi-processor startup on x86 involves sending a
series of inter-processor interrupts from a specially blessed
"Bootstrap Processor" (Intel's nomenclature; AMD calls it the
"Bootstrap Core" or sometimes "Boot Support Core") to the "APs"
(Applicaton Processors), which also start in 16-bit mode where
software must similarly move them into something reasonable.

The x86S proposal changes this. Systems will always begin
execution in 64-bit paged mode (including the BSP). For APs
this is relatively straightforward: an architecturally defined
data structure that contains an initial program counter and to a
page table root is being introduced, along with a global MSR
that contains the physical address of an instance of that data
structure; presumably, the BSP creates this, sets the MSR, and
sends a "Startup IPI" (SIPI) to a core as it does now.

For the BSP this is more complex: a "firmware interface table"
contains the instruction pointer and a page table root pointer
that the BSP will begin execution with. What's less clear is
what creates the initial page tables that the CPU comes out of
reset running against (let alone creates that table).
Furthermore, many current Intel systems rely on software running
on the x86 cores for DRAM timing training; usually this is done
by basically treating cache as RAM and running entirely in
cached memory initially; if paging is introduced into the mix
that early, it's not clear how that will happen. On AMD, for
e.g. EPYC, this is done by the PSP (Platform Security Processor)
before the x86 cores come out of reset; it's possible Intel may
take a similar approach here.

Obviously, if the x86S proposal goes forward, the relevant code
bits in VMS will have to change. I suspect VMS on x86_64 relies
on UEFI or a BIOS for DRAM training, so it can basically ignore
that; the FIT thing and SIPI startup may be a bit more
interesting, but fortunately, it's mostly in assembler and
really only a few dozen instructions so the change area will be
pretty small.

There are good reasons for wanting to get into 16-bit mode
(mainly to grab services from a legacy BIOS for e.g. setting
graphics modes and things like that; pre 3.0 VBE etc) and
obviously that won't be supported anymore; I doubt it matters
much for VMS, however.

- Dan C.

In article <u5jc75$3tmq$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 6/4/2023 3:31 PM, John Dallman wrote:
>> In article <630361da-4c95-4556-b7a6-40cc74829383n@googlegroups.com>,
>> n.rieck@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.
>
>Are you sure that was a MS choice?

Yes.

>16 bit programs are a AFAIK not run in "real mode"
>but in "virtual 8086 mode".

It really depends on the execution mode of the processor. The
CPU starts in 16-bit real mode when it comes out of reset (SDM
vol 1 sec 3.1).

>And based on what I can read then "virtual 8086 mode"
>is only available when the system is running in
>"32 bit mode" / "protected mode" / "legacy mode" and
>not when running in "64 bit mode" / "long mode".

There are two submodes of IA-32e mode: "Compatibility mode",
which is analogous to protected mode, and "64 bit mode", which
permits access to a 64-bit linear address space. The OS can
select which mode the processor runs in on a per-segment
basis; this allows a 64-bit OS to provide access to virtual
8086 mode (SDM vol 1 sec 3.1.1).

Transitioning between these is non-trivial, however; as someone
else mentioned, this is likely why MSFT did not support it.

- Dan C.

On 2023-06-05, John H Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
>>
> Neither does the E9.2-1
>
> $ show system/noproc
> OpenVMS E9.2-1 on node SCALZI 5-JUN-2023 08:21:00.83 Uptime 21 08:35:01
> $ teco
> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
> \TECO\

On VMS, the usual command is "EDIT/TECO". Is there a placeholder command
table entry for it ?

Thanks,

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, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
> Obviously, if the x86S proposal goes forward, the relevant code
> bits in VMS will have to change. I suspect VMS on x86_64 relies
> on UEFI or a BIOS for DRAM training, so it can basically ignore
> that; the FIT thing and SIPI startup may be a bit more
> interesting, but fortunately, it's mostly in assembler and
> really only a few dozen instructions so the change area will be
> pretty small.
>
> There are good reasons for wanting to get into 16-bit mode
> (mainly to grab services from a legacy BIOS for e.g. setting
> graphics modes and things like that; pre 3.0 VBE etc) and
> obviously that won't be supported anymore; I doubt it matters
> much for VMS, however.
>

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

Furthermore, it would _appear_ the new version will not run on the
existing hardware. Do I understand the situation correctly ?

_If_ my understanding is correct, then that would cause some real
costs with management of systems in the real world that's going to
really slow down adoption of the new architecture, until people are
forced to switch due to the lack of old-style hardware.

Simon.

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

In article <u5l89k$ddca$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-06-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Obviously, if the x86S proposal goes forward, the relevant code
>> bits in VMS will have to change. I suspect VMS on x86_64 relies
>> on UEFI or a BIOS for DRAM training, so it can basically ignore
>> that; the FIT thing and SIPI startup may be a bit more
>> interesting, but fortunately, it's mostly in assembler and
>> really only a few dozen instructions so the change area will be
>> pretty small.
>>
>> There are good reasons for wanting to get into 16-bit mode
>> (mainly to grab services from a legacy BIOS for e.g. setting
>> graphics modes and things like that; pre 3.0 VBE etc) and
>> obviously that won't be supported anymore; I doubt it matters
>> much for VMS, however.
>
>_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.

There are several systems that work that way, but necessarily
rely on either a symbiotic loader that knows how to set up the
paged environment that they begin execution in, or a
well-defined boot protocol for handoff from a slightly more
generic loader.

For instance, Linux _can_ work this way, and supports 64-bit
entry with any loader that implements its 64-bit boot protocol:
https://www.kernel.org/doc/Documentation/x86/boot.txt

Note that Linux supports direct EFI handoff into a 64-bit entry
point. A system that relies on that may need no change at all
to begin the boot process (the change would be invisibly handled
in firmware).

To an extent this is splitting hairs: system software that
boots into an OS must necessarily change, but that may not be
the OS itself. For systems that rely on UEFI to boot, it may
require no changes _to the OS_ at all to get the BSP running.

However, the OS usually wants to handle bringing the AP CPUs
online itself, and for that, the OS will need some modification
(hence the caveat). There is a UEFI protocol for MP management
but I don't believe it handles startup (I do not know, though).

I have no idea how VMS on x86_64 boots currently. If it does
its own transition through 16- and 32-bit modes, or if it uses
multiboot and starts in 32-bit mode, that will have to change.
But I suspect the delta would be relatively small.

>Furthermore, it would _appear_ the new version will not run on the
>existing hardware. Do I understand the situation correctly ?

Not necessarily. First, consider that almost no production
operating systems running on x86 start directly from the reset
vector; execution almost always starts in firmware, and then
_most_ use a multistage loader to boot into the actual operating
system. This prevents a chicken-and-egg problem, where the OS
image may be resident on a non-trivial device that needs to be
initialized after reset. Anyway, the point is that it is rarely
the case that the first instruction an x86 CPU runs when it
comes up is part of the actual operating system that will end
up running on that machine. [*]

Given that, nothing prevents an OS from having multiple entry
points exposing different boot protocols for variations in the
underlying hardware/firmware combination. As long as a loader
that understands the system selects the correct one for the
architecture, it can do the right thing.

AP startup is fairly straight-forward here; the proposed new
system exposes CPUID bits that the OS can use to select either
the legacy or new AP boot method.

>_If_ my understanding is correct, then that would cause some real
>costs with management of systems in the real world that's going to
>really slow down adoption of the new architecture, until people are
>forced to switch due to the lack of old-style hardware.

I don't think the situation is quite as dire as that.

- Dan C.

[*] An exception is our machine, which boots into a very thin
loader directly from reset; that is responsible for loading Unix
as a regular ELF binary, and then jumps directly to its entry
point.

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.

In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>Other than an impact on the boot loader due to the change in startup mode, it has essentially no impact on OpenVMS

Interesting. I take it OpenVMS itself is entered in 64-bit mode
then? What about AP startup? The new SIPI type must surely be
accommodated, or does the loader also start the APs and park
them until the actual OS gets around to using them?

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

The same was true of 32-bit x86 as well. The ring architecture
on x86 was never particularly useful. I've heard rumors that
OS/2 2.x used it, but beyond that, I don't think it's ever seen
much use. *shrug*

- Dan C.

On 05/06/2023 18:50, Simon Clubley wrote:
> On 2023-06-05, John H Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
>>>
>> Neither does the E9.2-1
>>
>> $ show system/noproc
>> OpenVMS E9.2-1 on node SCALZI 5-JUN-2023 08:21:00.83 Uptime 21 08:35:01
>> $ teco
>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>> \TECO\
>
> On VMS, the usual command is "EDIT/TECO". Is there a placeholder command
> table entry for it ?
>
> Thanks,
>
> Simon.
>

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;
$

--
Chris

Simon Clubley schrieb am 05.06.2023 um 19:50:
> On 2023-06-05, John H Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
>>>
>> Neither does the E9.2-1
>>
>> $ show system/noproc
>> OpenVMS E9.2-1 on node SCALZI 5-JUN-2023 08:21:00.83 Uptime 21 08:35:01
>> $ teco
>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>> \TECO\
>
> On VMS, the usual command is "EDIT/TECO". Is there a placeholder command
> table entry for it ?

No.

> X86005> show system/noproc
> OpenVMS E9.2-1 on node X86005 5-JUN-2023 22:00:42.66 Uptime 67 04:34:33
> 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;

Hans.

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.

John

On 2023-06-05 17:50:41 +0000, Simon Clubley said:

> ...EDIT/TECO...

I'll just leave this here: https://github.com/blakemcbride/TECOC

--
Pure Personal Opinion | HoffmanLabs LLC

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:
>>>>
>>> Neither does the E9.2-1
>>>
>>> $ show system/noproc
>>> OpenVMS E9.2-1  on node SCALZI    5-JUN-2023 08:21:00.83   Uptime  21
>>> 08:35:01
>>> $ teco
>>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>>>    \TECO\
>>
>> On VMS, the usual command is "EDIT/TECO". 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?

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.

>
>> X86005> show system/noproc
>> OpenVMS E9.2-1  on node X86005    5-JUN-2023 22:00:42.66   Uptime  67
>> 04:34:33
>> 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;
>
> Hans.
>

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:
>>>>>
>>>> Neither does the E9.2-1
>>>>
>>>> $ show system/noproc
>>>> OpenVMS E9.2-1  on node SCALZI    5-JUN-2023 08:21:00.83   Uptime
>>>> 21 08:35:01
>>>> $ teco
>>>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>>>>    \TECO\
>>>
>>> On VMS, the usual command is "EDIT/TECO". 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.

>>> X86005> show system/noproc
>>> OpenVMS E9.2-1  on node X86005    5-JUN-2023 22:00:42.66   Uptime  67
>>> 04:34:33
>>> 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;
>>
>> Hans.