[Info-vax] New CEO of VMS Software

[Arne Vajhøj]

On 1/6/2024 3:27 PM, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 15:30 +0000 (GMT Standard Time), John Dallman wrote:
>> It can't be made fully 64-bit without breaking source-level
>> compatibility with customer code.

> Yes, but remember, at the same time, they were able to bring out their own
> Unix OS for the same hardware, and make it fully 64-bit from the get-go.

It was the same technical problem, but a different business context.

Changing all pointers from 32 to 64 bit would break a lot of legacy
code.

But DEC was making a lot of money from VMS VAX customers and wanted
to keep those customers, so VMS VAX code had build on VMS Alpha (and
actually allow converting VMS VAX executables to VMS Alpha executables
without source code).

No such concern was made for the Ultrix customers going to DEC OSF/1
aka DUNIX aka Tru64.

DEC made less money from Ultrix. Ultrix and OSF/1 was two different
Unixes so compatibility would have been difficult anyway. And porting
C code using a C API was easier anyway.

> Look at how the Linux kernel does it, on platforms (e.g. x86) where 32-bit
> code still matters: it is able to be fully 64-bit internally, yet offer
> both 32-bit and 64-bit APIs to userland.

> By about 1996, there were 4 OSes that you might say were in common use on
> Alpha: DEC Unix, OpenVMS, Windows NT, and Linux. Two of them (Unix and
> Linux) were fully 64-bit; one (OpenVMS) was a hybrid of 32- and 64-bit
> code; and Windows NT was 32-bit only.

32 and 64 bit on Linux (or Windows) is totally different from
32 and 64 bit on VMS Alpha/Itanium/x86-64.

They have 32 bit code with 32 bit pointers and 64 bit code with
64 bit pointers.

VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
(32 bit pointers getting extended to 64 bit addresses).

Arne