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

VAXman- at SendSpamHere.ORG VAXman- at SendSpamHere.ORG
Thu Mar 12 20:28:57 EDT 2020


In article <r4eh4k$1t84$1 at gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne at vajhoej.dk> writes:
>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.

Even the crappy C ones! 


>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.

!


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

I speak to machines with the voice of humanity.



More information about the Info-vax mailing list