What is different about tornado II?

So what are the differences between tornado I (which most of this site still describes) and tornado II?

Tornado now is written in C and portable across a multitude of platforms
Tornado runs under another GUI system ie; as a subsystem of the host GUI
Tornado applications now actually run as programs under the host GUI (via recompilation) but use a thunking layer provided by the tornado server to (a) remain portable (b) interact with the host system and other tornado applications and (c) to use tornado server provided functions

However, these rather radical changes do NOT change the ethos and philosophy of tornado - which is reflected still by these pages. What it does do is radically alter the scope of tornado and indeed the potential of completely portable applications truly becomes a reality. Unlike Java, which suffers from adhering to what is currently commonly available on the various GUI's, tornado redefines what is available on all GUI's and thus does not suffer from outdated methodology.

How the new tornado II works?

Tornado II is based on a client/server relationship. Applications written in C are compiled with a set of common standard tornado header files which binds library link information into the executable. This then means that when the host GUI executes the program, the shared tornado library routines are made available to the program and thus the program now becomes a client.

But a client to what? For tornado II programs to interact with each other properly and provide the facilities shown at this site, a server also runs on the host GUI. This server provides various common facilities used by tornado programs - but not available on the host GUI. So, for example, here's how a window belonging to a tornado program is redrawn:

Host GUI sends redraw window request to tornado program
The tornado libraries (statically or dynamically binded) who provide much of the thunking layer are the ones who receive this request. The thunking layer then sends a request to the server requesting that it redraw the tornado-ey parts of the window.
This done, the thunking layer dispatches a message to the actual tornado code requesting it update its window. This may not happen however if for example that window has had its attributes set to display a file in that window - in which case the thunking layer may one of two things: (a) call the host OS's facilities to render the file or (b) ask the server to render the file - it may even fetch the renderer from another machine over the network.

And essentially so on. The potentials are pretty obvious and the system is relatively simple but yet quick and powerful. It also should work on all the major GUI's - however, it will not work on RISC-OS as it stands.

What will be done on RISC-OS

RISC-OS currently sits someway short of the basic minimum required by tornado II. The first, and most obvious, is that the RISC-OS Wimp does not preemptively multitask its processes nor does it provide facilities to do so except for the taskwindow which is too restrictive for tornado.

So, as a result, these missing features need to be implemented. Work has already started on this and it is expected that a preemptive multithreading multitasker extension to the RISC-OS Wimp will be ready in early 1997. Alpha and beta copies are available from hensa in folder d124 - here.

Despite their tornado II orientation however, these support modules will also be available to non-tornado RISC-OS code. Details on how to use the tornado support module is also at the above url.