I/O, OLE and hotlinking
-=-=-=-=-=-=-=-=-=-=-=-

Tornado does all disc i/o while multitasking, including when an
executable is being loaded in from a !Run file. Tornado does this by
providing *-commands to load in code while multitasking. A background
operation hourglass appears during this. Also, any i/o operations are done by
Tornado, including serial, parallel, disc and inter-application i/o.
Sometimes the i/o is done without the application's knowledge or involvement.
   For a start, all low-level serial and parallel i/o is done using SWI
Tornado_IOOp. Block gbpb taking more than 1cs to perform gets broken into
blocks and transferred while multitasking, although the calling task can have
the SWI return control instead so full application functionality is retained
(Basic programmers would need this the most - C and assembler images can be
multithreaded in this case). I/o is done using the serial block drivers for
the serial port, and with a specialised replaceable driver for the parallel
port.
   For more generalised use, i/o can be directed at tserial:, tparallel:,
tprinter: and anything else that is added by third-party producers (eg;
tethernet:). For the printer, tprinter: in fact is a FIFO buffer which takes
in input and spits out output to the printer as fast as it can. I/o to
tprinter: is also done while multitasking, unless the app wishes to retain
full functionality. I/o to tserial: actually directs i/o to whatever is the
currently selected serial driver(s) (can be different for different apps).
Also, multiple apps can access the serial port at once, using a system like
the input focus. The access requirements for eg; tethernet: have yet to be
finalised.

That's general i/o. For more usual i/o like disc i/o, there's a different
setup. For a start, applications do not know that a user has requested that a
file be loaded into that application. Nor does an application know if the
user saves the file out of it. Or if the user has OLEd a file currently
loaded in. Or, for that matter, if the application has _any_ files loaded in
at all. [1]
   How is this possible? Well, tornado applications are written to edit one
file and one file only. *Tornado* handles the loading in of _multiple_ files.
Also, tornado applications do not /load/ in files, they rather replace an
existing (possibly empty) one. For example, loading in a tornado app and then
loading a file into that actually replaces the blank file which is
considered to be already loaded in with the one being loaded in. [2]
   This means that the user OLEing a drawfile in a DTP frame simply does the
following:
   * User does OLE special-key & click.
   * Tornado receives this, and checks the filetype of the file loaded into
the frame in the DTP (i)
   * Tornado checks the apps currently loaded in, and sees if any of them can
load the file (ii), and if none are loaded in it checks to see if any
suitable apps have been seen by the filer (iii)
   * Tornado tells the receiving app to *replace* the currently loaded blank
file with this file here, and passes it the address of the file loaded into
the DTP package. It also tells the new-found editor where to open its editor
window if appropriate eg; directly over the frame containing the original,
scaled to the correct zoom factors etc. (iv)
   * From now on, any modifications made to the shared file is accompanied
with a message sent to all tasks with access to that file requesting that
they redraw that file (v)

 (i) Tornado knows the filetype of every file loaded in because *it* does the
loading in.
 (ii) Tornado knows which filetypes each app loaded in can edit (without
conversion) because the app declares them in its Tornado script file.
 (iii) Tornado knows which filetypes each app on disc can edit because they
are declared in the !Boot file of every app on disc. Tornado can build a
'map' of the disc by checking the disc for tornado apps, extracting what
files they can load and compiling them into a list. When the Tornado filer is
written, any changes made to the directory structure (ie; the user moves a
file from here to there) will also update the list. Otherwise, or to save
memory, Tornado can simply register any apps seen by the filer.
 (iv) All files loaded into all tornado apps are stored in a central
reservoir maintained by Tornado, and this lives in RMA. See the appropriate
file about this.
 (v) All files are redrawn by the Tornado renderers, which are available to
all tornado apps. See the approriate file about this.

From the above, you can see how the user dragging a file from the filer to a
tornado app would work, and dragging a file from another app to an app, and
hotlinking a whole bunch of files together. It's even possible that a single
file could be shared over a network eg; an alteration to a file on one
station would affect all copies all over the network (and beyond). This would
allow teachers to monitor what any student is doing.

Note also, that all files loaded in and saved out go through tfs: (if
present). The file is loaded while multitasking into tfs:, and loaded into
the app from there. A file is saved to tfs:, from where it is copied to disc
under multitasking. This ensures constant multitasking.

See also the file about subtasks, as subtasks play a more than notable part
in implementing i/o.





[1] Note that in fact, no tornado application can have a file loaded into it.
The file in fact is loaded into tornado, and tornado passes the editing of
the file to the app the user assigned to it by dragging the file onto the
icon of that app. Ie; the app doesn't maintain its own list of files. Nor can
it distinguish between files passed to it by tornado. When a user alters a
file, tornado informs the app owning the editor window and passes it the
address of the file. The editor modifies the file, and tornado shows any
changes onscreen.

[2] In other words, multiple files 'loaded' into an app are really a list of
files _associated_ with that app. When one is altered, the app is called to
do it. As far as the app is concerned, it can edit one file and one file only
- whatever the file tornado passes to it.

