[Info-vax] DCL and scripting

[Simon Clubley]

On 2018-12-12, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2018-12-12 13:38:41 +0000, Simon Clubley said:
>
>> The biggest thing for me is that John doesn't seem to think there's a 
>> major conceptual problem with inserting C code into DCL, even given 
>> DCL's unique requirements.
>> 
>> If you can get C code into DCL, I wonder if that could be used to fix 
>> up other DCL issues.
>
> C is available in kernel mode, and using, the so-called kernel CRTL.  

Yes, I know, but that API had to be added to VMS before it was
possible to use C in the kernel.

Likewise, the use of C within DCL was interesting because I didn't
know if the use of C within DCL was even possible without adding
support for it. As John has said, it is already in use which opens
up various additional functionality options in the future.

> Some C library functions are and others can be implemented in the 
> kernel CRTL fairly easily, while other functions?typically thise 
> involving system calls or RTL calls not directly available in kernel 
> context?are much more difficult to provide in the kernel CRTL.  And 
> those are usually omitted.
>

I've written a C language kernel device driver so I have a feeling
for what you can and cannot do (although it was a long time ago).

>> For example, we know from previous discussions the line editing code in 
>> the terminal driver is an unmaintainable mess, so we can't edit command 
>> lines which are longer than the terminal width. Could the problem be 
>> worked around (at least for DCL) by placing line editing code into DCL ?
>
> DCL can't fix a terminal driver limit.
>

No, but it can do what bash on VMS does and provide its own functionality.
Even better, it could be turned into a library so that everyone else
could use it as well in their own programs.

> The terminal driver keeps one (non-wrapped) line around.  DCL already 
> keeps the complete command line in its history, and works around the 
> terminal driver limit.
>

But doesn't allow you to edit multiple lines on a long command without
deleting enough of the command to force it on to one line.

> As I've commented elsewhere, the changes permissible within the 
> existing class and port terminal driver stack are constrained by the 
> expectations of upward-compatibility.  It's difficult to retrofit 
> changes into this and similar environments, as it's very easy to break 
> (some) existing code with changes to documented or even to undocumented 
> behavior.
>

I've never seen the VMS source code so I don't know the answer to
this, but is the terminal driver line editing code unmaintainable
because someone tried to be "clever" when writing the code and hence
caused maintainence problems later on when changes were required,
or was it simply that someone tried to fit something into the kernel
that should never have been placed in the kernel in the first place ?

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world