The Datafile PD-CD 3/PDCD_3.iso/utilities/utilst/tornado/Info

Text File | 1995-05-25 | 14KB | 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 i