[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

[Simon Clubley]

On 2020-03-11, Arne Vajhøj <arne at vajhoej.dk> wrote:
> On 3/11/2020 3:25 PM, Simon Clubley wrote:
>> On 2020-03-11, Dave Froble <davef at tsoft-inc.com> wrote:
>>> On 3/11/2020 9:22 AM, Simon Clubley wrote:
>>>> On 2020-03-10, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>>
>>>>> Really off the wall, since Macro-32 is not part of the OS.
>>>>
>>>> Oh yes it most certainly is.
>>>>
>>>> The need to support Macro-32 as an application programming language is
>>>> the reason why the various VMS APIs look the way they do.
>>>>
>>>> It's also one of the reasons why VMS needs mixed mode 32-bit/64-bit APIs
>>>> in the same process instead of just having a flag that says the current
>>>> process uses either 32-bit or 64-bit pointers and addressing by default.
>>>
>>> Supporting what allows use of Macro-32 does not mean that the language
>>> is part of the OS.
>>>
>> 
>> But the point is that it's not about supporting Macro-32, but limiting
>> what the OS can do in its various APIs if it has to provide support for
>> applications written in assembly language.
>
> I find it very difficult to believe that any possible new
> API's could not be implemented in Macro-32.
>

That isn't what I said. What I said is that the various VMS APIs are
more ugly than they need to be because of the need to support applications
written in assembly language.

A really good example is RMS and the control blocks and what happened
during the move to 64-bit processes.

In Unix land, an address variable looks like this:

	{some data type or struct} *ptr;
	ptr = data_structure->flink;

The Unix land compiler, regardless of language, handles all the conversions
from 32-bit pointers to 64-bit pointers when you rebuild this code for
64-bit mode without you having to change this code.

In VMS land, thanks to the need to support Macro-32, an address
looks something like this:

	uint32 ptr;
	ptr = (uint32) source_address;	/* YUCK YUCK YUCK ! :-) */

with total loss of any address attribute information.

If all these raw longwords were not user-visible in the way they are
in VMS thanks to Macro-32, and you only needed to support higher level
languages, then the move to 64-bit VMS might have been as simple as
compiling and linking your code for 64-bit mode instead of 32-bit mode.

Without the need to support Macro-32, the RMS control blocks would
have been written for higher level languages with proper pointer
and other abstracted variable types which automatically change size
during compilation and linking as required.

RMS would know it was dealing with a 64-bit process (from the process
attribute information) and would know what the offsets it needed
for 64-bit mode instead of 32-bit mode without you having to change
your source code.

Instead you get the user-visible RAB64 structure and all the 32-bit
limitations which are applied to RMS. :-(

This is one area in which Unix style code is _way_ cleaner than
VMS style code due to C being the lowest supported level of language
in the Unix world, instead of assembly language as in the VMS world.

Simon.

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