[Info-vax] Compatibility, Porting, Migration

[DaveFroble]

Stephen Hoffman wrote:
> 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

True

IIABDFI

(If It Ain't Broke, Don't Fix It)


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