[Info-vax] VSI: "Official 8.4-1H1 Launch"

[johnwallace4 at yahoo.co.uk]

On Wednesday, 10 June 2015 02:41:58 UTC+1, Simon Clubley  wrote:
> On 2015-06-09, David Froble <davef at tsoft-inc.com> wrote:
> > Simon Clubley wrote:
> >> 
> >> For one thing all the architecture specific code is _very_ cleanly
> >> separated on Linux which makes it relatively easy (compared to VMS)
> >> to port Linux to a new architecture.
> >
> > Well, I think you're missing at least one thing.  I'm guessing Linux is 
> > implemented 100% in C, and if you're porting to something with a C 
> > compiler, that is one big task that you don't have to do.  VMS is not 
> > 100% C, and I for one think that's a good thing, and multiple compilers 
> > must be ported right up front.  Now let's look at those compilers. 
> > Before you're done you're going to need them anyway, because some 
> > customers will need them.  (What good is a port if no customers will be 
> > able to use it?)  So porting Linux and porting VMS really are two 
> > separate types of tasks.
> >
> 
> When you port Linux to a new environment you still have to port binutils
> and gcc first if the new environment is not yet supported by them.
> 
> Once you have the language tools out of the way (and using LLVM is a
> good decision of the part of VSI) the ease of porting the OS depends
> on the OS internal architecture.
> 
> Yes, the fact the Linux kernel is written (mostly) in an architecture
> independent language is a major benefit, but the real benefits come
> from the internal Linux design, including the _strict_ isolation of
> architecture specific code from the rest of the code.
> 
> BTW, I hope VSI are porting multiple compiler front ends but far fewer
> (ideally one) back end(s).
> 
> > I'll also point out that the multiple languages supported on VMS is one 
> > of the strengths of the OS.
> >
> 
> VMS style application level multiple language support has nothing to do
> with the OS implementation language but to do with the design of the OS.
> You can write code in multiple traditional languages on Linux as well BTW.
> 
> I think it comes back once again to observations I've made in the past
> about seeing what can be achieved in other environments and wanting to
> see that for VMS as well.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

You can indeed write code in multiple traditional languages on
OSes other than VMS.

On VMS it is trivial to do and because of the underlying
language-independent standards such as the Calling Standard it
is trivial to make multiple sensible languages interoperate
reasonably well, so e.g. if you have a bit of FORTRAN that
needs to call some pre-existing code in C (or whatever), there
won't be too many issues. The documented standard also means
that 3rd parties can, if they wish, develop conforming compilers
and tools.

Not sure it's quite so easy elsewhere. Possible, maybe.

Even Microsoft eventually caught on to the value of a
language-independent Common Language Runtime (which admittedly
goes a bit further, in some ways, than the VMS Calling Standard). 

And VMS has descriptors, architected in to the OS and many
languages and associated runtimes, and in many languages they
"just work", invisible to the user.

Just think how many buffer overflow bugs would never have had
a chance to exist if the descriptor concept had been widely
used elsewhere. 

Basic string handling? Don't hand code it, don't call K+R
routines (sorry sirs), call the tried tested and proven STR$
routines. And so on. A 17byte string into a 16byte space
returning an error status, rather than scribbling on data
it shouldn't touch, and **almost without the programmer
having to think about it**, what a concept. Amazing.

Chapter 7 of the OpenVMS Calling Standard has far more info.
Maybe there's a simpler intro somewhere too - pointers
welcome.

Someone somewhere out there liked the concept so much that they
implemented their own descriptor-style string handling for C,
which for most people would probably be the most useful chunk
of descriptors' usefulness.

In the not totally unlikely event that readers have played with
dwarflib, they may have come across the "extensible string
buffer" package it uses. It isn't quite descriptors, it's not
as broad as descriptors, but it's potentially far superior to
random DIY or K+R or even their modern allegedly safer
substitutes. 

I like VMS's descriptor concept, especially when cleanly
integrated into a nice language and runtime. If your code
is in C, descriptors are a bit of a 'force fit', but if
your interest is a safer string library, there are places
to look, not just K+R or "safer" versions thereof.