[Info-vax] C... the only winning move is not to play...

[Stephen Hoffman]

On 2014-02-12 21:07:27 +0000, JF Mezei said:

> Although I believe it was Mr Hoff who stated that those routines are 
> not well suited for use at elevated levels.

Other than that the RTL calls generally don't work for and are 
otherwise unsuited for use from inner-mode code, sure, have at.
In an eon or two past I would have preferred a hard error be returned, 
alas the maintainers decided to jam the access and allow the code to 
run, albeit with exposures.

> However, when you look at lexical routines availabe in DCL, wouldn't 
> those use underlying RTL lexical functions ? ($FAO comes to mind)

The SYS$FAO and SYS$FAOL system services, you mean?

> Or is the distinction here between SYS$ and LIB$ routines ?

Many eons ago, system services were theoretically all accessible from 
kernel mode at IPL 0.

Some system service calls were documented as being caller's mode 
services, which meant the VMS code didn't need inner-mode access.  
IIRC, $FAO[L] is caller's mode.

Many other system service calls did and do need inner-mode access.

Many of the classic and most common system services are part of the 
kernel, and those can generally be called from kernel mode code at IPL 
0.  Though for various calls, the inner-mode code might choose to 
directly invoke the entry point "behind" the system service (usually an 
EXE$ or a more recent EXE_STD$ call) and bypass the system service 
entry point entirely.  This to avoid the overhead of the system service 
entry checks.

The run-time library calls were intended for user-mode use from user- 
and third-party- and DEC-written applications and compilers and 
related, and the system services provided features for the callers via 
entry points into the operating system itself; IIRC, the entry vectors 
used to be in system S0 space, but moved to process P1 space an eon 
ago.  System services were the foundation of the environment.  RTL 
calls didn't need to reside within the kernel and could be loaded by 
applications and processes as needed, and usually didn't need to 
execute in inner-mode.  (The RTL calls that were originally found in 
VMSRTL were split apart at V4, dividing the various calls into specific 
separate shareable images based on their function — this because the 
classic VMSRTL was becoming unwieldy for everybody involved.  No sense 
loading this increasingly-ginormous omnibus everything RTL into your 
address space, when all you needed were this subset of calls from a few 
smaller RTLs.  Yes, installing the shareable images as shared did help 
reduce memory use here, too.)

Things have gotten more complex and the demarcations murkier and the 
kernel both rather more and somewhat less modular.  Compromises, etc.

Over the years, there became some system service routines here that 
weren't accessible for any of various reasons; usually involving 
implementations via user-written system service interface — those calls 
are generally not callable from kernel-mode.   The ones I stumble into 
most often are the security system services, and particularly those 
that are implemented in SECURESHRP.EXE image.


-- 
Pure Personal Opinion | HoffmanLabs LLC