[Info-vax] 32/64 bits on VMS, was: Re: problem with 64-bit pointers in C

[Simon Clubley]

On 2018-01-31, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>
> The bad choice was OpenVMS V7.0, and it was a massively short-sighted 
> decision, and a decision that can and will continue to haunt OpenVMS 
> developers and will continue to have repercussions until the day y'all 
> decide to deprecate and finally, eventually, hopefully entirely remove 
> it.
>
> Ditch the 32-/64-bit compatibility and allow us to migrate our code to 
> a flat 64-bit environment.  All languages.   The design and 
> implementation was brilliant and wonderfully compatible, but using the 
> 64-bit results are just... difficult.
>

It's a pity that images couldn't have instead been built as either a purely
32 bits or purely 64 bits image as you can do elsewhere. That way, you
could keep the existing 32 bit images, but if you wanted 64 bits you had
to convert all your code to run in a 64 bit environment and to use 64-bit
libraries.

That means, for example, there would have been a distinct RMS-64 API which
used purely 64-bit values and would have been incompatible with the
existing 32-bit API.

It would have allowed backwards compatibility with existing 32-bit images
and would also have allowed a cleaner 64-bit future.

Of course, on VMS you have to support a mass of code that uses a .long
to store a pointer (for example) instead of purely using languages that
abstract away the pointer size in any code you write...

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world