Re: Bootcamp

On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:

There are no indicatianos of substantial reimplementation.  Official info says that new or substantially reworked code is in C.  But w also have information that amount of Macro32 and Bliss did not substantially decrease.  So, (almost all) old code is still in use.
It could be that small changes to old code took a lot of time. It could be that some new pieces were particularly tricky. However, you should understand that porting really means replicating exisiting behaviour on new hardware.  Replicating behaviour gets more tricky if you change more parts and especially if you want to target a high level interface.

You're correct. Reworking existing working code is quite often an immense mistake.
It usually fails. If not always fails.
And bringing a source-to-source translation tooling or an LLM can be helpful, and can also introduce new issues and new bugs.
About the only way a global rewrite can succeed — absent a stratospheric-scale budget for the rewrite, and maybe not even then — is an incremental rewrite, as the specific modules need more than trivial modifications.
Reworking a project of the scale of OpenVMS — easily a decade-long freeze — and for little benefit to VSI.
Some bozo once wrote: "...VSI spends years creating an inevitably-somewhat-incomplete third-party Linux porting kit for customer OpenVMS apps, and the end goal of the intended customers then inexorably shifts toward the removal of that porting kit, and probably in the best case the whole effort inevitably degrades into apps ported top and running on VSI Linux. Or to porting to and running on some other not-VSI Linux. That's certainly a service business opportunity,  providing customers assistance porting their OpenVMS apps to VSI Linux.  It does get VSI out of maintaining a kernel, but does not reduce much else. And that at no small cost and no small investment, and at a cost of a number of other opportunities..."
Yeah, I'm sure some customers would like assistance porting their native OpenVMS apps to native Linux, but that's already an opportunity for services organizations, albeit without the code sharing.
And I'd be willing to bet money VSI will need a number of modifications to the Linux kernel, too.  And the new OpenVMS kernel will then have to be maintained on an ongoing basis, and it'll have to comply with GPL2 and potentially other licenses. If you're going to dream, maybe to to seL4 or some other kernel intended for this sort of thing.
But again, this has all been discussed before: https://groups.google.com/g/comp.os.vms/c/1etAx5jJoNM/m/nUY5infiAgAJ
--
Pure Personal Opinion | HoffmanLabs LLC