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

[VAXman- at SendSpamHere.ORG]

In article <r4c5r8$p2j$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>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.

Has/had nothing to do with Macro32.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.