The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/QandA/InterR1

Text File | 1995-07-14 | 60.6 KB | 1,388 lines

Hello to all,

Following the huge response from the bowels of c.s.a.*, I have replied to
each and every reply below. I also scanned the newsgroups, looking for anyone
who didn't post the message to [e-mail] (grrr!), and I
think I've caught most of them. Hopefully.

Replies to messages received from the Internet:
Colin McQueen, [e-mail]

> Built in networking/internet software
>    include conferencing, WWW and MIME transfer

Although I'm sure Bi*l Gates thinks he knows what he is doing, this can't be
on the cards. It is not the responsibility of the OS to provide all this,
especially some users may prefer alternative interfaces.
   However what Tornado will provide is the finalisation of Hugo's block
drivers, and replace sections of them with 'better' code, as some of Hugo's
coding methods are decidedly iffy (check out the method used to do block
i/o). This involves allowing the user to redirect the serial i/o to different
programs by the use of hotkeys, or a menu in the Tornado application
manager. This is done by Tornado_SerialOp.

> Automatic file conversion
>    from PC MAC to Acorn for graphics (bitmap and vector) and text
>    all controlled by a simple configuration

This has been implemented, through subtasks. Upon the user dragging a file
onto a Tornado application, Tornado checks if it can load this file. If it
can't, a suitable list of converter subtasks is prepared (more than one if
necessary), and the file is run through these subtasks until the desired file
type is output. The task knows which type of file it was originally, and the
file is converted back before saving. This even applies to say, GIF's in a
DTP window, whereby in memory they are sprites but when saved as part of the
DTP file they get converted back into GIF's again.

> Partitioning and protection of any writeable filesystem
>    including RAM so we can have fast scratch space
>    for harddiscless machines with lots of RAM on a network

Fraid I don't understand what you mean. Tornado has its own filing system
tfs: which can contain an unlimited no of files, with names of unlimited
length, and to an unlimited directory depth. Obviously though copying between
tfs: and adfs: may cause some problems though! :-)

> An Alarm timing system
>    that can be managed across a network
>    for timed local machine activity
>    Also time management system to keep a log of
>    machine and appliation usage by individuals.

Hmmm, nice idea, but I'm afraid that will really be up to individual
programmers. The problem is the mass usership of Acorn's are single users,
and don't need meticulous logs kept. But, by all means, if there is enough
demand we'll put in the necessary hooks. But not yet!

> Manager defineable menus for the OS
>    so I can lock out rename and stamp etc.

Again, same problem as above. Most users like to be able to delete things!

> Put more of printers into the OS so it loads quicker

Again, Tornado does all the hard work of selecting printing streams, so to
the task this is transparent. Also, printing is multitasking, so no hung
machine for hours on end. What you say above will certainly be thought about,
but not yet: Printer manager design is tough stuff, as poor Bi*l well knows.
What is perfect for one is crap for another.

> Shared Button bar tools for common tasks

Em, sorry, no. This is out. :-)

> Global clipboard filing system

Won't be needed: RAM transfers work perfectly and transparently, and if need
be someone could write a clipboard in about twenty lines of C. One that
converts between file formats etc. etc. and file rendering is taken care of
by Tornado.

> Shared dictionaries and manuals on line

Fraid this is also out. We're not wanting to turn the Arc into a M*c here!

> An easier way to write modules and module tasks

Em, what's wrong with the current way? Bl***y sight easier than doing the
same for DO* without a good library!
   Anyway, there's loads of stuff out there that do this already - just none
of ye can get it as you won't log onto a BBS!

> Floppy disc dismount automated or timed when not seen

This will be considered, but Filecore is a beast at times.

>    Name appearing next to icon as for hard discs

Plenty of stuff on the PD scene to do this ...

> Option to see thumbnails of clipart files in filer window instead of icon

The demo app with Tornado, showing how to write Tornado apps, does this. It
should be only 2k of Basic, or less of C if you didn't include the standard
header.

> Option for hotkeys on filer (dangerous)

The rewrite of the filer (a while away) will do this, and an awful lot more.

> Option to save desktop boot file automatically through Taskmanager dialogue
> when shutdown
>   including opening document windows etc.

The rewrite of the Task manager should do this, and more besides.

> Long double click to save having to do a shift double click (configurable
> hold time) See !TidyDesk

I thought RO3 did that already? My RO2 has a utility I wrote to do this for
me.

> Better range of backdrops

Not our problem! But we will do a much better Pinboard, which is dire to say
the least.

> Close all filer windows option

Em, this could be done already in about 4k of Basic!

> Interesting screen blankers with option to code more

Eventually, yes. The Tornado app manager will do this.

> Better hourglass to help us really know what's happening

Done, but I need designs!

> Option to stop two tasks of same name loading

What's the problem with this? Indeed, IMHO there are too many apps already
out there (eg; Zap) which do this.

> A Management system for different makes of toaster like !Printers
> (!Toasters)

Have you been eating mushrooms? :-) Toasters?



Peter Christian Naulls, [e-mail]

> : Please remove the 77 file per group limit.

Fraid Filecore does all this, and we're not about to recode it!
tfs: has an unlimited number of files per directory though!

> And while you're at it, the 10 character filename limit, and an easy way to
> make multi-line text labels for icons :)

Again, filecore forces this. And again, tfs: has an unlimited filename
length.



Cliff Dobbs, [e-mail]

Oooo, a person from ARM Ltd! How's StrongARM coming along?

> Am I to understand from this posting, that you are developing RO4
> independantly from Acorn?

No, we don't wish to do this. Doing this would destroy the Acorn usership,
with PD stuff being developed for Tornado and commercial stuff for RISC-OS.
   No, what our problem with RISC-OS is that, since RISC-OS 2, there hasn't
really been any /real/ improvement of the operating system. And with RO3,
some of the supplied software (eg; Pinboard) is positively dire, and not only
that the OS runs like a drain etc etc etc. RO3 was, in many peoples eyes, a
disaster, mine included. I still use RO2 for example, never seeing why I
should pay my hard-earned money for a hash of an operating system.
   We also believe Acorn are not putting enough resources into developing the
correct areas of RISC-OS, and since they seem intent on developing a
progressively worse and worse SharedCLibrary, and orientating all of the OS
around it, we plan to do something about it. Even if this project never
leaves the theoretical side, maybe it will make Acorn wake up and realise a
lot of people are annoyed. Especially on fidonet, where the lack of
development on Basic is really p***ing off a lot of people.
   Look at it this way: the last rumours of dissent with Acorn's operating
systems was in the days of Arthur. Now they are writing RISC-OS 4, and the
same things are beginning to happen. Maybe it's about time they started
writing an OS, starting again from RO2, which will really kick ass. Then
again, maybe, and probably they won't. In which case, Tornado will be here.

Tornado is intended to function as an alternative development of the
operating system from RO2 onwards, and I think you'll be impressed. It will
be written mostly in C, bits of assembler and some of the demo stuff will be
in Basic. It will remain compatible with current and future versions of
RISC-OS, running alongside it rather than on top of it.

One of the handy things implemented by RO2 over Arthur was the very easy way
it is to extend the existing OS. This will be used to its fullest extent.



Volker Hetzer, [e-mail]

> * an improved filesystem allowing longer names containing whitespace and
>   an unlimited amount of entries per directory

tfs: does this. However, it is not an entirely media-based format, as some of
it is on disc and some of it in RMA.

> * the adfs/scsi/ram naming of filesystems should be rethought. With the
> arrival of image filing systems that don't appear as drives on the iconbar
> there needs to be found a new solution.

Em, AFAIK no filing system appears on the icon bar unless it specifically
goes about doing so itself. And sometimes, if a filing system isn't on the
iconbar, then there's a good reason why it isn't.

> * Suggestion:
>    separate the administration of filenames and directories (if they
>    should exist) and the physical representation of data, space
>    allocation, defragmentation and so on. This might slow down things a
>    bit but allows a very abstract implementation of name administration
>    and different space administration strategies.

Fraid we're not going to rewrite filecore quite just yet!

> * change the "standard" Language to something better than C or C++.
>   Alternatives are eiffel, smalltalk and objective C.

Personally, I can't see for the life of me why it matters which language is
the "standard" language. What does it matter, other than to stifel the
programmer and generate extra revenue for Acorn through sales of its C. No,
it doesn't matter to us what language the programmer uses. Tornado as a
policy (it's called Aim 3) will support, and continue indefinately to
support, all languages available on RISC-OS. We don't discriminate against
people Orwellian-style like Acorn.



Wilco Dijkstra, [e-mail]

> It's nice to hear that at least someone will develop a new OS! (was about
> time - I also expected much more from RO3.5)

Not developing an entirely new OS - in our opinion RISC-OS 2 was pretty damn
good. We're going to start from there and build upwards, and hopefully avoid
all the mistakes Acorn have made with RO3 and 3.5.

> I'd like to share my ideas with you (in a while), but firstly it would be
> great if you told me more about your project:
> - is it Acorn related / by a company / by enthousiasts (like Linux)?

Yes, very Acorn related. And it's all by the grass-roots users, although
Multinational companies are welcome to join in if they wish! :-)

> - would it be possible for other people (like me) to cooperate?
>   (except for ideas/hints & tips of course - I mean coding, as I am
>    about to graduate)

Hmm, you won't have much time then? Yes, anyone able to contribute can. Right
now we need loadsa C coders. BTW, you can't use the ANSI libs :-)

> - maybe you have a larger explanation of what you have designed?
>   (allows me to make more specific and relevant comments/tips)

Hopefully by the time you read this hensa will have posted v0.03 of the
Tornado brief which contains /everything/ we want to do, and how to do it.
v0.01 is already there, but it is woefully incomplete.

> - dynamic linking / reentrant code (with NO overhead for most calls) - NO
> SWI's as system calls, but rather inter-module calls to objects - all code
> except for the microkernel & interrupt drivers runs in
>   usermode
> - different levels of protection
> - object-oriented (dynamic function calls)
> - use the ARM memory manager fully (managers / clients)
> - mapping files into virtual memory
> - version management (different versions for a certain module/object:
>   like app A needs v1.1 windowmanager, while B needs v1.2. If v1.1 and
>   1.2 are incompatible, then both are loaded and used. Maybe even swap
>   v1.2 out while running for v1.3! Also, support for different, competitive
>   implementations of the same object: a faster FPE replacement)
> - please no compilation at runtime! (like TAOS) - etc. etc....

Ouch! Fraid if that's what you've got lined up, good luck! That's a good
year's of coding AFAICS. No, Tornado is much smaller scale as it relies on
much of RO already present. It just goes about implementing the higher-level
stuff differently.



Ian Griffiths, [e-mail]

> Is this for real?

Yes! :-)

> How many of you are there?

Less than there could/should be ... :-(

> Is this planned as a complete re-write from scratch?  I assume so with
> what you propose to achieve.

Nope, RISC-OS 2 laid some pretty powerful foundations, and we intend to build
on them in a way Acorn never did, unfortunately for us the end-users out
here.

> Is this going to be RiscPC only, or old hardware too?

Anything that can run RISC-OS 2 and upwards.

>* Virtual memory might I suggest that as well as paging to a swap file you
> consider the  facility to map files into memory, either in part or in
> whole.  (In part  must include the ability to map several portions of one
> file into  different parts of memory.)  This is a jolly useful feature, not
> only  because it enables very large files to be processed reasonably
> efficiently, and without too much effort on the part of the application
> programmer, but also because you can then reuse this mechanism for  loading
> in executables (AIF files in particular).  This will give you  swapping out
> of portions of executables for free, and without taking any  space in the
> swap file, leaving that purely for the data.  (There is  never any need to
> swap out executable data - being read-only by nature,  you can always go
> back to the binary and re-read it when you need to page  it back in.)

Phew! No, this is too fundamental and RISC-OS won't allow it. Our virtual
memory uses a novel approach, and centres around a relocatable block manager.
The task claims a block, and receives a handle (which happens to be
negative). This block may sit in RMA, or it may live on disc, depending on
its age. When the application wants to access the data within the block, it
calls Tornado_Getaddr, giving the handle of the block. Then the address of
this block in RMA is looked up, and given back to the app (and perhaps the
block may be loaded back in from disc if need be). So long as the app doesn't
do any heap op's during access, and isn't being preempted, and isn't polling,
it can access the block freely in the knowledge that the block won't move.

Is that clear enough? For further details consult the tornado brief available
from hensa.

> >* TAOS style subtasks Are they what I'd call 'threads'?  By a thread I
> understand a path of  processor execution running concurrently with others,
> but working in the  same application space as other threads within the same
> process.  They  share all data within a process except for stacks which
> exist per-thread.

No, we were going to do this, but unfortunately Basic can't hack it in these
situations. No, subtasks work by a parent calling them. Subtasks may run
locally, being preempted by the Wimp, or at the other end of a network, or on
the other side of the world connected by TCPIP if need be.
   For example, picture a WWW client like Netscape. Essentially, it would be
a Tornado task, which upon loading in a page issues a request for a subtask
that will convert GIF's into Sprites. Tornado issues an upcall, the subtask
server picks it up, and it may run it locally as a preempted Wimp task or on
another machine connected by Ethernet. The subtask loads in the file,
converts it (optionally spitting out already-processed data back to the
parent app) and then finishes. And the subtask may call another subtask, or a
multitude of subtasks, all of which may call more subtasks still. Thus
develops a tree-like structure, similar to TAOS except TAOS uses a web like
structure.
   As you might imagine, this can lead to some /pretty/ powerful programs,
with multiple processes working at once all communincating with each other.

> It's all rather closely tied in, but you haven't mention it, so I'd like
> to request the ability for individual tasks to block on system calls,
> particularly those involving IO, and for asynchronous IO requests to be
> multiply outstanding, e.g. can have multiple tasks all sleeping because
> they're all waiting for a disk operation to finish.  Other tasks not
> blocked (sleeping) should be able to execute while waiting for a response
> from hardware.  (Obviously only possible if you can leave the hardware to
> its own devices [sorry, awful pun] until it IRQs you to ask for attention;
> almost all hardware works like this so it shouldn't be a  problem.) Since
> this is going to require FileCore at least to be re-written and  possibly
> fileswitch, can we have long filenames while we're about it? Some sort of
> controllable metric on the scheduler would be handy, like  Unix's 'nice'
> values.

Again, we're talking complete OS rewrite here, which is something we're not
doing. Acorn did good with RISC-OS 2, and we want to see them continue the
good work, rather than the pathetic improvements with RO3.

> I think I'm about to question your fundamental design approach...  (Sorry.)
> Might I suggest that you do it inside out?  I think a lot of  the API for
> RiscOS WIMP programming is not as it could or probably should  be.  In
> particular things like the need to offset screen coordinates by  scroll
> offsets manually on every single screen operation, revealing the  fact that
> the desktop is nothing more than an illusion at a very obvious  level,
> strike me as unhelpful and anachronistic. I would suggest that you design
> your shell to be a superset of the  current Wimp's functionality, and build
> that as the _fundamental_ Wimp  interface.  Backwards compatability would
> be achieved by mapping the  current Wimp calls onto these new ones.  This
> is how both Windows NT and  OS/2 achieve compatibility with Windows 3.1.
> In NT's case, Win32 is the  fundamental Windows API (although it is just a
> 'personality' which runs  on top of the NT executive itself) and under
> OS/2, both Win16 and Win32  are mapped onto OS/2's fundamental windowing
> API, which again, if I  understand it (I'm not an OS/2 programmer) sits as
> a shell on top of the  OS itself. This would give you much greater freedom
> in your API design, and will  almost certainly lead to a neater solution.

Exactly! You've got a lot of it in a nutshell. Tornado provides a superset of
the Wimp, which has been long needed, but I suppose Acorn assumed everyone
would be using their precious libraries. Well, I'm not, and there's thousands
of others like me.

> As for crash protection, similar issues are pertinent.  How do you intend
> to achieve crash protection?  This is not something that can simply be
> installed as an extra bit of software (despite the impression you may get
> from certain advertising campaigns), it needs to be built in to the very
> methodology of OS design. This would require a different approach to the
> way RiscOS works.  The  module area is a particular bug bear, in that it's
> a free for all area,  despite being a sensitive one which, if corrupted,
> can bring the whole  system crashing down. So my preferred approach would
> be to go for a notion of a virtual  machine.  This is messy, but then
> dealing with legacy designs going back  15 years (a module is really a
> sideways ROM...) always is.  You would  have Tornado applications and
> device drivers, (i.e. ones written with  Tornado in mind) which would be
> protected from one another, and would  abide by the rules you've built in
> to enforce system integrity.  You  would then have old style applications
> which are run in a virtual machine  which looks much like an old RiscOS 3.x
> machine, where all old style  modules are visible, and access to this is
> granted to applications.   (Access to the full machine is granted to
> modules, since they run in SVC  mode, but that's always going to be true.)
> The number of modules in such  a virtual machine would be kept to a minimum
> - for preference all modules  would be Tornado-aware and live in the true
> Tornado machine.  Old  applications and old modules of which Tornado
> versions do not exist would  run in one or more of these machines.  If one
> of these decides to wreak  havoc, you'll only wipe out the virtual machine.
> You could make it an  option to start up some tasks or modules in a virtual
> machine of their  own.

Nice idea!

You're right: this is difficult. The best Tornado is going to go for is to
install itself on the OS_ChangeEnvironment handlers, and do the best it can
from there. With RISC-OS, you can't stop programs accessing outside their
space as the looming beast of the WimpManager looms over everything: and even
changing the MEMC's memory map even one bit often causes total system crash,
as the WindowManager is not very well written in this respect.
   You can only do so much here: RISC-OS follows an inbetween approach to all
of this, and you can go one way or another. Problem is the Wimp decided to go
on total openness, and once that's done there's nothing, Tornado included,
can do to really fix it.
   I suppose we could write a seperate multitasker for Tornado apps only, and
this would have definate advantages: it's been written down. We'll think
about it in due course, but it's pretty tricky - especially with all the
differing hardware out there.

> Module calls could be made from within a virtual machine to a module
> outwith that machine, so long as that module was a Tornado one:  the SWI
> router would give the SWI handler access to the task which called it, so
> as long as data is always accessed by the module itself (rather than the
> application allocating some RMA and giving that to the module, a practice
> which would need to be outlawed for Tornado applications and modules)  SWIs
> can work like this.  The fact that there are a fair few rules like  this
> that would need to be enforced is not a problem for backwards
> compatibility - old modules will break them, but they'll be running  inside
> the virtual machine[s] anyway.

Like I say, it's a nice idea. Tornado file renderers follow a slightly
related idea, but really there's not much we can do really. Not without a lot
of work for effectively little gain, especially as most apps don't mess
around like this. At least, they shouldn't anyway! :-)

> You may consider this to be overkill, or at least a very heavyweight
> approach to the problem.  However I don't honestly believe that you'll be
> able to achieve crash protection in any other way.

Essentially, all we want is when an Address exception occurs in an app, that
a suitable message pops up (NOT Address exception at &xxxx) and all the files
in the app currently being edited are saved out, any open files shut etc, and
the application terminated nicely. Next time the app is started up, Tornado
informs it that it crashed and tells it where to get the saved out data.
   I think that for all the work needed, this is adequate gain. I hate losing
work after hours of design!

> As to further suggestions, you're presumably currently most interested in
> the low level OS aspects rather than UI at the moment.  I'm fairly
> interested in this sort of thing, so if this project really is going to  go
> ahead, please let me know of further developments, and any comments on
> what I've said so far;  I'd be interested to discuss this further.

Both really. And yes, I'll keep a hold of your address: you know your stuff.
And I'll keep posting into theses groups as long as it's still necessary. You
can do as much/as little as you want.



Gavin Sallery, [e-mail]

>  Built-in support for the 'Net (possibly some sort of definite link to
>     FreeNet)

See above to Colin McQueen

>  A RAM disc that you can reduce in size down to the size of files that it
>     occupies dynamically, ie without emptying the thing and starting again.

Yep, we have that in the form of tfs: which auto-extends, garbages, and
shrinks to avoid fragmentation. Also, if it gets full, some of the files may
be dumped to disc to give applications some more memory. Open files and
constanly updated files are exempt from this of course, unless the user
wishes otherwise.

>  Long filenames. You're bound to get loads of other people saying this, but
>    I want to as well :-)

That's filecore: we're not rewriting it!

>  Something similar to the Windoze (spit) alt-tab combination; *sometimes*
>    it might be useful, just for bringing recalcitrant application windows
>    to the top of the stack.

Yeah, that would be useful. I've pencilled that in. Thanks.

>  Lots of options. The ability to configure nearly eveything about the
> system, as with X-windows or OS2/Warp, would be quite a boon. Acorn's GUI
> looks quite nice as it is, but I'm sure someone would want to customise it.
> I'm willing to help out if you need any sprites designing for any new bits.
> Come to think of it, my A-levels are over, so I could probably give you a
> hand with, say, documentation or whatever. My coding's a bit rusty, but I'd
> love to get involved somehow :-)

Tornado's about as configurable as you can get, although most of it is done
using Zap (ie; the more estoric features and options). Almost anything can be
changed.
   However, one thing that will be standardised is keypresses, as it's rather
difficult to explain to someone about something if you're using different
keypresses. However, almost everything else should be configurable, on a
demand related basis. You ask for it: we'll give it to you, unlike Acorn.
   As for becoming involved, anyone and everyone is welcome, assuming they're
serious and can do something useful.

>  Thinking about that last (rather rambling) point, maybe some nice
> extra-whizzy flash gimmicks, just to show off the Risc PC properly. I mean,
> Mac OS has those wizzy boxes flying around the screen as you open the
> windows, which could be neat. Maybe something extra to do with opening
> menus? Scrolling or sliding open, rather than just popping up. Windows is
> going for lots of animation in order to captivate the user/entertain those
> who might other be intimidated. Maybe this would be something to look at?
> Nothing tacky mind :-) I can no doubt think of more if I actually put my
> mind to it.

Em, the principle aim of Tornado is productivity for the end user. Above all.
That means no flashy gimmicks, as these slow things down. However, we will
provide the necessary hooks wherever possible, so PD writers can do all this
flashy tacky stuff and you all can use it to your hearts delight! However,
/we/ won't be doing it.
   And anyway, we aren't talking about PC's or Mac's: it's good ol' Acorn's
here!

> Macro recorder. This would be useful for inexperienced users, especially if
>   you include several ready-made macros with it. Things like creating a
>   standard letter, or setting up a spreadsheet, stuff like that. A neat way
>   of doing it would be to have the macro replayer tied to the mouse pointer
>   in a context-sensitive fashion, so that whatever window the pointer's in,
>   if you do, say, an alt-click on the window, a box pops up with a list of
>   macros available for that program, having checked this fact in its
>   database of available macros. What I'm thinking is something along the
>   lines of those "Wizard" helpers under windows, tied to the interactive
>   help system of RISC-OS; whenever you get a Help message giving you simple
>   instructions for a generic use of whatever's under the pointer, the macro
>   utility would give you a list of specific instances to do with the same
>   subject. For example, if the Help application says "Open the General
>   Settings panel" (in NewsBase), the appropriate macro (actually, we
>   probably want something a bit more than a macro; something that allows
>   some user input via a simple dialogue, and the ability to display
>   informative prompts) would take you through the setup procedure in a
>   friendly fashion. Obviously, you couldn't hope to provide such macros for
>   all applications, just the system ones, but if the editor's built into
>   the OS, the things are bound to proliferate. Writers may even begin to
>   supply the info with their programs :-)

For the start of Tornado, this won't be a priority as we're aiming for
productivity of the experienced RISC-OS user who can read a manual! :-).
However, given some time, we'll get around to it.

>  Most of the stuff that Black Hole II adds to the OS... especially the
>   file-finder (one other area that Windows scores over RISC OS. I suppose
>   any areas which Windows leads in should be eliminated! If I think of any
>   more, I'll let you know. There aren't many. :-)

Filefinder: noted! Thanks! It was going to be incorporated in a much more
sophisticated, automated way sometime in the future, but we'll stick in a
more simple version just for handiness. This way we'll really demonstrate the
power of subtasks, and we'll have every level of directory structure being
serached at once ...

> Anywhere I can get more info about this project? Thanks,

Hensa has some stuff, and hopefully by the time you read this they'll have
v0.03 of the Tornado brief uploaded. This details /all/ of Tornado's
internals, whereas v0.01 only does a bit of it.




Graham Robinson, [e-mail]

> Does this mean Tornado is being developed independantly, without Acorn.  If
> so how does it run (multi-tasking with RISC OS or as a separate task?) I
> would like to see better security on the Hard Disc. At the moment you can
> stop people writing to the disc (RISC PC), but you cant 'hide' programs if
> the password has not been put in correctly. Also for the Filer the ability
> to split hard discs it to partitions easily and also on IDE drives (not
> just SCSI).

No, Tornado will be developed to run alongside RISC-OS, and most of it comes
in the form of four or five core modules, with 'helper' apps loaded from disc
running alongside it. Although a Filecore rewrite is off the cards, the
proposed rewrite of the desktop filer should do some of this. Then disabling
all access to the command line should suffice. And unfortunately partitioning
is up to the particular filing system, not the OS. Although Filecore could
help a lot here, we're not rewriting it.




Paul J. Dunning, [e-mail]

> As long as it will run on my A310, it all sounds good to me so far.

Yep, even if it's still running RO2!

> * Automatic recognition of alien filetypes - eg TIFFs loaded without going
> via ChaangeFSI, Type 1 font support - so the font manager can cope with
> fonts not currently available to the Acorn user.

We have automatic translation of filetypes, but I don't know about fonts. I
don't see why the file translator can't be extended to cope.

> * Reading and writing to Mac disks as well as the PC and Atari that are
> already there.

Wince! This must be the twentyth time I've said this, but you couldn't have
known. We aren't rewriting Filecore. Result: irritate Acorn about this!
Anyway, Apple want paid if you're going to use their disc format.

> * Support for changeable hard disks / CD Roms - this will allows the use
> of systems such as Syquest disks. OK - 3rd party software allows this -
> but support from the manufacturer in this respect will be a bonus.

Ditto, we're not rewriting filecore. That's Acorns problem, not ours.

> * CMYK support in the palette selector - I understand that RO3.5 derives
> its data from an RGB table.

AFAIK RO3.5's Palette selector is written in C. This is something we are
/strongly/ against, as we believe Acorn are playing silly buggers putting C
code into the OS. To each his own though ...
   We'll do something about this eventually, but not yet as there aren't that
many programs needing it yet.

> * Please PLEASE retain the OS in ROM. The problems that I have  experienced
> with Macs are caused by files being cpnstantly re-written to  on the HD,
> and if one gets corrupted then it's potential bad news.  Virtual Memory -
> yes - but no further. How about using Flash EPROMS in  future so that
> future upgrades can be uploaded from disk without having  to open the box?

Acorn? Please answer this bloke! :-)
   Fraid we can't supply Tornado on ROMs as rather annoyingly Acorn didn't
leave a ROM slot free. But theoretically it's blowable onto ROM, so I suppose
it wouldn't be too difficult to stick it on a podule.




Merlin Hughes, [e-mail]

> Dump those ridiculous rules about submissions for approval
> by the Politbureau; I for one, would _never_ develop under
> such an autocratic system.  Loosen up; you're not creating
> the new world.  If it's supposed to be used by all, it had
> better be a lot more friendly.

Hmmm ... :-)

Ok, fair point I suppose. It may seem a little onimous. But the general
intention of this idea of verification (see Aims) is so customers, when
buying /commercial/ goods, can find out how well a Tornado application does
in complying, a good thing IMHO. Read more about this in Aims, as from
receiving this message I've updated it.

Here's the reply I issued to Merlin:

Quoting DigiLink Email Gateway:

> Dump those ridiculous rules about submissions for approval by the
> Politbureau; I for one, would _never_ develop under such an autocratic
> system.  Loosen up; you're not creating the new world.  If it's supposed to
> be used by all, it had better be a lot more friendly.

Hi Merlin! I usually don't reply directly to people suggesting things, but
this message rather puzzled me.
   The Tornado approval system was intended mainly for use by commercial
producers, and is by no means mandatory. It is intended to stop commercial
producers producing software, claiming it to be absolutely fabulous and when
we use it we find all their menus are bright red!
   It is highly unlikely that most writers will submit their work for
approval, as most writers like to take their own path while writing. However
things like Translator's master control window (by Jon Kortink) should be
avoided as it is very unwieldy, especially for those running with smaller
screens (VGA).
   Essentially, it is hoped it will implement a standard by which the
end-user will know that this application will at least come up to certain
standards, rather than relying on the producer's word.

Put it this way: it's like a driving test, whereby you go through the testing
procedure and if you fail you get a detailed breakdown of your faults.

It's not a dictatorship thing: this is much more liberal, and if people don't
like it they can always ignore it, or request changes. We'll be happy to
accomodate.

Cheers,
Niall




Serge van der Schaft, [e-mail]

> Requests for RO4?
> Although I am not a programmer and don't know anything about it, I would
> consider it extremely valuable if there could be something like an 'undo'
> feature, for the OS, but to be used with apps as well.
> Just to let you know.

Hard one this. But we've noted it down. We'll try to include help for apps
putting undo features into their code.





Victor Markwart, [e-mail]

>     Hey up Niall!
>     This has probably been stated by others, however:
>     - remove 77 file limit

You're right, it has, and as said before I have been told a new Filecore will
be released soon which does just that.

>     - some sort of scripting language (REXX, BASIC?) which allows
>     (relatively) easy interprocess communication, data transfer, and
>     program control (though from your description is sounds as if this may
>     already be included).

Em, sort of. The script won't be a language in it's own right, but rather a
script which adds various functions that can't be done easily from a normal
language. Ie; the programmer writes the main body of code in whatever he/she
likes, whether it be Basic, Smalltalk or C++, and also writes the Tornado
script file to go along with it, as none of these languages have commands
(obviously!) that are Tornado-related. This means writers can use the
language _they_ want, not what Acorn want.

>     PS Any chance of running on pre-RISCPC machines?

Well, considering I'm writing on a RO2 Arm2 A3000 .... :-)

No, more seriously, RO3 went the wrong way. That's what we think. And RO4
will go further the wrong way. And so, we're starting from scratch with RO2,
and writing from there. Any machine capable of running RO2, whether currently
of historically, will also be able to run Tornado. We're aiming for a floppy
only 1Mb system as the minimum operable, but that may have to be waived.
We'll see.





Mike Allum, [e-mail]

> I would like to see, in RO4...
> 1) Long file names

Filecore's, and Acorn's problem. Nuff said previous to this. I HOPE ACORN ARE
LISTENING!

> 2) UNIX-style filenames (/blah/blah/file.extension.master_extension)

IMHO Acorn's filenames are uniquely Acorn, and should stay that way. You want
Unix filenames, use Unix. Anyway, it's also a Filecore problem.

> 3) Filetyping override on master extension (i.e. list.dbf.txt is TEXT)

Filecore again sorry to say ...

>4) Easier to use screen co-ordinate system (the present one is a pain in the
>   rear)

Hmmm, agreed. I always felt there was nothing wrong with having a screen that
was always 1280x1024, and if really the screen were 2560x2048, then to refer
to pixel 3,5 you'd use coords of 1.5,2.5. But Acorn decided different, and
anyway that's kernel based. Internally it can't be touched, by anyone.

> 5) Global cut and paste using filetypes (i.e. cut 15 draw objects to buffer
>    and they're typed as draw and will not paste into edit)

Eh? Sorry, I don't understand you.

> 5) Global cut and paste buffer stack (i.e. cut draw objects, text, and data
>     and first paste on a text editor pastes in text, first paste in a draw
>     window pastes draw, etc.)

Quick and dirty fix is to not use a clipboard at all :-). Tornado will not
support one internally, as quite frankly I and a lot of people found it's
presence crap, although ATM one of the Tornado demo apps will be a clipboard.

Sorry!

> 6) Cut and paste of text ANYWHERE on screen (cf HP-vue where you can
> highlight even the text in writable icons and cut/paste it)

Noted for the rewrite of the desktop. Okay, when we've finished the Tornado
replacement filer, this will be a feature.




Alexander "Sascha" Nerke, [e-mail]

> What you have done so far sounds to well to be true ... lets see

Cheers.

> How about to include OpenDoc ? And maybe a DisplayPostScript system ?
> And please do something like Apples auto-find-the-right-file-even-if-its-
> moved-thingy, i.e. you can move a file but the OS always finds the new
> location so you don't need to change config-files all the time ...

Fraid I don't know much about OpenDoc, and I'll leave the postscript renderer
up to someone's who better than me - they'll do it as a Tornado renderer, and
thus all apps from hence will be able to use it.
   And finding files no matter where they are is an important aspect of
Tornado. We haven't done the protocols yet, but we'll eventually get around
to it. And Tornado config files are /so/ flexible that the main program can
be on CD-ROM, and it's config's be stored somewhere else ...

> Thanks for 1st looking for the users ... ;)

Cheers, just doing what Acorn should have a _long_ time ago ...





Keith Hopper, [e-mail]

> Greetings,
>      The absolutely vital thing which must be incorporated irrespective of
> any other feature is the internal handling of ISO/IEC 10646-1:1994 (also
> known as UNICODE) Level 3 character encodings.   This obviously applies to
> such things
> as FontManagers, file systems (eg file names in Thai or Chinese or ...).
>
>      I agree that a flavour of this sort of thing 'could' be added on top,
> but there would just be so much unnecessary overhead for every single
> application using I/O of almost any kind other than graphics.   There will
> need to be a major revision of design of a keyboard driver (a research
> project with this in mind is under way here) to be context sensitive (eg
> operating in quite different ways at the drop of a hat when mixing
> Hanzi/Kanji and Hiragana and Katakana and English ... in one document.
>
>      I could digresson these problems for a wee while, but the fundamental
> design must take into account the fact that a recognisable character shape
> when displayed or printed may have been generated from up to 192 bits - or
> as few as 16 -- eight bit codes will become obsolescent within the next
> five years -- well within the working life of Tornado.   Actually until we
> can get sixteen bit codes in NZ we cannot represent Maaori (which uses
> characters from Table 2 of 10646) nor all the other character repertoires
> of languages spoken here.

Must admit I have never thought about it. The most obvious solution is to
change character representations into 4 byte quantities, allowing for a few
billion combinations.
   Forgive me: probably you get the brush-off from a lot of people, and I
know this means squat, but currently I know of no processor running on 32-bit
instead of 8-bit quantities. The Arm is probably better than most, but
certainly RISC-OS was never designed for such a core change in design. And
because Tornado relies on RISC-OS to function, I'm afraid Tornado could only
support extended character sets as an overlay, as you suggested.
   Mind you, for my computer science degree, in which I intend to write an
operating system to work under Tornado instead of RISC-OS, I'll certainly do
this. However, unfortunately, it's a bit unlikely my OS will ever be used
seriously.

>      I imagine you would have problems in Eire too!

Nah, we all speak English here. Thanks to Queen Victoria and friends.





Darren Caunt, [e-mail]

> First of all, I am very happy that someone seems to be taking more
> of an interest in RISC OS than Acorn!

So are a lot of people. Just shows how badly Acorn are doing out there.

> As for 'Tornado', the ideas you put forward are excellent!

Cheers.

> Virtual memory, pre-emptive multi-tasking, OLE support, these are
> all of the things Acorn should have put in RO3 (but obviously didn't)

Nah, they preferred to write the SharedCLibrary and flesh out RO2 a small
bit. Nothing substantial enough to make me upgrade anyway.

> I work in a school, as a technician tending to the whole range of
> Acorn machines. There are several things which I see as very important:
>
>    1)  File locking and password protection for individual files and
>        directories (with a super-user password override) built into the
>        very heart of the filing systems.

Pencilled in. As said in STOP PRESS below, we may have to do this.

>    2)  Meaningful long filenames

Ditto.

>    3)  Informative error messages - eg. no more 'address exceptions at' or
>        'abort on data transfers' which mean nothing to anyone!

Done already, but only for Tornado tasks really. Unfortunately it's a bit
difficult to provide better handling for other tasks without hacking the
window manager, which would be rather OS dependent.

>    4)  A useful on-line help system which gives more than a few limp
>        suggestions, again built into the OS.

We'll do our best, by providing facilities that can be hooked into, but
unfortunately large files full of help messages contravene the ideas behind
Tornado, in that they consume vast tracts of disc space. Far better, in our
opinion, to write a good manual, and when you need help up pops the page
number. Some may not agree, but when a user knows the package backwards, they
don't need an extra 2Mb of disc space taken up with now useless help
messages. This, in our opinion, is a major failing of Windows and System X,
and we don't intend to let it happen to RISC-OS unless we can damn well help
it.

>    5)  Keyboard control of the mouse pointer (!)

:-) - I wrote an excellent module to do just this a few years ago. Very handy
when your mouse breaks down.

>    6)  Ability to only permit the applications you have specifically
>        listed to run.

Will be in the rewrite of the filer.

> Some of them may seem to be a little 'petty' and of the more 'window
> dressing' variety, and I'm sure I can come up with more 'worthy'
> suggestions given more time to think!

No, we're wanting _any_ input, whether 'petty' or not. Thanks!

> How are you planning to make Tornado available to the Acorn community?

Assuming hensa are okay with it, we'll put the entire lot in an archive for
everyone. However, extended and advanced development tools will be
commercial, although basic ones will be PD. We reckon we can fit it all into
800k of archive at most.

> Are you planning to only use Tornado on RiscPC machines, leaving the
> vast majority cut off from your improvements? Given the limited amount
> of memory available for the majority of machines I can't see that all
> the suggestions would work happily in a 2Mb/4Mb machine configuration
> and that usually more OS generally means less speed available for
> applications, it does seem that the older machines have basically
> 'had it'!

No, oddly the things we have suggested won't take up more than 200k of RAM at
most. Even with it written in C. Most of the memory goes on the more helpful
than usual messages shown to the user when something goes wrong.
   Unless you're planning to run a powerful system editing 10Mb files
regularly, a 2Mb Arm2 RO2 Arm420 will suffice easily. And will be quite quick
too. Obviously running Tornado on a Arm700 series 16Mb RPC will increase
productivity no end, but it still should spring a bit of life into the 80's
made machines. For example, I'm programming on a RO2 4Mb A3000. Pretty
underpowered to what most of you out there have, but it works!

> I hope that you have great success with the Tornado project, and
> perhaps teach Acorn a trick or two in OS design - they need it!

Well, if nothing else, we hope that Acorn will wake up a bit. We don't want
to have to support the Acorn forever, preferring to give the rights of
Tornado to Acorn when we think they will treat it well, although retaining
rights to intervene whenever we feel it's necessary ie; we won't abandon
Tornado, and will still have input into its design.




Gavin I. Jenkins, [e-mail]

> How about adding system controlled animated icons?
>   Could be quite cosy for the user.

:-). And wastes processor time, memory and disc space. Contravenes all three
aims of Tornado. Sorry!

> Let the machine use JPEGs in the same way as Sprites

Done.

> Get some realy good support apps, eg. replace Edit with a badged version of
> Zap or the like.

Fraid we're not writing a completely new OS, just a few bits 'an pieces to
make the current a lot better. Anyone able to get Tornado will also be able
to get Zap etc etc - so there's little need to include it.

> Internet Stack built into OS.

Such a i/o method would use Tornado's central i/o methods, a bit like the
serial block drivers. Ie; essentially it would be a block driver that uses
TCPIP, although obviously the current restrictions on block drivers means it
wouldn't actually be a block driver. A Tornado block driver say? :-)





Jeff O' Keefe, [e-mail]

>   RISC-OS is a multi-tasking machine, but it is not a multi-user machine.
> Whilst I am not proposing that a full Unix-style solution is what is needed
> here, have you considered allowing for more than one person using a
> machine? This is a very common occurence it the machine is placed into a
> lab for public use.
>
>   If there was some way of saying "I am fred" etc, and having the machine
> then use all configuration files from a directory associated with "fred" it
> would save people having to continually re-configure the programs they use.
> The trouble is that different people like to set up the programs they use
> differently.
>
>   It may also be the case that a person may want to set the machine up
> differently if they are doing different tasks with the computer. They may
> like their text editor to behave differently if they are writing a C
> program than if they are writing a text document.
>
>   In a sense, this is like a login, but merely from the point of view of
> configuring the machine to personal preference. Passwords would not be
> necessary, and the machine would still work (a generic 'login') if you
> don't log youself in beforehand.
>
>   Your work sounds interesting and I wish you well. IU hope this may be of
> some assistance.

You mean something like that used by Windows '95? Certainly, I agree, and we
weren't going to do this, but we will now. Thanks. We'll try not to make it
as stifling as Win '95 though.




Samuel Kock, University of Pretoria, [e-mail]

> What about
> * Long file names (up to 50-100 chars would do)

If Acorn don't do it first. See STOP PRESS below.

> * 3D-ish Windows and menu borders. (like in Unix, Windows 95)

The window contents will be 3d, but not the windows themselves as that is the
Window manager's forte, and Tornado can't really involve itself there. :-(

> * True 'background printing'. (like Windows 3.x,95)

Done.

> That is all I can think of now, I'll mail again when I think of some more.

Cheers for the input.

> Are you developing this independantly of Acorn? Just thought I'd ask.

Yep, not even on the Acorn developer's list. They sorta didn't like me still
using RO2 and blatently refusing to upgrade to RO3 as I thought it wasn't
worth it. And I still believe that.

> Thanks for doing something. (At last!)

No problem. We'll do our best.




Ian Burley, news editor of Acorn User, [e-mail]

Quoting DigiLink Email Gateway:

> I'd be very interested to hear more about your work on developing Risc  OS
> - are you working for or with Acorn on this?

Quick summary:

For quite a while now, there has been a growing mass of Acorn users who are
disliking the increasing apathy with which Acorn have been treating RISC-OS,
and the grass-root users using their computers. Development really stopped
after the release of RO2, and RO3 onwards really are odd varients on RO2. You
may not believe me: but I still use RO2, never having seen the need to
upgrade, and 95% of software works. Check out all the stuff I twiddle from
your coverdiscs. Almost always works, even with things like Flux, which was
very RO3 specific. Bit slow on my antique though! :-)
   Essentially, we got bored chiming to Acorn about all the faults with RO
and nothing being done, and so we decided to start doing it properly. On our
own. We would start again from RO2, and lead development in a direction that
it was always meant to go in. Not Acorn's half-baked RO3 effort. And if you
thought RO3 was good, check out Tornado. As it was meant to be.
   We have virtual memory, OLE, hotlinking, TAOS-like subtasks, common file
renderers and editors - and this is just the beginning. By rewarding
programmers for using Tornado, the end users will also profit hugely. And
because programmers aren't being forced by Acorn into doing things they don't
want to (eg; using C and C++), they will write better. And this will benefit
the user again. Read the Tornado brief (v0.05 is the latest and best) ) -
much of it is technical, but you will understand what we are trying to do
here.
   Unfortunately, due to the rather large response from users, coding has
been delayed (currently two weeks behind schedule) but should be starting
sometime next week.

Okay, spiel over, Acorn have no involvement whatsoever in this. This is
purely a repeat of the Arthur & CC thing. Except Tornado is an alternative
running under RISC-OS, so you can still use RO and enjoy the benefits of
Tornado as well. We don't wish to hinder the RISC-OS development - if
anything, hopefully kick Acorn into doing something. And also Acorn can't
deliberately fix anything so Tornado won't work anymore. :-)
   In fact, Acorn are rather miffed over this. Like they were with CC back
before RO2. Tough I say.

I assume you want to do something in AU about this? If so, you may want to
know that release I of Tornado is timetabled for the 21st of August. Release
II is for Christmas 95. Release II is Summer 96. By then, I'll be going to
Uni so I probably will have even less time than I will in the coming year.
Hopefully others will be able to continue developement.

Hoepfully this is some help? Any questions feel free to ask.

Sorry for the delay - I was in England. Attending some computer-related
things, and clubbing :-).

Cheers,
   Niall Douglas, of the Tornado developer's group.







Replies to messages received from fidonet:

Richard Murray, 2:254/86.1

> Don't forget support for bi-directional parallel ports and other hidden
> hardware extras. Maybe you could make it like Windows, to take advantage of
> added hardware (like an sp_dual?)...

We'll do our best, by providing Tornado_IOOp to do all the non-media based
i/o. But that's about as best as we can do, as all hardware has its
peculiarites.

Update: We're now using a method similar to the file renderers to implement
i/o operations.




Charles Baylis, 2:254/86.2

CB> Is Tornado an add-on for RISC OS or a compatible replacement for the
CB> desktop.

Sort of both really. Difficult to explain - try the Tornado brief, available
from the DDBank.

CB> If it is an add-on, then I'd like to warn you that I personally don't
CB> like people using external library type things eg Interface, WimpExt, ABI
CB> etc.

Agreed. Tornado is more intrinsic, ie; use Tornado one bit and you use it
/all/. Either all or none. You may not like this, but it's bl**dy handy.
You'll see what I mean.

CB> However, you could tempt me to use it if you create an app creation
CB> interface which allows you to write code for an object in a template, ie
CB> double click on an 'OK' button in a template viewer, and write code in a
CB> new window. :-)

Fraid we are, but not for a bit yet. VisualTornado it will be called, after
the similar packages on the PC. And will work similarly too, although I do
hope to squeeze it into all of 50k of code ... :-)





Ol, 2:255/93.3

> I'm not too sure what this Tornado is all about but I'll download the
> information from somewhere and read about it. I have got several ideas that
> I would like to see in a new Risc OS mainly because I've just had to learn
> OS/2 at work and although most of it is crap, it has got some very good
> ideas.

Dunno about that. I thought OS/2 was quite good really. Has a funny feel to
it though.

> OK that's enough of my waffling! On with the wishlist:-
>  - Shadows of files and directories on disc so that it is stored once but
>    can appear many times, for instance !Spark in your comms directory and
>    graphics and etc.

Pencilled in. I like it, and hopefully we'll avoid this alias business.

>  - Decent window tidying eg cascading and tiling.

Pencilled in.

>  - Multiple desktops, one for graphics, one for comms, one for DTP etc.

Pencilled in.

> Hmm, I can't think of any more ATM. I'll try and remeber some other good
> stuff and write it down. Good luck with the coding - rather you than me!
> :-)

Tell me about it! :-) Coding started late last night with a preassembler ...
:-(




Chris Claydon, of currently unknown address

Quoting Chris Claydon:

CC> I think pre-emption is a great thing, but there are two serious problems
CC> with your implementation:

Go on ...

CC> o  It's not automatic, tasks have to ask to be pre-empted, so only
CC> tornado-aware tasks will be.

Exactly. This is because Tornado functions /alongside/ the Wimp, and has to
bend under the Wimp's idiosyncracies. Ie; to be a Wimp app, it can't run fully
as a preemptive task, as the Wimp really disencourages it. BTW, subtasks
probably will run under their own multitasker, as the Wimp doesn't like having
100+ tasks suddenly starting up and quitting soon later. Stupid bloody Acorn!
:-(

CC> o  Often important Wimp poll messages can disappear into the netherworld
CC> of surreality that is tornado's polling...

Read brief 0.03 (the latest released) yet? Obviously not ...

CC> Therefore, I have come up with another, more complete, more complicated
CC> way of doing the thing!
CC> Hopefully you will eventually be able to incorporate something like this
CC> in tornado. It really should have been done by Acorn years ago and, like
CC> most of Tornado, they might actually get round to it in RO4...
CC> Specifications for a new Wimp_Polling system with full pre-emption for
CC> ALL tasks, without the tasks requiring any knowledge of the new system
CC> and with no loss of polling information.

Tornado will use this method, thought of by the c.s.a.* boffins quite a bit
ago, for subtasks only, and maybe for Tornado tasks later. But not yet. Cannot
be done yet. Anyway, the structure has been carefully designed to allow for
this change as and when it happens/is possible.

CC> at a user defined delay, I would suggest that each task is given approx
CC> 0.5 cs usually. An optional new parameter to

Minor difficulty: internal RO timers are accurate to 1cs only. Real b**ch.
That's why Paul Corke of the Tornado developers team is writing a timer
accurate to 0.1ms. Problem is the RPC mainly, and it's IOMD chip.

CC> The hourglass is only shown while a SWI is being called. This is because
CC> pre-emption cannot take place during SWIs. The state of the hourglass is
CC> stored by the OS, and if it is on when a SWI is called, it is displayed.
CC> at all other times the actual state is ignored and the normal pointer is
CC> displayed.

:-). Easier and better to take the Tornado option, and use Tornado_File. A
replacement for OS_File. You get a background hourglass a la Win 95 then :-)

CC> The one problem I see with this system is that some software requires
CC> Wimp messages to be replied to within one poll. A possible solution to
CC> this is that if a task has a wimp message waiting for it, it is not
CC> interrupted until it has polled.

A most horrible problem, and is probably the main reason why preemptive apps
cannot be written for the Arc. And why your system won't work. Tornado's
preemption is just as effective as yours, and anyway what you've just put
needs the app really to be aware it's happening. Which is why it might as well
use Tornado instead! :-)

CC> Good luck with tornado, but don't forget about RO4.

I won't. From what I've had my sources tell me (some of the team are under the
NDA, and although they haven't said anything really, they still reckon Tornado
is vital) RO4 will contain little new. And it won't be out for quite a while.
So I, and we, are pretty safe we're not doing the same as CC with Arthur.

CC> I think you'd be best to develop tornado in association with Acorn. That
CC> way, you know what's happening in RO4 and you know what's not happening,
CC> which is more than anyone

Acorn grittily declined any participation. I think we've really irked them
with this y'know :-). Arm Ltd have been asking questions, and so have AU, and
a few companies around the place. I'm about to write replies soon. Acorn also
seem to have 'forgotton' my request for Tornado's SWIs etc. Odd that, innit?

CC> else does! I doubt Acorn will be too pleased if you do this without their
CC> consent, and when VM etc. are available in RISC-OS there will be a total
CC> mess if half the tasks are using RISC-OS VM and the other half tornado
CC> VM. In short,

They aren't! :-). Tough luck I say. Anyway, we decided with some debate to
make Tornado's VM compatible with whatever Acorn might put up in the future. I
daresay our's will still be better though. Read the brief v0.05 when it comes
out. Other things won't be compatible though. Tough luck again I say.

CC> make sure that what you do is totally compatible with what Acorn do -
CC> features of RO4 for other computers, using the same SWI names & numbers
CC> as Acorn do.

We'll be recoding a bit of RO3, as we don't like it much (pretty awful coding
really). Away with the Filer, display manager, task manager etc. DragASprite
is already gone. By the time we're finished, a lot of RO will be different.
And for the better we think. Especially as we'll /actually/ respond to what
the users want. Which is important.

CC> Phew! That took a while! I hope it's some use to you, I would do it
CC> myself, but I'm so busy with Immediate at the moment, I'll leave it up to
CC> you.

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

     ... Nana Na nanana .... (splat of green gremlin sludge) ... Gremlins are
          no match for mad pink leprechauns ...
--- FidoMail v.1.87 (21 Feb 1994)
 * Origin: Tornado BBS Cork, Ireland [Sat 9pm+ [phone]]   (2:257/501.13)







Other things not mentioned here:

I think I've covered everything in this reply, except maybe file renderers.
This is a centralised method of rendering files, and allows applications to
render any type of file, whether it be sound, vector, bitmap, movie etc. To
render a new type of file, it becomes simply a case of installing a new
renderer, whereupon all apps can then use it. This is how the Tornado demo
app, View, works.

STOP PRESS: The decision has just been made that if RO4 does not have a
filecore supporting infinite length names, infinite files per directory etc.
and release II of Tornado is out, we'll recode things so the above can be
used with release II.5. Okay, we've done it - made the decision! Now you guys
need to mailbomb Acorn so we don't have to do it! :-)


Any information contained above is subject to change.

Any correspondence to [e-mail], as I don't read the
newsgroups that often.

Cheers,
Niall Douglas, Tornado developers group.