[Info-vax] Message from HP.

[gce at gce.com]

It seems unlikely that there is sufficient expertise at HP to do a port of VMS again without significant growth to its VMS engineering group. The codebase has been ported twice now, so it's a bit easier to do than the first 2 times, but since the path has been in part to compile macro2 and Bliss (and there was a lot more of the former) a new compiler backend would be needed. The old work on x86 did not get far, and would need heavy rework even if its code can be located any more, since it would make sense only to target x86-64. 
More importantly, though, even if you could get the whole VMS function base to work on x64 iron, it would remain a niche sized system. Consider that a new filesystem is obviously needed now, if only because single disks twice the size ODS5 can support are readily available now, and that will get worse. I am reminded of the kludges DOS-11 used when block count exceeded 65535...
Beside that, new drivers are needed for current other peripherals and that's hard to get support for. The Windows model is closer to that of VMS (since it descends from it (morganatically?) but replicating a closed source model like that looks impossible to me. 
Other generic application code also is handled differently in VMS from other systems. There have been efforts over the years to find ways to support other OS functions (most notably unix fork) inside VMS. Today I suspect that it would make more sense to try and support VMS specific things on top of some other system, Linux being one I would consider first. That would be an interesting effort, to bring in ASTs, forks, DLM, and also a usable ODS compatible filesystem and record handling system in. Figuring out some way to run VMS
binaries (unless by emulation) on x86 would be no piece of cake either, so at best you'd want to be able to rebuild sources.
  I am hard put to imagine why anyone would want to bring ALL the nuances of RMS over anywhere else - there are loads of odd capabilities in there - but something that would handle 95% of the cases and 99.99% of what is used is likely doable. 
  This does not sound like something a corporal's guard tasked also to fix any bugs found and to try to keep existing VMS running with some current peripherals is likely to have spare time to do. And if done, would HP promote and sell it, when their promotion of the current VMS capabilities even in areas where data integrity and security are key has been so lacking?
  It would be perhaps more useful to get together lists of functions that exist now only in VMS, and see whether outsiders might be able to recreate them elsewhere with some value enough to justify the work.

(If HP gives up on VMS, it would be most decent of them to open source the VMS sources, as much as they can, but any third party would have to figure out answers to the above anyway, and I suspect what might be needed can be done currently by third parties if they had justification to do it.)

Glenn Everhart