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

[Simon Clubley]

On 2020-03-13, Dave Froble <davef at tsoft-inc.com> wrote:
> On 3/12/2020 7:14 PM, Simon Clubley wrote:
>>
>> I am not. The problems originate from the need to support Macro-32
>> when calling VMS APIs but they infect other languages on VMS equally badly.
>
> Whoa, let's back up a bit there.  Why do you make the "unsupported 
> claim" that new APIs will need to support Macro-32?  If indeed that is 
> what you are claiming.
>

No I am not. I am talking about how we got to where we are with VMS
today and how you could make things much more cleaner internally in
a rewrite if you didn't have to worry about Macro-32 but only support
languages with auto-resizing pointers based on whether the source code
is compiled in either 32-bit or 64-bit mode.

>>
>> The problems are not language specific and the problems are equally
>> the same on VMS regardless of language, including in C.
>
> But you had claimed that compiled Macro-32 was a problem.
>

Huh ?

>> You can no more switch to using RMS in some transparent 64-bit mode
>> in C or Fortran than you can in Macro-32.
>
> Who desires this?
>

Probably anyone who's done this kind of stuff on Unix, sees how simple
it is there and then has to do something similar on VMS.

There is a lot about VMS that is still worthwhile implementing in a new
operating system, especially the cluster and DLM stuff, but the existing
VMS internals are rather yucky by today's standards due to the era in
which they were created.

Simon.

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