It exists.

But I am having a few "challenges".

The VSI kit works out of the box, but without mysqli support then it is
not that useful.

And I am having problems with the Berryman kit.

Specifically php_x86_7_4_28.zip where I have tried with both
X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
always get:

$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file
ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?

Arne

On 3/20/24 8:51 AM, Arne Vajhøj wrote:
> It exists.
>
> But I am having a few "challenges".
>
> The VSI kit works out of the box, but without mysqli support then it is
> not that useful.
>
> And I am having problems with the Berryman kit.
>
> Specifically php_x86_7_4_28.zip where I have tried with both
> X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
> always get:
>
> $ php
> %DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
> -CLI-E-IMGNAME, image file
> ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
> -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
>
> Any suggestions for what version of Berryman PHP that works
> with what version of VSI LDAP?

The 7.4.28 kit was built 2 years ago and was linked against LDAP V2.5-7
(VSI-X86VMS-LDAP-V0205-7-1.ZIP).

The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image. PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

Mark Berryman

On 3/20/2024 5:39 PM, Mark Berryman wrote:
> On 3/20/24 8:51 AM, Arne Vajhøj wrote:
>> It exists.
>>
>> But I am having a few "challenges".
>>
>> The VSI kit works out of the box, but without mysqli support then it
>> is not that useful.
>>
>> And I am having problems with the Berryman kit.
>>
>> Specifically php_x86_7_4_28.zip where I have tried with both
>> X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
>> always get:
>>
>> $ php
>> %DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
>> -CLI-E-IMGNAME, image file
>> ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
>> -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
>>
>> Any suggestions for what version of Berryman PHP that works
>> with what version of VSI LDAP?
>
> The 7.4.28 kit was built 2 years ago and was linked against LDAP V2.5-7
> (VSI-X86VMS-LDAP-V0205-7-1.ZIP).

I don't have that or know where to get.

> The more recent kits split out the extensions that depend on a
> particular layered product version as loadable extensions rather than
> building them into the phpshr.exe image.  PHP 8.1.23, for example, is
> linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

I was planning on doing 7.4, because some of the code is
pretty old style, but 8.1 will probably be fine.

Thanks.

Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?

Arne

On Wed, 20 Mar 2024 20:18:31 -0400, Arne Vajhøj wrote:

> Regarding all the link problems - would it be better
> instead of xxxxxx.EXE to distribute xxxxxx.OLB and
> LINK_xxxxxx.COM and let users link in their environment?

Interesting that, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning.

On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
> On Wed, 20 Mar 2024 20:18:31 -0400, Arne Vajhøj wrote:
>> Regarding all the link problems - would it be better
>> instead of xxxxxx.EXE to distribute xxxxxx.OLB and
>> LINK_xxxxxx.COM and let users link in their environment?
>
> Interesting that, while VMS was a pioneer of shared libraries in the early
> days, it never progressed to developing library versioning.

It did.

Which is actually what is causing the problem here.

Arne

On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:

> On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
>
>> early days, it never progressed to developing library versioning.
>
> It did.

It’s supposed to solve problems with linking with incompatible libraries.

On 2024-03-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
> It exists.
>
> But I am having a few "challenges".
>
> The VSI kit works out of the box, but without mysqli support then it is
> not that useful.
>

That needs to be fixed. IMHO, without mysqli, it is a usable kit in name only.

Simon.

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

On 3/20/2024 10:40 PM, Lawrence D'Oliveiro wrote:
> On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
>> On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
>>> early days, it never progressed to developing library versioning.
>>
>> It did.
>
> It’s supposed to solve problems with linking with incompatible libraries.

It refuses to load the executable when only an incompatible
library is present. It does not by magic download a compatible
library.

Arne

On 3/21/2024 7:35 PM, Arne Vajhøj wrote:
> On 3/20/2024 10:40 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
>>> On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
>>>> early days, it never progressed to developing library versioning.
>>>
>>> It did.
>>
>> It’s supposed to solve problems with linking with incompatible libraries.
>
> It refuses to load the executable when only an incompatible
> library is present. It does not by magic download a compatible
> library.

And for those that never got to read that section of the linker
manual:

$ type hello1.for
subroutine hello
write(*,*) 'hello 1'
end
$ type hello2.for
subroutine hello
write(*,*) 'hello 2'
end
$ type main.for
program main
call hello
end
$ for hello1
$ for hello2
$ for main
$ set noon
$ def/nolog hello sys$disk:[]hello.exe
$! I am not aware of the issue
$ link/share=hello hello1 + sys$input/opt
symbol_vector=(hello=procedure)
$ $ link main + sys$input/opt
hello/share
$ $ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
symbol_vector=(hello=procedure)
$ $ run main
%DCL-W-ACTIMAGE, error activating image HELLO
-CLI-E-IMGNAME, image file DKA0:[arne]hello.EXE;3
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$! I am not willing to commit to maintaining backwards compatibility
$ link/share=hello hello1 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$ $ link main + sys$input/opt
hello/share
$ $ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=equal,1,2
symbol_vector=(hello=procedure)
$ $ run main
%DCL-W-ACTIMAGE, error activating image HELLO
-CLI-E-IMGNAME, image file DKA0:[arne]hello.EXE;5
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$! I promise to maintain backwards compatibility
$ link/share=hello hello1 + sys$input/opt
gsmatch=lequal,1,1
symbol_vector=(hello=procedure)
$ $ link main + sys$input/opt
hello/share
$ $ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=lequal,1,2
symbol_vector=(hello=procedure)
$ $ run main
hello 2
$! fake it
$ link/share=hello hello1 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$ $ link main + sys$input/opt
hello/share
$ $ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$ $ run main
hello 2
$! hack it
$ link/share=hello hello1 + sys$input/opt
gsmatch=always,1,1
symbol_vector=(hello=procedure)
$ $ link main + sys$input/opt
hello/share
$ $ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=always,1,2
symbol_vector=(hello=procedure)
$ $ run main
hello 2

Arne

On Thu, 21 Mar 2024 19:35:44 -0400, Arne Vajhøj wrote:

> It does not by magic download a compatible library.

Consider, on Linux, the transition from libc.so.5 to libc.so.6.

Now, to VMS denizens, those may look like version numbers on the end. But
they’re not--at least, not in the sense that VMS uses them, as some kind
of temporary backup facility that gets wiped out by the next PURGE
command.

Because there is no PURGE command on Linux. Those are actually different
file names, installed by different packages. So programs linked against
the old libc could coexist with those built against the new one.

Furthermore, that transition happened over a quarter century ago.
Notwithstanding the enhancements to libc since then, it is likely there
will never be, or need to be, a libc.so.7. This is because the symbols
themselves now have version numbers, so programs linked against older
versions can now share the same library file with those built more
recently.

On 2024-03-21 02:40:20 +0000, Lawrence D'Oliveiro said:

> On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
>
>> On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
>>
>>> early days, it never progressed to developing library versioning.
>>
>> It did.
>
> It’s supposed to solve problems with linking with incompatible libraries.

Which is exactly what has happened here. An incompatible shareable
image library was found in the default path, and its activation
violated the rules the developers provided to the linker, and the
activation was blocked.

As with myriad other implementation details, implementing
upward-compatibility is complex and nuanced and interconnected, with
the choices all having trade-offs.

Solutions range from static linking, to dynamic linking and shareable
images on OpenVMS and GSMATCH, to a storage-intensive solution such as
Nix as is used by NixOS and as available on some other platforms, to
storage-intensive self-contained app bundles.

Adding to the complexity and nuance, various development projects can
be fond of making incompatible changes whether for technical reasons or
for expediency or whatever (q.v. The CADT Model, etc), as anyone
familiar with Linux or OpenSSL or other platforms and packages will
become well aware. These incompatibilities can arise at API, or ABI, or
both. OpenVMS has had a few of these breaking changes too, not the
least of which was with the BACKUP callable API. Which AFAIK never
really has been fully cleaned up, either.

In the last couple of decades, OpenVMS has gone out of its way to
effectively disable GSMATCH usage in certain of its own libraries. This
being a workaround for a mess which arises from weak tooling, and from
update practices that range from exceedingly cautious to just bad.

And as for API and ABI design consistency goals more generally, not
breaking compatibility that needs to be broken "for reasons" is
empirically a poor long-term strategy for success, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On Sat, 23 Mar 2024 12:23:14 -0400, Stephen Hoffman wrote:

>> It’s supposed to solve problems with linking with incompatible
>> libraries.
>
> Which is exactly what has happened here. An incompatible shareable image
> library was found in the default path, and its activation violated the
> rules the developers provided to the linker, and the activation was
> blocked.

What happened here is known as “DLL hell”. So you see, it’s something else
Windows inherited from VMS.

On 3/20/2024 8:18 PM, Arne Vajhøj wrote:
> On 3/20/2024 5:39 PM, Mark Berryman wrote:
>> The more recent kits split out the extensions that depend on a
>> particular layered product version as loadable extensions rather than
>> building them into the phpshr.exe image.  PHP 8.1.23, for example, is
>> linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).
>
> 8.1.23 works perfect.

Pretty well anyway.

My DIY stuff runs.

I can get a ZF 3 app to run.

But a Laravel 9 app gives me:

$ php artisan serve
zend_mm_heap corrupted

:-(

Arne

On 2024-03-23 21:56:37 +0000, Lawrence D'Oliveiro said:

> On Sat, 23 Mar 2024 12:23:14 -0400, Stephen Hoffman wrote:
>
>>> It’s supposed to solve problems with linking with incompatible
>>> libraries.
>>
>> Which is exactly what has happened here. An incompatible shareable
>> image library was found in the default path, and its activation
>> violated the rules the developers provided to the linker, and the
>> activation was blocked.
>
> What happened here is known as “DLL hell”. So you see, it’s something
> else Windows inherited from VMS.

Shareables can require different versions around, yes. All platforms
have to deal with this case, too.

In the linker, in the image activator, in the installer or package
manager, and in the system and the app updates/upgrades.

For OpenVMS, I'd suggest spending some time in the linker manual and
particularly with GSMATCH details.

Page 93: https://docs.vmssoftware.com/docs/VSI_Linker_Manual.pdf

The developers coded this shareable image for an exact match only,
meaning that they were not expecting or not keeping ABI stability. Or
they didn't specify GSMATCH.

Whether that was appropriate choice here, I don't know, as I don't know
the details of the ABI here.

OpenVMS does not do well around installations and upgrades and parallel
versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.

--
Pure Personal Opinion | HoffmanLabs LLC

On Sun, 24 Mar 2024 11:30:17 -0400, Stephen Hoffman wrote:

> OpenVMS does not do well around installations and upgrades and parallel
> versions, with various apps chosing their own paths here, and OpenVMS
> itself chosing different paths in different cases.

Like I said, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning. Which (I
didn’t make clear before, I assumed it was understood) nowadays means
being able to cope with transitioning between versions.

It’s not just Linux that has a solution to this problem: the BSDs do, too,
and I believe their solution predated Linux.

Back when VMS was new, the Unixes were still trying to come to terms with
shared libraries. But they have long since surpassed the pioneer in this
regard.

On 2024-03-24 22:54:07 +0000, Lawrence D'Oliveiro said:

> On Sun, 24 Mar 2024 11:30:17 -0400, Stephen Hoffman wrote:
>
>> OpenVMS does not do well around installations and upgrades and parallel
>> versions, with various apps chosing their own paths here, and OpenVMS
>> itself chosing different paths in different cases.
>
> Like I said, while VMS was a pioneer of shared libraries in the early
> days, it never progressed to developing library versioning. Which (I
> didn’t make clear before, I assumed it was understood) nowadays means
> being able to cope with transitioning between versions.
>
> It’s not just Linux that has a solution to this problem: the BSDs do,
> too, and I believe their solution predated Linux.
>
> Back when VMS was new, the Unixes were still trying to come to terms
> with shared libraries. But they have long since surpassed the pioneer
> in this regard.

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.

But you're not interested in any of this.

--
Pure Personal Opinion | HoffmanLabs LLC

On Mon, 25 Mar 2024 12:34:59 -0400, Stephen Hoffman wrote:

> Linux is a mess here, too.

The *nixes manage to cope with greater complexity than VMS can manage.

On Mon, 25 Mar 2024 20:22 +0000 (GMT Standard Time), John Dallman wrote:

> They do require regarding the API compatibility as a fundamental
> feature, never to be busted without a very good reason.

That practically goes without saying. The problem here is a bit more
subtle than that.

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

> In article <uts93j$16m5n$1@dont-email.me>, seaohveh@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

On 3/25/2024 4:22 PM, John Dallman wrote:
> In article <uts93j$16m5n$1@dont-email.me>, seaohveh@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.
>
> John
>

After having some experience with RTLs in VMS, WEENDOZE seemed to me to be a bit
lacking.

Ok, a confession. I have a database product which has a couple RTLs and a
couple files for linking. I attribute my placing them in SYS$SHARE to laziness.
Guilty as charged. However, with logical names on VMS it is rather trivial to
associate RTLs and such with particular applications. After all, the developers
should have to do some work.

The final concept I came up with in WEENDOZE was to place such files in the same
location as the application executables.

As a general concept, the RTLs, DLLs, and such that are developer and/or used
with a particular application are indeed part of that application. Storage
should no longer be an issue. My first DEC system was a PDP11-40 RSTS system
with 8 RKK05 disk drives. Each was 2000 blocks. Thought it was great, at the
time. Today we have multi-terabyte drives. While old habits die slowly, my
opinion is use whatever storage (and memory) is required to have a well ordered
application installation. Bundle the complete application as a single entity.

While some may feel that VMS (and others) should have tools to address such,
I've found that logical names can do the job. And some work by the developer.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/25/2024 5:18 PM, Lawrence D'Oliveiro wrote:
> On Mon, 25 Mar 2024 12:34:59 -0400, Stephen Hoffman wrote:
>
>> Linux is a mess here, too.
>
> The *nixes manage to cope with greater complexity than VMS can manage.
>

That's kind of arbitrary, in my opinion. The corollary is that VMS just might
do some things a bit better than other OSs. Might depend upon your definition
of complex.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Mon, 25 Mar 2024 18:33:12 -0400, Stephen Hoffman wrote:

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

What the *nix folks do is bite the bullet and make breaking ABI changes
every now and then: a public structure might gain extra fields, a type
like time_t might need to change from 32 bits to 64 bits (even on 32-bit
systems, to avoid the year-2038 problem), and so on.

So code compiled against the new version of the library picks up the new
definitions, while binaries built against the old version continue to work
unchanged.

On 3/23/2024 7:36 PM, Arne Vajhøj wrote:
> On 3/20/2024 8:18 PM, Arne Vajhøj wrote:
>> On 3/20/2024 5:39 PM, Mark Berryman wrote:
>>> The more recent kits split out the extensions that depend on a
>>> particular layered product version as loadable extensions rather than
>>> building them into the phpshr.exe image.  PHP 8.1.23, for example, is
>>> linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).
>>
>> 8.1.23 works perfect.
>
> Pretty well anyway.
>
> My DIY stuff runs.
>
> I can get a ZF 3 app to run.
>
> But a Laravel 9 app gives me:
>
> $ php artisan serve
> zend_mm_heap corrupted
>
> :-(

Slim 4 also runs.

Arne

On 3/25/2024 7:20 PM, Dave Froble wrote:
> On 3/25/2024 4:22 PM, John Dallman wrote:
>> In article <uts93j$16m5n$1@dont-email.me>, seaohveh@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.

> Ok, a confession.  I have a database product which has a couple RTLs and
> a couple files for linking.  I attribute my placing them in SYS$SHARE to
> laziness.  Guilty as charged.  However, with logical names on VMS it is
> rather trivial to associate RTLs and such with particular applications.
> After all, the developers should have to do some work.

> As a general concept, the RTLs, DLLs, and such that are developer and/or
> used with a particular application are indeed part of that application.
> Storage should no longer be an issue.  My first DEC system was a
> PDP11-40 RSTS system with 8 RKK05 disk drives.  Each was 2000 blocks.
> Thought it was great, at the time.  Today we have multi-terabyte
> drives.  While old habits die slowly, my opinion is use whatever storage
> (and memory) is required to have a well ordered application
> installation.  Bundle the complete application as a single entity.
>
> While some may feel that VMS (and others) should have tools to address
> such, I've found that logical names can do the job.  And some work by
> the developer.

VMS got the version check in the image activator.

VMS allows side by side installation using logicals.

Could VMS do more? Yes. But I don't think there is a good
case to do more. The message from VMS users seems to be
that they want less not more in this area. The "please
maintain backwards compatibility and disable the version
check and I will just upgrade to latest and greatest and
it should work" seems to be what the customers want.

Arne

On 2024-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> VMS got the version check in the image activator.
>
> VMS allows side by side installation using logicals.
>
> Could VMS do more? Yes. But I don't think there is a good
> case to do more. The message from VMS users seems to be
> that they want less not more in this area. The "please
> maintain backwards compatibility and disable the version
> check and I will just upgrade to latest and greatest and
> it should work" seems to be what the customers want.
>

Linux isn't perfect in this regard either.

The earliest "fun" I remember in this area was the move from the .so.5
version of the C++ (not C) ABI to the .so.6 version.

This was especially "fun" when you tried to install/build a more modern
gcc (then use it to build programs) on a version of Linux that was using
..so.5 for its own C++ libraries.

Simon.

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