[Info-vax] VMS porting/rewrite, was: Re: [OT] Wirth style languages, was: Re: Obscure Ada compiler vendors?

[Stephen Hoffman]

On 2013-04-10 03:03:39 +0000, Craig A. Berry said:

> In article <kk11j5$etr$1 at dont-email.me>,
>  Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>> 
>> These are two separate issues and people are mixing them up.
> 
> No, actually, you seem to be the one mixing them up.  The reason that
> previous ports to new architectures have come up more than once in this
> thread is as a measure of scale.  Whenever OpenVMS Engineering was
> faced with getting VMS running on a new architecture, they considered
> rewriting major portions of it, but rejected that option.  Whatever
> difficulties there were in porting MACRO and BLISS (and of course the
> first time, converting MACRO from an assembler into a compiler), moving
> firmware functionality into the OS, messing with scary exception
> handling differences, and other porting challenges, doing those things
> was always less expensive, more achievable, and more compatible than
> undertaking a major rewrite.

Yep.

If you're going to do this, then ports are far smaller and more manageable.

Three to five years last time, depending on how you want to measure the 
project.

That was with staff from the team that was then-maintaining the OS, too.

Wholesale rewrites of an OS are always massive projects.

That'd be a decade or more for something like VMS, if you're starting 
from scratch.

That'd be with a paid, full-time, OS-experienced team.  Rewrite 
estimates traditionally tend to be low, too.

Less, if you have a good kernel to start from.

The downside of a reimplementation is that a proper feature-compatible 
reimplementation of VMS would then be ~45 years old.

We've learned a few things about kernels and security and 
multiprocessing since the 1970s, and we'll learn a few more in the next 
decade.

Put another way, if you're going to the cost and effort of implementing 
a wholly new kernel, then you need to use newer mechanisms and tools.

And those newer mechanisms and newer tools won't be entirely compatible 
with VMS...

It'll be VMS-like, or VMS-compatible, or some such.  But not VMS.

And once you go there...  Why would folks choose to migrate, either 
from VMS, or from something else....

Which gets into "who's the audience for this port/rewrite?" question.

> Those were major challenges, but tiny in comparison to the suggestion
> that an independent group of volunteers could rewrite it all from
> scratch without access to HP's source code.  I'm all for rewriting it,
> but steadily, incrementally, as new capabilities or new target
> architectures make it necessary.  It would be nice if HP would do that.
>  It would be nice if HP would let someone else do that.  I will
> continue to hope for either, but expect neither.

Even an incremental rewrite is still a large project, still a very 
complex undertaking as you're overhauling or creating new compilers for 
Macro32 and Bliss, you're doing a new memory manager, and anything of 
this scale inherently requires a foundation and testing and 
bug-tracking and project oversight and a whole host of other details 
and committees and baggage and bletch, but a port is still much more 
manageable and much smaller than a wholesale rewrite.

Clair Grant wrote a good overview of what was involved last time, when 
HP ported OpenVMS to Itanium.  
<http://www.openvms.compaq.com/openvms/journal/v6/porting_openvms_to_integrity.pdf> 


One of the closest similar projects in recent times is Apple and 
NeXTSTEP, and what became OS X.  See 
<http://en.wikipedia.org/wiki/History_of_OS_X>, et al.  This 
kernel-swap wasn't as large as a ground-up kernel rewrite as it started 
with existing software and an existing kernel, though was still a very 
large effort.

-- 
Pure Personal Opinion | HoffmanLabs LLC