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

[VAXman- at SendSpamHere.ORG]

In article <r4bf31$1cc1$1 at gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne at vajhoej.dk> writes:
>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.
>
>Some of the existing API's are definitely Macro-32 friendly. But
>that does not prevent newer API's from being less friendly but
>still accessible.

The only Macro32 friendly interfaces were those that were JSB.  All of those
Macro32 APIs now have callable interfaces to them.  Save for some of the RTL
routines, there weren't too many JSB interfaces exposed for general program-
ming.



>> There was a time when there was a real need to write applications in
>> assembly language. That time has now passed.

I can still create faster in Macro32. ;)

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

I speak to machines with the voice of humanity.