[Info-vax] Learning VMS application programming

[Stephen Hoffman]

On 2014-09-07 15:57:18 +0000, David Froble said:

> As Steve mentioned, DEC had to revise or replace the C-RTL to make the 
> routines safe for inner mode code.  Just too bad they chose to do this 
> with C, and not some other language(s).

There's a second and subset and parallel version of the C standard 
library known as the kernel-mode C library.   
<http://labs.hoffmanlabs.com/node/769>

This to avoid using or sharing the heap for memory allocations, which 
is insecure and variously not available.  (How can all the VMS common 
language environment languages share the same virtual memory pools?  
That sharing doesn't work so well mixed-mode programming, where that 
sharing means user-mode pool corruptions might tip over or expose 
vulnerabilities or open up exploits into the kernel-mode code.  There 
are different memory pools in kernel, and different routines to access 
them.)

The astute reader might notice that there is no malloc nor free call, 
which are typical of C memory management routines.  When using C in 
kernel mode, you're using the kernel memory management routines.

> Or, if that was too obscure, "your Fortran RTL contains routines that 
> should not be used in inner mode(s)" ....

Various of the languages can generate calls to OTS and other libraries; 
it's not just the Fortran RTL.

> It's not the language, it is the "implementation" of the language.

C being a portable PDP-11-ish assembler, didn't involve generated 
object code that was calling supporting routines outside of those in 
the language's library; the C standard library.  Being assembler-ish, 
it was already doing the sorts of things that an operating system would 
be doing, too.   Which means you're dealing less with the compiler, and 
thus largely with C kernel mode library and with adding the 
hardware-specific extensions.

Not sure I'd want to tangle with the constraints of Fortran pointers 
when accessing VMS kernel data structures, but that's another 
discussion.  Yes, it'd be technically possible to extend the Fortran 
compiler implementation and definition to make this access easier 
(e.g.: a Fortran version of a void * pointer), as well as adding the 
bitlocks and queues and related extensions, but then we're back to the 
difference between what's technically feasible, and what's reasonable 
and practical and in the best long-term interests of the vendor and of 
the majority of the product users.

Fortran is very good for scientific computing.  It's not so good at 
text processing, nor for operating system kernel development.




-- 
Pure Personal Opinion | HoffmanLabs LLC