<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Mon, 29 Mar 1993 10:30:26 +0100 (BST)
From   : "I Stephenson" <ian@...>
Subject: A new OS layer?

>At its simplest I'm thinking of something that intercepts file
>opens/closes/reads and writes so that screen output can be redirected into
>file, and keyboard input taken from a file. This is imply implemented by
>trapping all such calls, and then (for example) printing or writing
>as appropriate.

>But this is already supported through *spool/*exec more or less. Instead of
adding to the OS new calls, at the very most patching onto the old ones will
do the trick.

The problem with *spool/exec is that they can't be used recusivly. A batch 
file can't contain another batch file for example. I agree that idealy it
would be better to intercept the current OS vectors but that could get a
bit messy. For now I want to keep things simple.

>What would need to be done is to build into *pipe information on where various
programs get their input and output from.

UG :-(

>Oh, well, that was a poor example of how *exec and *spool could be used but
you get the idea. Is this the sort of thing you are thinking of, or do you
have something far more ambitious in mind?

This is part of the basic functionality that I want, on which more can be 
built. I've been spending an hour most nights for the last week trying stuff 
out (6502 hacking is fun - I haven't done any for ages!). The result so far
is a CLI which will support comments, star commands, and recursive batch
files. I have a file on disc called "ls" which contins the text

#Catalouge a disc
*cat

The program is in two parts - the shell and the OS layer which traps writes
to channel 0, and redirects them to the screen (and simlarly for reads).
Addig pipes and redirection to the shell is then easy.

I'm currently considering how to handle executables. Seeing as relocation 
is difficult, I'm considering dumping the running image to disc before loading
the new image, and then retoring it afterwards. The problem with this is
for compiled code which uses a stack in a distant part of memory from the
main program.

Ian
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>