[Info-vax] DCL, was: Re: Microkernel

[Stephen Hoffman]

On 2012-08-16 23:03:17 +0000,   VAXman-  @SendSpamHere.ORG said:

> In article <k0j9po$bv5$1 at dont-email.me>, Stephen Hoffman 
> <seaohveh at hoffmanlabs.invalid> writes:
>> On 2012-08-16 14:24:51 +0000, Jose Baars said:
>> 
>>> Op donderdag 16 augustus 2012 14:54:59 UTC+2 schreef (onbekend) het volgende:
>>>> You can still specify your OWN CLI in your UAF record!
>>> 
>>> Are there any examples including sources of this available somewhere?
>> 
>> FWIW, I don't know of any.  And I don't see any posted, based on a
>> cursory search.
>> The sys$cli call and the related supervisor-mode APIs aren't officially
>> documented.
>> What documentation that is available here is in the source listings and
>> in the IDSM.
>> DEC/shell and MCR sources never got released, and gnv isn't implemented
>> as a CLI.
> 
> Neither of which would have any bearing on this.  SYS$CLI is merely
> a callback to the DCL handler for things like setting symbols, etc.
> There's no SYS$CLI callback for the DCL RECALL buffer.

If you're implementing your own CLI, then you're probably going to be 
fielding the CLI callbacks and the rest of the supervisor-mode baggage.

> THe issue is a matter of $IMGACT/$IMGFIX and building an image which
> uses these to map DCL.EXE.

Last I looked at this, there was a cha-cha to get the code remapped 
from P0 to P1 space, and some other arcana.

And the new CLI will want to be field the callbacks arriving from the 
sys$cli routine, no?

> You then setup the OOB AST on the control
> character of your choice and read the DCL recall buffer.

I'm not particularly interested in extending DCL and enhancing the DCL 
buffer, myself.  I'll leave that to other folks.  To me, a different 
shell would be more interesting.


-- 
Pure Personal Opinion | HoffmanLabs LLC