home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / tornado / altguide2 / altguide
Text File  |  1995-10-01  |  26KB  |  461 lines

  1. The Tornado operating system
  2.  
  3. by N. Douglas (ndouglas@digibank.demon.co.uk)
  4.  
  5. This is the alternative second edition of the guide to the tornado operating
  6. system. It attempts to cover most facets of tornado from an average users
  7. perspective, while being still detailed enough for a programmer to not find
  8. it boring :-).
  9.  
  10. For the uninitiated, the tornado operating system runs under another
  11. operating system, RISC-OS. This operating system comes with the range of
  12. computers running on the Arm series of CPU's made since the Acorn A3000.
  13. Older machines using the Arm CPU can also run RISC-OS, so long as the
  14. propriatary hardware (MEMC1a, VIDC etc) is also available and is arranged
  15. similarly to the archimedes series - also, any hardware compatible with the
  16. original archimedes design should have no problems.
  17.  
  18. Problems with RISC-OS:
  19. ----------------------
  20.  
  21. While RISC-OS was originally constructed during the late eighties, it still
  22. compares quite well to the latest operating systems from Microsoft, IBM and
  23. Apple. However, it's age does show in many areas, and the only reason why it
  24. can still be considered alongside other operating systems is because of
  25. original design strengths in the original release.
  26.  
  27. Advantages of RISC-OS over other operating systems:
  28.  
  29.   * Extensive drag & drop facilities. RISC-OS allows dragging and dropping
  30. from almost everywhere to everywhere else on the screen. This increases
  31. intuitivity incredibly, but *only* when it's used to its full effect. Often
  32. it isn't.
  33.  
  34.   * The ability of a program to assume complete control of the processor. In
  35. multitasking operating systems, RISC-OS assumes the dubious status as the
  36. only one to use non-preemptive multitasking. The great advantage of this is
  37. the ability for a program to hog the processor and use all its power.
  38.  
  39.   * No application has control or precedence over others. This means you can
  40. select a group of objects in a window belonging to another program currently
  41. behind windows belonging to yet another program. While that might sound
  42. complicated, System 7 shows how irritating not having this can be. You can be
  43. working on something, and want to copy a file. Selecting a file in the
  44. Finders window behind the main window brings all the Finders windows to the
  45. front and now you can't see the main work window anymore.
  46.    A similar problem exists will Windows 95 - except that each filer window
  47. is its own task, so clicking in it only brings one window to the foreground.
  48. But still it shows that the application that the user is working with has
  49. precedence over any others.
  50.    This also shows in dragging and dropping. In RISC-OS you can drag a file
  51. out of one program into another. No other operating system allows *that* type
  52. of flexibility and power.
  53.  
  54.  
  55. Advantages of other operating systems over RISC-OS:
  56.  
  57.   * Multitasking on other systems is far more fluid and consistant. On
  58. RISC-OS, multitasking seems a very 'bodged' affair indeed - things like
  59. printing, or even disc i/o don't multitask [1]. If you get programs to do a
  60. lot of processing, RISC-OS slows down incredibly. Multitasking on a heavily
  61. loaded RISC-OS desktop is like watching a demo run at 12fps.
  62.  
  63.   * All tasks on RISC-OS are equal. This means that as far as RISC-OS is
  64. concerned all tasks get equal processor time, and no task may get more than
  65. another. This prevents an important process from getting more time so that
  66. it gets completed quicker.
  67.  
  68.   * Tasks on RISC-OS take as much processor time as they want. There is
  69. nothing to stop them giving up control every second. If every task on RISC-OS
  70. did that, RISC-OS quickly becomes unusable.
  71.    On other systems, a central multitasker handles how much time each task
  72. gets. This allows the multitasker to give less or more time to each task
  73. depending on circumstances.
  74.  
  75.   * Writing programs to run under RISC-OS is a real chore. While the
  76. interface to the desktop is very flexible, it is also very manual, with each
  77. task doing an awful lot of work for very little initial gain.
  78.  
  79.   * Programs not written to multitask on RISC-OS can't be made to. In other
  80. words, run a single-tasking program and it will hog the machine until it
  81. decides to finish. With many programs, you can't interrupt it without having
  82. to start it up all over again.
  83.  
  84.   * Programs which crash on RISC-OS aren't handled well. Currently, when a
  85. program tries to access memory not available to it a box appears saying at
  86. best 'Fatal error ...' and multitasking stops until the user acknowledges
  87. the message. On Windows 95, if a program crashes to the extent multitasking
  88. stops, you can hit a hotkey and windows will ask you if you want to terminate
  89. it. Or if you wait long enough, this happens automatically.
  90.  
  91.   * External access isn't handled well. RISC-OS contains no standard
  92. provisions for network access [2], and to use the serial or parallel port is
  93. fiendishly complicated.
  94.  
  95.   * RISC-OS does not adapt to its situations. RISC-OS fundamentally is still
  96. designed to work well on an Arm2 TV standard resolution 512k machine. Running
  97. it on an Arm700 series XGA+ 256Mb machine does not give huge improvements.
  98. Nor does plugging in a SCSI card automatically cause it to be registered and
  99. usuable. You have to go through a whole range of programs first.
  100.  
  101.   * RISC-OS has a very limited method of managing memory. The shared resource
  102. of the RMA gets badly fragmented, leading to huge quantities of memory being
  103. wasted after extended use. Data up to memory available can normally only be
  104. edited, as RISC-OS does not provide virtual memory of any kind. These
  105. restrictions cripple programs running under RISC-OS.
  106.  
  107.   * The facilities offered by RISC-OS to its programs are mediochre. They
  108. never were great - in my mind never finished - but little things like OLE,
  109. external editing of files, hotlinking, multiple views in different
  110. applications, standardised scrap filing etc really detract from the power of
  111. RISC-OS.
  112.    Also, there is no standard method of making code multithreading. You can't
  113. have a spreadsheet in one window recalculate while you work on another in
  114. another window in the same program without a lot of hacking on the
  115. programmer's part. Very few programs offer this, and quite rightly too.
  116.  
  117.   * RISC-OS does not provide help for users. Compared to Windows 95, where
  118. things are stepped through bit by bit by detailed hypertexted documents,
  119. RISC-OS just displays a message up to 256 characters in a window.
  120.  
  121.   * Filetypes are incompatible. Trying to load a GIF into Paint usually won't
  122. work, unless you run it through an intermediate program to convert it first.
  123. RISC-OS is extremely inflexible in this area - add to the above, neither will
  124. it display unknown file formats in their native format. This means costly
  125. amounts of memory being used to view a compressed filetype.
  126.  
  127.   * A lot of the RISC-OS window manager has become obsolete. Things like window definition blocks specify a whole amount of information which it nowadays totally useless. This in turn has led to a very bodged 'pretty' effect on the RISC-OS desktop, and things get very messy.
  128.  
  129.   * RISC-OS does not offer superior compression facilities, and neither is it
  130. particularly future-proofed. RISC-OS 3 offers Squash, a facility difficult to
  131. use and can only use LZW compression, which compresses badly on many formats
  132. (eg; sound). This relates to the point above in the way that a program can't
  133. play an MPEG or Replay without using one of a dozen propriatary methods.
  134.    RISC-OS still uses a combination of 'magic numbers' and RGB to specify colours, and so the latest machines facilities aren't used to the fullest. This relates to how RISC-OS doesn't expand to the machine it's living in.
  135.  
  136. [1] when I say disc i/o doesn't multitask, I refer to all disc i/o. Things
  137. like file copying and formatting multitask due to the revised filing system
  138. on RO3+, but simple loads and saves don't.
  139.  
  140. [2] I discount Econet here in this statement. Acorn's propriatary Econet was
  141. very clever - but by the time the Archimedes series was established it was
  142. woefully outdated. Newer versions of RISC-OS do contain Acorn's TCPIP stack,
  143. but the way it integrates into the environment is shoddy at best. Something
  144. coming closer to Window 95's method is a better idea.
  145.  
  146.  
  147. As you can see, the list of cons far outweighs the list of pros. And note
  148. nothing has changed much since RISC-OS 2. RISC-OS 3 added a large number of
  149. extensions to the original RISC-OS, but a lot of these have since been
  150. replaced with third-party extensions. In some people's minds, RISC-OS 2 never
  151. got finished.
  152.  
  153. The future:
  154. -----------
  155.    So how does this affect everyone in the future? Well, more than likely
  156. Acorn will adopt a propriatary multiprocessor system based loosely around
  157. TAOS, and will rewrite RISC-OS to run on it [3]. This RISC-OS that we see may
  158. be considerably different to the one we know today.
  159.    For a start, it probably will implement mulittasking in the kernel, and
  160. the GUI will be shifted into assemblation with the kernel, like Fileswitch.
  161. In fact, a lot of RISC-OS may be changed to function like other operating
  162. systems, probably based a lot on Unix. More than likely life will be
  163. considerably different.
  164.  
  165. [3] I base this on that Acorn are unlikely to develop a completely new
  166. operating system completely incompatible with existing RISC-OS programs. I
  167. would suggest they'll bung a dozen Arm's together and rewrite RISC-OS to use
  168. the multiprocessor facilites. Meanwhile, old programs can still run correctly
  169. by being only executed on one processor. In other words, only new programs
  170. would fully exploit the multiprocessing latitude.
  171.  
  172. But we're not here to talk about the future of RISC-OS - or are we? In many
  173. ways, what tornado implements is what the future RISC-OS's will have - in one
  174. form or another, because tornado should still be able to run on a
  175. multiprocessing machine just like existing programs.
  176.  
  177. Probably the best way to show how tornado is going to do this is to comment
  178. on that long list of pros and cons I gave above. Keep reading - but please
  179. feel free to skip anything you don't understand completely.
  180.  
  181. The advantages of tornado:
  182. --------------------------
  183.  
  184. Extensive drag & drop facilites ...
  185.    Tornado preserves that, and also automates a lot of it through its visual
  186. editor. It also adds standard facilities for OLE, hotlinking, external
  187. editing and multiple viewing. All these, shared amongst all programs, makes
  188. the desktop considerably more powerful.
  189.    Another minor fact is that any files loaded into or being edited by a
  190. tornado application are in actual fact owned and managed by tornado, not the
  191. application. This allows tornado to share files between tasks, or to save
  192. files out when an application crashes. The amount of usability gained by this
  193. single addition is incredible.
  194.  
  195. The ability of a program to assume complete control of the processor ...
  196.    Also preserved by tornado programs informing tornado when they're going to
  197. do this. This allows tornado to start preempting them, or if suddenly polling
  198. stops without tornado being informed tornado can start up the crash handlers.
  199.  
  200. No application has control or precedence over others ...
  201.    Under tornado, an program can be given more time easily [4].
  202.  
  203. Multitasking on other systems is far more fluid and consistant ...
  204.    Under tornado, all programs are preempted under the tornado multitasker,
  205. which runs alongside the RISC-OS multitasker, the window manager. To decribe
  206. how the tornado multitasker is outside the scope of this document (but there
  207. is more information at [4]), but be assured that it intelligently uses a
  208. combination of preemptive and non preemptive multitasking and multithreading
  209. to vastly improve program performance.
  210.    One of tornado's main aims to to improve multitasking. Printing and *all*
  211. disc i/o under tornado multitasks [5] and subtasking is available to have
  212. heavy processing done by tornado and not by your task [6]. An incredible
  213. difference shows when programs are written properly - the desktop becomes
  214. fluid, and tasking does not halt momentarily.
  215.    Also, I'll just mention that while tornado programs run entirely under
  216. their own multitasker, and do not use the Wimp whatsoever, tornado uses the
  217. Wimp to put tornado windows alongside Wimp ones, allowing partial interaction
  218. of the two systems as far as the Wimp can be made to go. Note also that
  219. tornado redraws its own windows, including frames, and these different window
  220. frames posess quite a few additions to make life easier, like an iconise
  221. button [7].
  222.  
  223.  All tasks on RISC-OS are equal ...
  224.    Well, they aren't on tornado! :-)
  225.  
  226. Tasks on RISC-OS take as much processor time as they want ...
  227.    Again, under tornado they get given what tornado gives them. They may ask
  228. for full processor control, and while they may get it they also may not.
  229. Either way, the task will not know if it is still being multitasked.
  230.  
  231. Writing programs to run under RISC-OS is a real chore ...
  232.    Tornado runs programs written in a 'visual' manner. While programmers can
  233. do this manually, it is even more work than the RISC-OS method - far better
  234. is to get the tornado visual editor [8], which allows combination of C,
  235. assembler and Basic in one program. To write a program visually, you create a
  236. window template frame. To this frame you create windows, and in the windows
  237. you create icons. To the icons you then attach sections of code in C,
  238. assembler or Basic. You can also attach code to user-defined tickers & timers
  239. and events, or attach code to windows themselves. By the way, when I say
  240. 'attach' I mean it very literally - you actually drag a tool/link etc from
  241. the toolbox/linkbox etc onto an icon/window.
  242.    You then can save the executable, which amalgamates all the code into the
  243. various files and saves the entire lot as a directory. This approach to
  244. programming makes writing multitasking code so easy and quick.
  245.  
  246. Programs not written to multitask on RISC-OS can't be made to ...
  247.    Under tornado, when you hit f12 a window opens on the screen with the
  248. *-prompt in it. When you double-click on a Basic program, a window opens and
  249. the program gets executed in it. Or if you wish, the program can take over
  250. the machine like it used to - but if you want to visit the desktop, hitting a
  251. hotkey will bring you there, while the program continues to multitask on its
  252. own. Another option available is for the program to take over the screen and
  253. sound, but multitasking continues in the background. This allows multitasking
  254. servers eg; fax servers to continue to work, but still allow you to see the
  255. program's display in its entirity. Note that only programs that are enabled
  256. to do so will multitask during full-screen operation - so a word processor
  257. for example wouldn't multitask if you didn't want it to - leaving more
  258. processing power available for the full-screened task [9].
  259.  
  260. Programs which crash on RISC-OS aren't handled well ...
  261.    When a program crashes, for whatever reason, polling is suspended on that
  262. task and a window appears and asks the user what he/she wants to do about it.
  263. The user may choose to continue regardless, or save out the files currently
  264. being edited by the program and then force an exit.
  265.    This also applies when an application decides to depart without telling
  266. anyone. Whatever files loaded into that application can be retreived. Or, if
  267. you want, when an application shuts down due to an error, its files can be
  268. saved out and a new copy of the application loaded in and the same files
  269. reloaded back into it. And all this happens in the background, while
  270. everything multitasks along nicely ...
  271.  
  272. External access isn't handled well ...
  273.    On tornado, a number of device drivers exist. Quite simply, tserial:
  274. refers to the serial port, tparallel: refers to the parallel port
  275. [THIS WILL BE FILLED IN LATER AS AND WHEN THE DETAILS ARE FINALISED]
  276.  
  277. RISC-OS does not adapt well to its situations ...
  278.    Unlike RISC-OS, tornado uses its advanced memory management facilities to
  279. make full use of any memory available to it. It also uses any disc space you
  280. have for virtual memory (and note only whatever shouldn't go into RAM goes on
  281. the disc, thus losing you the disadvantage of other system's swap files which
  282. must be a multiple of RAM size etc). Tornado uses the 24 bit RGB method to
  283. describe colours in all cases. For higher spec machines, tornado will
  284. calculate and render appropriately scaled down sprites and icons for the
  285. current palette/screen mode. On the other hand, if you have a low powered
  286. machine but a large fast hard disc, tornado will cache any rendered
  287. sprites/icons on disc, with a secondary cache in memory, thus not hacking out
  288. more CPU power than is necessary.
  289.    Unlike RISC-OS, the tornado system heap can be any size up to machine RAM
  290. size (the RMA has a limit of 4Mb); applications can have a slot of anything
  291. up to machine RAM size too (RISC-OS limits this to 16Mb); both of the low and
  292. high resolutions tornado shared sprite and icon pools can be up to machine
  293. RAM size too.
  294.    Also, under tornado, when you open the top and plug a SCSI interface card
  295. in, it automatically is installed and becomes immediately available for use.
  296. No more twiddling with configurations, although this still can be done if you
  297. really want!
  298.    Now, whether you own the latest RiscPC 700 series or a lowly Arm2 A310,
  299. you will have a system than runs appropriately to your computer's available
  300. resources.
  301.  
  302. RISC-OS has a very limited method of managing memory ...
  303.    Tornado implements a vastly enhanced memory managment system, which is
  304. available for all programs to use. It allows private heaps, RMA heaps, heaps
  305. in heaps, postslot heaps and of course it manages the tornado system heap, as
  306. well as the task and sprite pools.
  307.    Tornado's heap manager provides autogarbaging, autoextending,
  308. autopositioning heaps. You can allocate a fixed block or relocatable block
  309. from them. Relocatable blocks can and will move without your knowledge - but
  310. your handle, a negative number, remains constant at all times. Also, you can
  311. get a relocatable block from a heap in a relocatable block in a heap in a
  312. relocatable block in a heap. And if that bottom heap is too small, it will
  313. extend any or all of the heaps above it to fit that block in.
  314.    And of course, one of the best advantages of this is that blocks allocated
  315. from the tornado system heap can be of almost any length, even beyond machine
  316. RAM length [10].
  317.  
  318. The facilities offered by RISC-OS to its programs are mediochre ...
  319.    As mentioned above, tornado provides visual editing, allowing programs to
  320. be generated in very short times. A large library of code is provided via
  321. SWIs and example code fragments in external libraries to interface with
  322. tornado. Talking to other computers is no longer so horrible: the tft: device
  323. allows file transfers to other computers, thus saving your program of
  324. worrying about how it's being done eg; zmodem or TCPIP ftp?
  325. [MORE WILL BE ADDED HERE AS AND WHEN THE DETAILS ARE FINALISED]
  326.  
  327. RISC-OS does not provide help for users ...
  328.    Tornado provides two levels of help. The first pops up a message saying
  329. where in the manual you should look (this is recommended). The second level
  330. provides a hypertextualised document reading system which allows automation
  331. of many complex configurations by filling in default values. At all times,
  332. all of this help text may be partially or wholly installed or deinstalled:
  333. ie; when using a program for the first time the help texts would be
  334. installed. When you know it well enough, or if you have asked for a default
  335. expiry time (say three weeks), the texts can be removed, thus returning disc
  336. space.
  337.    Or, if you still use a floppy machine (or have no HD space left!), the
  338. help can be left out. This prevents what has happened on Windows, where half
  339. of the HD is full or help texts you don't need anymore.
  340.    Note also that you may choose to have the help texts archived - this saves
  341. 50% of the space needed while only delaying retrieval by a small bit.
  342.  
  343. Filetypes are incompatible ...
  344.    Dragging a GIF file into a tornado program which can only understand
  345. Sprites starts up one of a set of specialised subtasks, which convert the GIF
  346. into a sprite, and when saved will convert it back again. Also, tornado
  347. provides renderers, which will render files in their native format for the
  348. application. It will be up to the application to edit the file though -
  349. however, this still allows DTP programs to display files in their original
  350. format without worrying what they are.
  351.  
  352. A lot of the RISC-OS window manager has become obsolete ...
  353.    Tornado uses future-proofed formats. It has no limit of any lists it uses
  354. internally, and uses 24 bit colour wherever it can. Defining a window in
  355. tornado is a short block of data, although using the visual editor will save
  356. you of ever needing to worry about those things.
  357.  
  358. RISC-OS does not offer superior compression facilities ...
  359.    Internally, tornado uses compression in many places eg; in many of its
  360. internal file formats and on the virtual memory cache, as data can be
  361. decompressed on the fly while being read in. Tornado's file renderers can
  362. also render movies and sound - this opens MPEG's and JPEG's to everyone's
  363. view. Tornado on request can compress everything saved out (thus resulting in
  364. a similar effect to DOS 6's DoubleSpace or whatever), or whatever it really
  365. wants.
  366.  
  367. [4] In reality, it will be given a percentage of available CPU power.
  368. 'Available power' means the amount of processor bandwidth left over after
  369. system processes are performed. System processes include disc i/o, printing,
  370. serial i/o, all subtasks and maintance of them, and anything performed by
  371. tornado. Therefore, a fully loaded system would have all the application's
  372. percentages add up to 100%. A system running into overprocessing would have
  373. percentages exceed 100%. Usually tornado manages what percentages of power
  374. each application gets, and it's only when the user overrides tornado can
  375. overprocessing happen.
  376.    However, on a less powerful system (Arm250=<), overprocessing could happen
  377. if system processes exceed the CPU power available. This would result in
  378. non-system tasks not being multitasked at all until the overprocessing
  379. ceased, or if the user has configured it then system tasks are denoted in
  380. priority so they are treated as normal tasks. This would mean that system
  381. processes may fall behind, but still relatively normal system operation would
  382. be maintained.
  383.  
  384. [5] Note that depending on the media being accessed, disc i/o may single-task
  385. for efficiency reasons eg; Loading in a file from a 1770 based floppy while
  386. multitasking is incredibly slow, so it would probably be single-tasked.
  387. Tornado is intelligent in this regard, and it adjusts its access parameters
  388. (amount loaded in a cycle, time between accesses etc) on the fly while the
  389. file is loaded. Then it may cache the values for use later on either in
  390. memory or permanently on disc.
  391.  
  392. [6] The only essential differences between subtasked code and normal code are
  393. that subtasked code is executed at a higher priority, and that multithreading
  394. your code is much easier with subtasks (and multithreading Basic MUST be done
  395. via subtasks). However, on later hardware, tornado may execute subtasked code
  396. on an external processor - thus allowing massive speed gains. For these
  397. reasons, it is suggested writers use subtasks as much as possible.
  398.  
  399. [7] Tornado windows are rendered entirely by tornado. They are integrated in
  400. the RISC-OS Wimp environment by creating a Wimp window with no icons, title
  401. or even frame (it's made transparent). Then tornado handles dragging,
  402. resizing etc of the wimp frame according to what's being done to the tornado
  403. window contents.
  404.  
  405. [8] Note that only a very basic editor will be supplied in the Tornado
  406. programmers pack. A much much extended editor will be available for the sum
  407. of £50 from the Tornado software group. This is because it is assumed most PD
  408. writers will want to do it the hard way anyway, and commercial writers by
  409. right should pay someone for all our hard work!!! (since they have the
  410. money!) :-)
  411.  
  412. [9] Note this may have difficulties with single-tasking programs which do not
  413. use the vdu calls ie; almost all games. Therefore, there is an option to halt
  414. tasking on programs like this ie; - not to mulitask them when you have exited
  415. temporarily to the desktop.
  416.  
  417. [10] Some have expressed concern why we haven't done full virtual memory,
  418. whereby code can run in virtually paged space as well as having data reside
  419. there. The reason is that RISC-OS obstinantly refuses to allow this with some
  420. hacking (a la !Virtual), and anyway I personally have objections to providing
  421. virtual memory for code. Data no problem - you can edit large files - but
  422. code, well I don't like the idea. And hey, it's my OS, so I can do what I
  423. like! :-)
  424.  
  425.  
  426.  
  427.  
  428. Other things provided by tornado:
  429. ---------------------------------
  430.    Many would argue that tornado has wonderful features and all, but what use
  431. it is to anyone unless there are programs written to use it? Well, there is
  432. another aspect of tornado: the patching.
  433.    Tornado patches itself into much of RISC-OS to implement multitasking disc
  434. i/o, better crash handling etc. Little things. There is not much that can be
  435. really done under the current implementation of the window manager, but what
  436. can be done is.
  437.  
  438. I would think that when writers get a hold of the visual editor, tornado will
  439. soar off, simply because that in comparison to RISC-OS, there simply is
  440. nothing like it. ResEd is very clever and all, but it simply can't bypass the
  441. inherent restrictions the Wimp places on tasks running under it. And it
  442. doesn't allow Basic to be used in code, and as the amount of programs out
  443. there that are written in this language show, they is still quite a bunch of
  444. people who want to use it.
  445.  
  446.  
  447.  
  448. More information:
  449. -----------------
  450.    More information is available at micros.hensa.ac.uk (find by doing a
  451. search for 'tornado' in the acorn section), the demon shadow of hensa, or the
  452. imperial mirror. Also, most of the larger Acorn BBS's will have a copy, or
  453. have access to one.
  454.  
  455. If there is no other option, or you have some clever insight you'd like to
  456. share with the programmers, I'm available at ndouglas@digibank.demon.co.uk,
  457. or Riscnet#7:363/101.0 - whatever suits.
  458.  
  459. Thanks for taking the time to read this,
  460. Niall Douglas, tornado developers team.
  461.