[Info-vax] Compatibility, Porting, Migration (was: Re: Programming languages on VMS)

[Stephen Hoffman]

On 2018-01-29 16:20:00 +0000, DaveFroble said:

> Not sure what you mean by "maintenance situation".  VB6 still does 
> today what it did in the past.  Out of support from Microsoft, as far 
> as I know.  I haven't been able to install it on a weendoze 7 system, 
> or later.  I have seen information on how to do so.
> 
> And since this thread has discussed portability, all I'll say about 
> that is don't try to port VB6 code to VB.net.  You will be VERY 
> unhappy.  VB isn't portable on weendoze.
> 
> Perhaps Steve should consider such a disgusting software vendor before 
> going on too much about the evils of upward compatibility.  The grass 
> ain't greener on the other side of the fence, it's brown and crinkly.


I've not made more than incidental use of a Microsoft Windows system in 
the past decade.   Redmond is interesting to watch from afar.  That 
both for things they do well, and for that they don't.

As for debating VB6 and VB.NET, VB.NET is most of twenty years back.

The folks at Microsoft have massive problems with an enormous installed 
base and with software and hardware permutations nearly beyond 
comprehension, and many of those folks either aren't willing or aren't 
able to move forward.   Hauling all those folks forward is not and 
never will be easy.    Complete compatibility is impossible, too.   The 
.NET frameworks are how the Redmond folks have worked to reduce some of 
those permutations, and as has been discussed around here in 
comp.os.vms newsgroup before.   .NET is a very logical progression from 
the OpenVMS common run-time environment and calling standard.   it's 
really quite clever, what they've done to isolate many of the system 
dependencies into the framework.  OpenVMS has been dancing around the 
edges of a much more problematic compatibility approach here too, with 
the practice of effectively disabling the GSMATCH processing on 
language RTLs.  But I digress.

As for porting existing DEC/Compaq/HP/HPE/VSI BASIC code containing 
SUM$, DIF$, PROD$ and QUO$ calls, those would be a very small part of 
any porting effort, compared with the scale of an app port across 
platforms.  There'll often be many more OpenVMS services lurking in the 
typical BASIC app on OpenVMS, too.   But if you're ever stuck with this 
problem, here https://www.openssl.org/docs/man1.1.0/crypto/BN_mul.html 
is 's probably most of what you'd need to migrate those calls, and that 
code is even available on OpenVMS.  Or if you're migrating languages 
and otherwise staying on OpenVMS, there are RTL calls.

If VSI should become fabulously rich and massively successful and 
eventually decides to haul OpenVMS forward to OO or something newer 
(OOVMS, NuVMS, whatever), and to migrate DCL from 32-bit to 64-bit and 
to OO, and migrate DEC/Compaq/HP/HPE/VSI BASIC from 32-bit to 64-bit 
and OO or such, there'll necessarily be some changes made.  I'd wager 
that at least an equivalent amount of old app code will fall away with 
gnashing of teeth and consternation as happened with Microsoft and 
their .NET migration, if VSI does eventually migrate the mainline tools 
and APIs over to OO, and rearchitect the GSMATCH into something 
analogous to or better than how .NET can be deployed.   How much time 
and effort any vendor is also able and willing to spend making it 
easier for customers to migrate their apps forward to newer tools 
varies, too.  The easier the app migration, the more restricted and 
more restrictive the move forward can be, too.  Or the larger the 
investment in a one-shot migration sequence, or in what will inevitably 
be a dead-end sequence such as that of Apple and Rosetta.   
Compatibility is not without cost, and the costs only accrue.

TANSTAAFL




-- 
Pure Personal Opinion | HoffmanLabs LLC