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

[Arne Vajhøj]

On 3/12/2020 7:14 PM, Simon Clubley wrote:
> On 2020-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 3/12/2020 5:25 PM, Simon Clubley wrote:
>>> You are either being deliberately obtuse or you simply do not
>>> understand what I am saying.
>>>
>>> To answer your question: the abstraction comes from how addresses
>>> are referenced in C source code versus how they are referenced
>>> in Macro-32.
>>
>> Since you showed two pieces of C code, then I was obvious searching
>> in the C code on VMS.
>>
>> It did not occur to me that you were describing Macro-32 with C examples.
>>
> 
> 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.

There is nothing Macro-32 specific in FAB and RAB blocks,

And you should be able to call any API from Macro-32.

Macro-32 does not seem to be driving anything API wise.

> If you could write VMS API code which used C style (or other higher
> language code) addressing to their full ability, you could simply
> write something like /mode=64_bit on your compile and link commands
> and be done with it.

No.

Whatever you call need to expect what you are sending aka be compiled
with the same switches.

And in practice you will want to name same function with different
pointer size differently.

Which is actually what VMS has done.

And the C style API you are talking about both the version taking
long pointers and the one taking short pointers would be callable
from Macro-32.

For everybody except Brian there may be more conditional code
in Macro-32 code needing to call both versions.

> You can't do that on VMS due to the way the VMS APIs are structured.
> 
>> I think you will find that if you want to make a point about a problem
>> you see in language X then it may facilitate better communication if
>> your code example actually is in language X.
> 
> ????
> 
> The problems are not language specific and the problems are equally
> the same on VMS regardless of language, including in C.
> 
> You can no more switch to using RMS in some transparent 64-bit mode
> in C or Fortran than you can in Macro-32.

Of course you can't.

You can't on Unix either.

If you call Unix code compiled with 32 bit pointers with
a 64 bit pointer or code compiled with 64 bit pointers with
a 32 bit pointer then it will fail.

The pointer size is part of the binary API.

It is not necessarily part of the source API.

VMS would be a lot more portable if it had been all written
in C.

But Macro-32 is not preventing any changes to API.

Arne