This article is more than 1 year old
VMS will be ready to run on x86 in 2019!
Or 2018 if you're brave. For now, we have a boot screen!
VMS Software Inc (VSI), which became the custodian of the venerable OpenVMS in 2014, is getting close to its Holy Grail of running the OS on x86.
HP had decided that the operating system it inherited from DEC was end-of-life back in 2013, but in 2014 signed over an exclusive licence to VSI.
At that time, the company's CEO Duane Harris said VSI's “passion for taking OpenVMS into future decades” would see it ported to Itanium and then x86 architectures.
Early in September, the company published this little-noticed progress update (PDF) and this product roadmap (PDF).
While VSI has been able to keep the versions rolling for HPE Integrity servers (the most recent landed on September 23 and included a new TCP/IP stack and OpenSSL 1.0.2), the x86 rewrite is a slow process.
VSI says x86 support (with an Itanium cross-build) will be available for early adopters in 2018 (on HPE Intel and AMD servers) and will reach general availability in 2019.
A key milestone towards x86 support is compiler support: the company's been working to rewrite the original GEM compiler to the LLVM (low level virtual machine) architecture. Currently, the “state of x86” document notes that the C compiler passes 4,000 of the 4,200 compilation tests in the DEC C Test Suite.
It's finished its makeover of the early boot path, so on x86 and Itanium, OpenVMS always boots from a memory disk, launches without boot drivers, doesn't need to touch the primitive file system and writes crash dumps to the OS's dump kernel.
The dump kernel looks like an interesting way to handle crashes: at boot, a second instance of the OS is loaded into memory but not booted. It sits idle unless there's a crash; at which time, it boots, gets information gathered by the primary kernel, writes the dump file, and handles the shutdown.
Other high points of the work-in-progress include memory management, x86 and Itanium processor modes (x86 lacks the “strict hierarchy of memory access protection expected by VMS”), and paravirtualisation. ®