[Coco] Re: Data Modules (From:(Nitr)OS-9 and path numbers in MWC)

Joel Ewy jcewy at swbell.net
Mon Dec 4 11:05:29 EST 2006


Jeff Teunissen wrote:
> ..
> Also, has anyone thought of using a per-user data module for mocking up an
> environment space? Say, an 8K module named ENV<uid> that would be read from a
> random or sequential file by the Shell (or LOGIN, on multi-user systems) to
> hold shell variables like the PATH, Multi-Vue information, the user's "home"
> directory, etc.
>
>   
    I think that's a pretty neat idea, though 8K would probably be way
more than you'd need for setting a few environment variables.  Of course
it would take up an 8K block if it was loaded individually.  You could
always put it in the bootfile, but that might feel a bit too static for
environment settings.  It could also be merged with frequently used
commands and loaded just after login.  But then it would probably be
loading too late to initialize the user's shell.
    It would be nice if this facility were complemented with a nice
utility to easily create data modules -- "The Modulator".  Simulated
command lines:
modulate <env.txt >env.dat
modulate -d <env.dat >env.txt  [-d = demodulate option]
modulate -t dd <dd_720k.txt >dd.dd  [-t dd = type, device descriptor]
modulate <icon.vef >icon.dat

    Of course the format and contents of the data will be
application-dependent.  But one could specify simplified syntax for
building device descriptors for RBF and SCF drivers, so you wouldn't
have to put all the header info in.  Something (roughly) like:
manager=RBF
driver=nohalt
cyl=$80
sid=$2
dns=$3
...

    If one were going to go to the trouble to do something like this, it
would make sense to make gshell get its configuration data from the same
module.  What other settings could be squeezed into it?  The more use
you can get out of it, the more it can be justified taking up RAM.  I
guess you could have the shell load the module, get the information out
of it, and then unlink it again, so it isn't taking up valuable memory
after it's no longer needed.  But then it could just as easily be a text
file on a disk.  I guess that making it a module would be of benefit if
you are intending to run a ROM-based system.

JCE




More information about the Coco mailing list