[Info-vax] September 6, 2016 - new Roadmap and State of the Port updates now on VSI website

[Stephen Hoffman]

On 2016-09-10 01:12:58 +0000, David Froble said:

> Personal opinion.
> 
> I think that when you implement an environment on top of another 
> environment, then you're no longer really running executables under the 
> lower (not sure what term) environment.  In this case, if special stuff 
> is implemented in C, then by using it you're no longer running on VMS.
> 
> I also think that if you're going to claim that you're running 
> executables on VMS, then it should always be VMS services used to do 
> things, not some language specific replacement of a VMS service.
> 
> But what do I know ???

It's abstractions all the way down.

It's the OpenVMS services API that are the limiting factor here.    If 
the existing APIs are kept around — it'd be utterly absurd to remove 
all that — and a new (and preferably demonstrably better) API is made 
available and is made the preferred interface for overhauls and wholly 
new development work, then other improvements can be made.  Though 
things will look quite different than what is presently available.

The existing OpenVMS APIs are far more work than some newer designs can 
provide, and for limited and difficult-to-modify and generally 
inadequate results at best.

You don't see the glue code, but when I look at C or BASIC or Fortran 
or COBOL calling OpenVMS services, I see acres of repeated code and 
unnecessary code and all dealing with the OpenVMS APIs.   Those areas 
that don't have that have already some sort of abstraction such as the 
language-embedded file I/O keywords, and the RTL calls were an earlier 
effort to reduce this.   But in the case of system services, it's the 
whole API design that's problematic.   Itemlists and descriptors were 
wonderfully flexible designs for the 1970s and 1980s and particularly 
for folks working in Bliss and Macro32, but we've learned a few things 
since then, and we're also now running on pocket computers with vastly 
more memory and capacious storage and with vastly better performance 
than we suffered with on VAX.

The canonical example of this API migration is Microsoft and .NET, 
though NeXTSTEP (which is now the core of macOS) and other examples 
also certainly exist.

But I doubt that VSI has the staff and the schedule necessary to 
undertake anything of this scale and effort and scope of change.   Not 
for some years.   This'd entail significant work in the operating 
system, as well as in at least some of the compilers and related tools. 
  Given that this work is entirely forward-looking, whether this work 
is even of interest to enough paying customers to matter in any 
near-term revenues?  Probably not.  Which in aggregate means OpenVMS 
falls further behind in this area.  Whether that matters?


-- 
Pure Personal Opinion | HoffmanLabs LLC