reply to Rick Hohensee (not sent yet -- pine fucked up):

> > Hey, just think:  serial, ppp, ip, tcp, telnet, mail... it ain't that far
> > off, in Forth.
>
> Many deep design issues though. That was 90% of the work of H3sm.
> Original design. Ceiling-staring. Hard.
> I don't have my head around why Linux network interfaces aren't devices.
> I think Forth blocks make a fine VFS layer, almost. I think. Stuff like
> that.

Yeah.  Forth VOCABs for directories, BLOCKs for storage.  Instead of
"open /dev/tty/tty1" you'd do something like "ALSO dev tty tty1 OPEN".
I was talking about this with Jeremy St. James awhile back... In each
vocab you specify what lookup routine to use - one for normal vocabs, one
for disk directories maybe, one that does DNS lookups..  Aztec Forth does
something like that for windows .DLLs.

You're right, there's a lot more involved.. Before I do networking I'll
want a VFS, file handling, and a memory allocator.  TCP sockets aren't
much use if you can't open them as files, I guess.  In the meantime, at
least I could write serial and ethernet drivers, and IP and ICMP.. see if
I can ping my Unix box from Retro :)

 - Tom





VOCAB filesystem
----------------
Vocabularies are equivalent to directories.
Search-order is equivalent to PATH in other OSes.

There can be different types of vocabs... linked lists, trees, hash tables,
in memory; vocabs as file directories; vocabs as 'network neighborhoods'.

The Vocab-fs should provide information needed for direct access to devices
listed in vocabs, in addition to the Unix-style file abstraction.  "Files"
may be accessed directly, memory mapped, as byte-granular files, and as
block-granular files... and maybe other ways.  Screen output is an example
of direct access.


File handling
-------------
Disk files, devices, network interfaces and connections, etc, all interface
to a program via buffer queues.

A buffer consists of a block of shared memory, with variables specifying the
start/end and head/tail.

Terminology:
	"Channel" or just "CHAN"  (from ITS)
	"Queue" (type of data structure used)
	"Buffer" (one of the purposes served)

Need the ability to FLUSH buffers -- write out buffer contents to disk (or
whatever) before returning control.


Standard input/output
---------------------
Normally input comes from the keyboard buffer and output is written directly
to the screen, without a buffer.  When output is directed elsewhere, EMIT
outputs to a buffer.  KEY simply reads a different buffer.

CFAs for EMIT/KEY could be specified in UVARS; call like this:
	0 UVARS #@ EBX MOV,  >EMIT EBX@ JMP,
	(ie, MOV EBX, [UVARS]; JMP [EBX+EMIT];)
