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

[Tim Lovern]

On Wednesday, March 11, 2020 at 7:12:58 PM UTC-7, Simon Clubley wrote:
> 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.

It would be cleaner to use an OOL, where you used a factory model to return things like a RAB object, then used setters and getters to manipulate the values. 

The factory would return an object with all the pointer details hidden - they'd be of the correct size and type. The setters and getters would handle any boxing and unboxing of values. 

Reflection could be used if you needed to know any of the implementation details.

your code wouldn't care (shouldn't care?)  what size pointers were, and shouldn't care about word vs longword vs octaword, etc.

just throwing out a thought, however disjointed and ill conceived.