Mail Archives: opendos/1997/05/02/15:23:19
On 1 May 97 at 6:43, -= ArkanoiD =- wrote:
> > Anything else? Let's brainstorm, here :)
I'm still keen on the power to attach code to the interfaces of a file.
For security reasons, we must not have code that is executed without
the file being explicitly nominated - ie, nothing that is executed
when a file is merely /seen/ in a directory listing, or else we
would have a flood of virii, like RISCOS suffers from.
Consider the OO approach: a file has a set of methods. Leaving
them empty means that the default behaviour is inherited. New
behaviour inserted in there means that the file overrides the
default behaviour, and can still call back to it.
Methods could be (parameters in brackets):
- Open (for reading or writing, by whom)
- Delete (by whom)
- Gimmee search keywords
- Gimmee an icon
.
.
. or just:
- Gimmee data (tag name)
Now, how to implement this "attached code"?
Well, one way is to nominate monitor DLLs with a field
in the file's directory entry. This introduces a fair
amount of loading overhead to drag the monitors around,
though.
Another way is to have standard COMMAND.COM commands in text
fields. This isn't quite as powerful, but will be quicker;
all it involves is passing the string to COMMAND.COM. Quite
often the command will simply invoke a small program which
does the real work, but simple things such as access logging
can be acheived with:
echo | time >> $LOG$\$HOST$.log
Where HOST is an environment variable automagically set to
the name of the owning file. Note that I assume a LFN filer,
since the resulting filename will be like "autoexec.bat.log"
:-)
Another approach is to go for a proper scripting language
in the kernel. FORTH would be good for this since it's
very compact.
ABW
--
Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk)
---<## OpenDOS FAQ ##>---
Plain HTML: http://www.delorie.com/opendos/faq/
http://www.deltasoft.com/faq.html
Fancy HTML: http://www.deltasoft.com/faq0000.html
- Raw text -