The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/Old/Info

Text File | 1995-05-25 | 13.3 KB | 235 lines

Introduction to the Tornado application standard:

 - a proposed method of making writing Wimp apps like riding! (but what!) :-)

by N. Douglas

In a nutshell, Tornado can be described as 'a Filecore for Wimp apps'. It is
designed to force a standard look onto Wimp apps, while simultaneously making
writing easy, and enhancing life for the user.
   It is a development of RISC-OS that has long been coming, but something
Acorn aren't too keen on changing. They prefer developing their precious
SharedCLibrary, while ignoring the greater good of developing RISC-OS.
   Tornado will also function as a library, a filing system, and general
support. It is intended, that if it ever gets finished, it will form a large
part of RISC-OS's to come, whether Acorn likes it or not.
   <Rousing statement>: Tornado will allow the RISC-OS platform to once again
assume the cutting edge of OS technology, showing what a _real_ OS can do.
Forget Windows '95, forget X. Tornado, when finished, will increase user
productivity to an extent that *the* techie platform will only be the Acorn
one.
   Ok, whether you believe that or not, keep reading. I think you'll find
many of the features described here exciting, if nothing else.

   This document intends to describe what this is all about, and to drum up
both support and writers. Anyone can join in, and write for Tornado. Right
now, we need coders for Part A, the support backbone. They have to be pretty
compentent in Assembler, as the vast majority of this section will be in
assembler. Some parts may be in C (without ANSI libs), but little in Basic.
The end product will consist entirely of C or Assembler, with no Basic
(unless someone finishes the BasicSWI coding!).

Part A: Support
   In this branch are the low-level facilities provided by Tornado. Upon
these facilities the rest of the standard hinges. It consists of the
following:
   *  Heap+: This is an extension to the OS_Heap standard, remaining backward
compatible with OS_Heap style heaps, but adding the important element of
relocatable blocks and automatic garbage collection. Tasks claiming blocks
can choose either (a) fixed blocks or (b) shifting blocks. Type a are given
handles pointing to their position, ala OS_Heap style. Type b are given
negative handles, and before each access a Tornado_Heap+ SWI must be called
to retrieve the address of this block. Any data within this block _must_ be
relocatable at all times. Anyone wishing to see in more detail this heap
format, see the Basic test program HeapExt.
   *  TornFS: This is a r/w filing sytem holding its data in RMA. Every
Tornado task, after calling Tornado_Initialise gets an account in here, and
all files/Heap+ blocks have associated filenames in the accounts. IE; when a
app claims a block, a new file is created in tfs:, although the actual data
within the file is actually stored in a heap+ after the main code of the
task. All filing system operations can be done on this file (and the block)
as usual, as the data is accessed using Wimp_TransferBlock (which means
we'll be needing tfs: as a module task). Odd? You'll see why it's so
advantageous later.
   *  Wimp and misc utils: These include little things that always prove
themselves really vital. These routines could possibly be in C.
   Ok, for a start programmers are needed for:
      Preemption: Done, but needs tiding up, and extending so it stores the
codes it receives, and can regurgitate them later.
      General Wimp utils, like that supplied with DeskLib: These need to be
recompiled into module format, and accessed through a SWI interface.
      Accessory sub-tasks: Ah, this is interesting. The idea is this: a task
wanting to do some heavy processing, schedules a subtask. This subtask is a
program in its own right, a 'black box' if you like. It takes in data, and
spits out data. Here's how it works:
         Tornado task calls Tornado_StartAccessoryTask, pointing to the input
data and output data (in tfs:). The task called is an actual program, and it
will be called using *Run <taskpath&name> %0 %1 %2 etc. The program may
reside in the home dir of the task, or if frequently used (option in option
window) could reside in tfs:.
         Now, what happens is this: If there is only one processor available,
the subtask is run. The subtask calls Tornado_InitialiseSubTask, which in
this case starts the task up as a wimp app, and starts preemption too. The
subtask runs along, does its stuff, and exits with Tornado_ClosedownSubTask,
with the data processed. The subtask is exited, and the originator task is
told the data is finished.
         Second processor: The subtask code, and its data in/out, are copied
to the 2nd processor's memory, where a Tornado subtask server is running.
Same as above, except maybe without the Wimp getting involved and instead
preemption between multiple tasks occuring, ala VAX VMS style. Finishes as
above, except the results are copied back.
         Remote processor: this could be on the Internet, or on an Ethernet.
The subtask & data is copied over the network(s), to a server running on the
remote machine. As above, is copied back.
         A lot of work, but for now we only need the local processor option.
Not too difficult.
      Internal sub-tasks: a piece of code is called on every poll, and this
does the required job in bits. This may detract from the processor time the
task receives, or maybe not.
      Load/save routines which work under interrupts: Done, but need tidying,
and I'm not happy enough yet. The code should be able to intelligently guess
the ratios required for optimum access depending on the media being accessed.
We'll need a list of access speeds and transfer speeds to do this properly.
      Processor priority program: I think this can be done by having Tornado
send a Wimp_SendMessage no. 0 on every poll. This would double the processor
time the task gets. Or triple, quadrouple, etc.

Ok, this is the really dreary bit. Hard work, little gain. Anyone doing work
here can release the code seperately as a stand-alone version too, if they so
wish. But please read the Readme file first.


Part B: Tying it all together
   Okay, now we start having fun. With the foundations laid, the real fun
stuff starts. It's also probably the hardest and longest bit here, and will
take months of coding. Here is the major preliminary stuff, blow by blow:
   *  Automatic loading: Essentially, a user drags a file (either from filer
or another app) onto something belonging to the task. Tornado loads/transfers
the file into tfs: (multitaskingly if necessary, like it's a slow medium or
a network).
         NOTE: If the file format loaded in isn't a one the app can handle
(eg; loaded=GIF, task can only take Sprite), Tornado may first translate the
file into one the task can understand.
         When finished, Tornado sends a Tornado_Poll message to the app,
indicating which window etc. The task then allocates its own block (which
also appears in tfs:), and copies/loads the file into it. The task recalls
Tornado_Poll, whereupon the original is deleted.
         OR: The task can ask for the block to be preserved, and schedule
either (a) an external subtask to do the processing or (b) an internal
one. Or, if it's lazy, it can ask for preemption on its code (not approved
though!)
   *  Automatic saving: You can guess it from the above.
   *  Automatic OLE: Picture a nice Draw file in a Tornado DTP package. It
sits in its frame, beautifully. Then, the user double clicks on it while
holding down Shift (ala Filer=>Edit style), having noticed it's OLEable
because the pointer changed when it moved over it, and when the user pressed
Shift a double-click pointer came up etc. etc. Tornado gets the OLE request.
It then (optional) returns via Tornado_Poll, asking for preparations. Then it
copies the file out of the tasks heap+, into a tfs: OLE file. This is
DataOpened. Draw, currently loaded (or if not, Alias$RunTypeXXX is done),
picks it up and loads it. User edits. User opens Draw's save dialogue, clicks
on OK. File is saved back to tfs:, where Tornado notices the changed
filestamp, and recopies it back into the task's original block, extending it
if necessary (OR sends a Tornado_Poll and asks the task to do it).
        Obviously the task must firstly store that sprite in its own block,
and indicate that it's OLEable. This is done via Template files and the
indirection attached to each icon. This hasn't been defined yet, but further
details are available on request.
   *  Automatic hotlinking: Not only is every Tornado application hotlinked
to the Tornado application manager (more later), but files out of one
application can also be hotlinked to another. Consider it a new view of one
file in a task put into another task. This allows a spreadsheet's data to be
graphed by a seperate app, without extra propriatary code. Also, any graph
package can be used, not just one.
   *  Tornado application manager: This is a centralised manager, which
essentially replaces the Task Manager. It will offer various graphs of task
memory and resource usage, how much processor time each task is getting etc.
etc. It will also allow the user low-level control over each app, whether it
be directly tweaking files, shifting data around, sending test messages etc.
The Tornado application manager will be the friendly frond-end of the Tornado
resources, and will extend RISC-OS to the extent that it will once again
become the cutting edge of OS technology, like RISC-OS 2 was in its heyday.
         It will also allow global options to be set, like all Tornado apps
should use outline fonts, all should preempt operations etc.
   *  Smaller, not so major things. For example, the standard Tornado app
option window will have a pane updated exclusively by Tornado, and will be
common to all apps. All icons will automatically have 3d borders, slabbing
icons, changing mouse pointers etc. Automatic interactive help, although it's
use shouldn't be necessary if the task is done right, it may be useful for
larger apps. Proper error windows, which don't hold up the machine, and
display more meaningful messages, and will tell you to RTFM if you ask! :-).
Rendering SWI's to draw Draw files, text files, sprites - all major file
formats, and all automatically if so wanted.
         A standard method of communicating between tasks, so that things
like eg; in the DTP you say this pane should contain the address of one Niall
Douglas, it broadcasts the request, and waits for a reply (ie; polling
doesn't stop). A database picks up the request (because Tornado would have
routed the request to databases only, and if one wasn't loaded it would load
one in), searches all the files it has loaded (if it can't find any,
depending on user choice, it may then start searching the hard disc and/or
attached networks, looking for and searching any files it finds that are of
it's filetype), and if it finds such an entry (or if more it pops up a
dialogue window) it then inserts the data.
         Obviously, this is quite a fair bit away. But, the point is, the
framework should be laid as so to make this possible at a later date.


Above all, the design of Tornado is to increase productivity, although at
initial programmer expense, the result will be a fast, responsive,
and above all a productive machine. If it works, it shall be seen how this
will improve life for Acorn's everywhere. Later, it should be possible to
implement a 'Tornado stamp of approval', whereby commercial vendors wanting
to ensure their customers know their product is good, will apply for
approval (of course for a suitable fee), whereupon a Tornado member will
review the product, decide whether is passes or not, what faults it has, and
will then reply the findings to the vendor. This way, Acorn users will /know/
if a commercial product is as good as it is hyped. No AU to mislead us! :-)

Well, that's it. Some data is included in this archive, and it is subject to
the restrictions in 'Readme'. Any questions, ideas, or complaints! to
Niall Douglas@fidonet#2:257/501.13, or [e-mail].

Cheers,
      _
|\ | | \
| \|.|_/.



Already defined structures (not fixed!):

Structure of tfs:
$.[Internal]        - always present
$.<appname>        - dir, containing the account of the task
$.<appname>.[Data]    - contains data about app, as held by Tornado. Eg;
task handle, what things it wants automated, etc.
$.<appname>.<filename>     - dir, containing data for that particular loaded
file.
$...<filename>.Master    - contains main data of that file
$...<filename>.SubfileX    - contains a subfile, like the above sprite in a DTP
frame.
$.<appname>.Claims    - dir, containing any Tornado_Heap+ misc claims, ie;
those not directly related to files.
$...Claims.<descript>    - a particular claimed block. BTW, the <descript>
comes from a descriptor string passed to Tornado_Heap+ [Claim block]. It can
be as awful as '0', or something better like 'pollingblk'
$.<appname>.OLE        - dir, containing files currently being edited under
OLE.

[Internal] file:     (each rec 64 bytes)
+00:ptr to full app name, as passed to the Task manager
+04:ptr to list of filetypes the app can load. Important, as if the app can
only load sprites, and a GIF file is dragged to it, Tornado may be able to
ask another loaded task to translate (eg; ChangeFSI).
+08:ptr to list of filetypes the app can save. This may be augmented by
Tornado if something like ChangeFSI is loaded. Eg; if it can save sprites, it
can also save GIF's, TIFF's etc.
+12:task handle
+16:flags
+20:more flags
+24:still more flags
+28 to +60:reserved

[Data] file: not defined yet.