[Info-vax] New CEO of VMS Software

[Arne Vajhøj]

On 1/4/2024 11:44 PM, Lawrence D'Oliveiro wrote:
> On Fri, 5 Jan 2024 03:09:37 -0000 (UTC), Dan Cross wrote:
>> I think, again, you are talking at cross-purposes: my suspicion is that
>> Arne is referring to a VMS compatibility layer built on top of Linux,
>> not the effort of porting VMS to x86_64.
> 
> I thought I made it pretty clear early on that I was only talking about
> porting across userland executables and DCL command procedures--just the
> parts of VMS that users care about, nothing more.

If the goal is 90% compatibility, then it is reasonable easy and
low cost. But no customer demand.

If the goal is 100% compatibility, then it becomes tricky and expensive.

There will be both some hard problems and a gazillion trivial problems
to deal with.

Let me be specific. It is not difficult creating functions named
LIB$GETJPI and SYS$GETJPIW accepting certain argument. But what are
they going to return when asked for an item that does not exist
on Linux?

>> That said, VMS was not originally written for portability and wasn't
>> ported to anything other than successive version of the VAX for the
>> first 10 or so years it existed ...
> 
> And being typical of proprietary software, think of the layers of cruft
> the code will have accumulated, first in the move to Alpha, then Itanium,
> and now AMD64. All without ever really becoming a fully 64-bit OS.

I would expect practically zero cruft.

In general OS cruft does not come from adding CPU architecture support.

And both the Itanium and x86-64 ports has had as stated goals to
port as-is.

Alpha port added a whole bunch of 64 bit stuff. But that is useful
stuff not cruft.

Not everybody likes the implementation decisions made over 30 years
ago about that Alpha port, but that was prioritization back then
still not cruft.

Arne