OpenVMS State of the Port to x86_64 [pdf]
vmssoftware.com
OpenVMS State of the Port to x86_64 [pdf]
1–10 of 108 posts
Re: OpenVMS State of the Port to x86_64 [pdf]
#2Who, and why?
Re: OpenVMS State of the Port to x86_64 [pdf]
#3Who, and why?
I think at this point they are mostly targeting servers and not bothering with things like web browsers.
Re: OpenVMS State of the Port to x86_64 [pdf]
#4Who, and why?
Windows NT was a spiritual successor to VMS, sharing a father in DEC's Dave Cutler. VMS fell out of use and is widely considered history. Still, it had some interesting ideas and I've always preferred my history to be living.
Re: OpenVMS State of the Port to x86_64 [pdf]
#5Who, and why?
A few companies like IKEA and Indian Railways, as well as a bunch of healthcare companies.
As for why, because it works really well. It's not new and shiny but it doesn't break, it's fast, and it has a lot of nice features that still aren't common (clustering and RMS being the two big ones).
Re: OpenVMS State of the Port to x86_64 [pdf]
#6Who, and why?
There are still a non-trivial pile of organizations out there that rely upon VMS. I still can hardly believe it myself when I run into them, but as I understand the situations when I ask out of curiosity, these are relatively lower-margin organizations, and the cost of rewriting their VMS applications for them greatly exceeds the cost of adopting a platform that is a port to a major chip architecture and emulating the older chip architecture on that new chip when needed.
Generally, a rewrite places the organization's ongoing processes at huge, disruptive risk, because the existing application and its configuration accumulated all the corner cases earned painfully in the past (often stretching into decades of accreted domain knowledge). Forget the cost of the technical effort to rewrite: even if that were zero, the business impact to take on all the costs of relearning even just a quarter of those lessons in even just a five year project is excessive.
Re: OpenVMS State of the Port to x86_64 [pdf]
#7OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.)
This should be interesting when they get done. OpenVMS had a reputation of not going down and having amazing storage clustering. I found it a bit odd when I used it in college and years later on a job. I wish it had been open sourced, but I guess it makes me feel good to know it’s still going regardless.
Re: OpenVMS State of the Port to x86_64 [pdf]
#8Who, and why?
I hear that VMS is one of those OS's that got its concurrency API done right (BeOS would be another). Windows NT inherited a lot of that. To give an example, POSIX compliant asynchronous I/O on Linux is not that great (it used threads internally). There is also non POSIX async I/O on linux. But these are fare less mature and time tested and over all not a very uniform API.
Re: OpenVMS State of the Port to x86_64 [pdf]
#9Who, and why?
OpenVMS is more reliable than Unix, and bears a more sophisticated kernel design intended to handle real-world workloads. In particular, unlike every extant Unix except Solaris, async I/O is handled the correct way in OpenVMS (and Windows NT), with real async system calls and completion-based notification.
Re: OpenVMS State of the Port to x86_64 [pdf]
#10Who, and why?
Windows NT was a spiritual successor to VMS, sharing a father in DEC's Dave Cutler. VMS fell out of use and is widely considered history. Still, it had some interesting ideas and I've always preferred my history to be living.
My question is, which of those "interesting ideas" didn't end up in Windows NT? Is there anything other OSes (Linux, ⋆BSD, macOS) could learn from VMS, that they can't better learn from WNT?