[Info-vax] PHP on VMS x86-64 9.2-2

[Stephen Hoffman]

On 2024-03-25 20:22:00 +0000, John Dallman said:

> In article <uts93j$16m5n$1 at dont-email.me>, seaohveh at hoffmanlabs.invalid 
> (Stephen Hoffman) wrote:
> 
>> Examples of alternatives and tooling mentioned in my earlier reply, 
>> too. And Linux is a mess here, too. This is not an easy problem.
>> 
>> OpenVMS is limited here both by its compatibility goals, and as this 
>> and related areas are seemingly "below the fold" when investing time 
>> and effort on the platform.
> 
> This is very educational: I'm learning about the origins of my 
> employer's very painstaking maintenance methods for shared library 
> interfaces. Those started on VAX VMS and have been applicable to every 
> other platform we've supported. They do require regarding the API 
> compatibility as a fundamental feature, never to be busted without a 
> very good reason.

ABI and API stability avoids a whole lot of churn elsewhere in the 
general configuration, yes.

Stuff touched by this area within OpenVMS includes PCSI and VMSINSTAL, 
the image activator, kitting-related tooling including VMSKITBLD, the 
linker and GSMATCH obviously, and sundry other giblets. And there are 
bits missing that should exist here, including security and integrity 
checks. There's a lot of tooling "behind the scenes" to ensure the ABIs 
and APIs and constants are verified and don't incur any incompatible 
changes, too. Which the BACKUP API ran afoul of, and that for various 
reasons.

There are write-ups around this general topic, with various different 
ways to cope with deploying breaking changes. This includes write-ups 
for OpenVMS and other platforms, and around ABI and API stability more 
generally.

The whole purpose for itemlists is easing ABI stability for instance, 
with a newer syntactic abstraction for that same general ABI 
requirement being a message-passing ABI; OOP. A decently-designed OO 
scheme has the advantage of flexibility, and also of getting rid of 
shedloads of glue code, too. As useful as they are, OpenVMS itemlists 
are also a whole lot of glue, too. That OpenVMS still doesn't have 
support for itemlists on either the calling or called end—past the 
likes of BLISS and MACRO32 macros and ilk—is inexplicable too, but most 
of fifty years on is also now largely irrelevent.

OpenVMS uses the same strategy as Linux in some areas, particularly 
around open-source libraries that can or do make breaking changes. And 
as mentioned, OpenVMS goes out of its way to disable use of GSMATCH in 
some areas.

The downsides of ABI and API stability include cost and effort involved 
in ensuring compatibility, and the limitations on what can change. 
There are parts of OpenVMS that just can't be fixed without breaking 
the ABI and API. One area I've referenced before: UAI$_PWD

As mentioned up-thread, the approach used by Nix is probably the 
(cleanest? most flexible? least constraining?) of what is currently 
available for managing apps and app versions, though one of the 
trade-offs there is storage. Embedding the dependencies into the app is 
another, though eventually the system ABI usually has to change, too. 
Or inevitably.



-- 
Pure Personal Opinion | HoffmanLabs LLC