---
created_at: '2015-06-30T16:49:31.000Z'
title: The Taos Operating System (1991)
url: http://www.dickpountain.co.uk/home/computing/byte-articles/the-taos-operating-system-1991?hn
author: vezzy-fnord
points: 110
story_text: 
comment_text: 
num_comments: 93
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1435682971
_tags:
- story
- author_vezzy-fnord
- story_9806607
objectID: '9806607'

---
[Source](http://www.dickpountain.co.uk/home/computing/byte-articles/the-taos-operating-system-1991?hn "Permalink to The Taos Operating System (1991) - dick pountain's pages")

# The Taos Operating System (1991) - dick pountain's pages


| ----- |
| 

## [dick pountain's pages][1]

 | 

Search this site

 |  
| 

* [Home][2]
* [Blogs][3]
* [Biography][4]
* [Computing][5]
* [Photo Gallery][6]
* [Paintings][7]
* [Cool Quotes][8]
* [Materialism][9]
* [Music][10]
* [Sampling Reality][11]

 |   |

| ----- |
| 

* [Home][2]

    * [Biography][4]

    * [Blogs][3]

    * [Computing][5]

        * [Byte Articles][12]

            * [Limits of Computing (1997)][13]

            * [Oberon/F (1994)][14]

            * [Parallel Course (July 1994)][15]

            * [The Oberon Language (1990)][16]

            * [The Oberon System (1992)][17]

            * The Taos Operating System (1991)

        * [PriPar Machines][18]

        * [Ruby Projects][19]

            * [Maths Libraries][20]

            * [Shoes projects][21]

                * [Creatures][22]

                * [Equation Solver][23]

                * [Factoriser][24]

                * [MatrixCalc][25]

                * [WordSieve][26]

        * [Scratch projects][27]

        * [Simpleware][28]

            * [Download page][29]

    * [Cool Quotes][8]

    * [Materialism][9]

        * [Sampling Reality][11]

    * [Music][10]

        * [A Sad Canticle][30]

        * [Algorhythmics][31]

        * [Béla Bartók][32]

        * [Just Plain Wrong][33]

        * [Just Plain Wrong][34]

        * [Spotify playlists][35]

    * [Paintings][7]

    * [Photo Gallery][6]

        * [Flickr Top 200][36]
* [Sitemap][37]

 | 

[Home][2]‎ > ‎[Computing][5]‎ > ‎[Byte Articles][12]‎ > ‎ 

###  The Taos Operating System (1991)

| 

_{This material originally appeared in the March, 1991 International Edition of Byte magazine, a McGraw-Hill publication} _   
  
To describe TAOS (pronounced 'dowse' as in the oriental religion Daoism) as an   
innovatory operating system would be a profound understatement. It has so few   
points of similarity with operating systems like MS-DOS that many observers,   
myself included, have initially had trouble believing in it at all. For one   
thing TAOS is strongly Object Oriented and makes almost no distinction between   
data files and executable programs. It brings together many advanced ideas   
about Persistent Objects, Object Oriented Virtual Memory and Dataflow   
programming into one wholly novel system. It is a parallel operating system   
which configures itself automatically to run on a network of distributed   
processors and load-balances itself. More incredibly still, it promises to run   
exactly the same code on different processors in a heterogeneous network (eg.   
a mixture of Inmos Transputers, Intel 80386 and Acorn ARMs); it offers CPU   
transparency.   
  
Before proceeding I must stress that TAOS is not finished yet and there are no   
commercial ports of it in use. Some of the radical features mentioned above   
are only partially implemented at the time of writing. This article is   
therefore more of a preview of the concepts in TAOS than a full 'review'.   
  
TAOS is being developed by Tao Systems UK Ltd., a small firm that has existed   
for about 9 months, and whose leading spokesmen are Nick Spicer and Chris   
Hinsley, two experienced programmers from very different backgrounds. Spicer   
was a founder member of the European arm of Microway, the US firm which   
specialises in high-performance floating point hardware and more latterly in   
Transputer products. Spicer was Technical Manager and systems programmer.   
Hinsley on the other hand is a veteran games programmer, an assembler wizard   
who has been responsible for successful Atari ST and Amiga games like   
'Verminator' and 'Onslaught'. Though writing exclusively in assembler, Hinsley   
developed an Object Oriented style for writing games based on extensive macro   
libraries, and this provided the original inspiration for TAOS. Spicer added   
the parallel aspects to TAOS, based on his experience with Transputers and his   
dissatisfaction with Occam.    
  
**VP CODE**  
Perhaps the most important thing to understand about TAOS, before even   
discussing the way it works, is that it is designed to execute a virtual   
machine language called VP (for Virtual Processor). VP is the binary code of   
an imaginary RISC-like processor with about 32 instructions, designed by Tao   
Systems. In order to execute VP on a real processor, a translator will be   
provided from VP into the native machine code of the target processor.  
The ingenious part is that the translation takes place at program load time,   
not during runtime as some erroneous reports have stated. This is NOT an   
interpreted pseudo-code as used in the UCSD P-System or POP-11. When a program   
module is loaded onto a Transputer node it will get turned into Transputer   
code before it is run, whereas if it gets loaded onto an 80386 it will be   
turned into Intel code.    
  
Tao Systems is currently committed to produce translators for the Inmos T800   
transputer, Motorola 680x0, PgC7600 (see article in this issue), Intel   
80386/80486, Acorn ARM and Sun SPARC. Of these the first three have been   
written. The TAOS program loader, called ALEX, is part of the kernel that runs   
on each node in a parallel computer, and as ALEX loads each program module it   
performs the native code translation and optimization. Because TAOS is   
extremely modular in nature and employs a novel late binding scheme, the size   
of each module to be translated will be very small, and since all the target   
processors are powerful CPUs the time taken up in translation should be quite   
small. ALEX is not yet completed and the prototype TAOS systems which have   
been demonstrated employ a conventional VP assembler to produce executable   
native code. Tao Systems seems confident that the design of the VP instruction   
set is such that writing the individual translators should not be too   
difficult, even to such un-RISC like processors as the 80486.   
  
So the first point about TAOS is that everything in it (apart from the native   
code kernels at each node) consists of VP code, including all the applications.   
A parallel TAOS program consists of a number of tool modules which you can run   
on any mixture of the supported target processors without even knowing what   
they are. If TAOS becomes established as an operating system then compilers   
from C and other languages into VP will undoubtedly emerge.   
                               
**OBJECTS **  
Everything in TAOS is an object, and as in traditional OOPS, objects contain   
both code and data. Under TAOS the code part is called a 'tool', equivalent to   
a 'method' in conventional OOPs. Even what would be considered data files   
under a conventional OS are objects which have tools that can for example   
display their name, and check the access rights of a user.   
  
All the executable code in TAOS is contained in tools. Tools must be fully re-  
entrant, relocatable and side-effect free and cannot therefore contain static   
data; so TAOS groups data and code together into objects, but rigorously   
segregates code from data within an object. Tools are the smallest units of   
executable code under TAOS so you can think of them as being like subroutines,   
or C functions, or Pascal procedures. However tools are independently   
executable so a better analogy would be with Forth, where words can always be   
executed directly without having to call them from a main program.   
  
Some tools are called 'permanent tools' and get loaded up by the boot system;   
these form the heart of the operating system itself. Some tools are 'semi-  
permanent' and these are loaded at boot time by a user-created configuration   
process, but once loaded they and become part of the operating system and   
cannot be de-activated. These tools are roughly equivalent to the device   
drivers and extensions loaded by CONFIG.SYS and AUTOEXEC.BAT under PC-DOS.   
  
Finally there are 'application tools' which are the user executable programs   
of TAOS. Application tools can be 'virtual' or 'non-virtual'. Non-virtual   
tools are loaded with the application and remain in memory until it is de-  
activated (ie. quits). Virtual tools only get loaded into memory when the   
application calls them, and when they cease to execute they can be marked as   
'freeable' and the space they occupy can be reclaimed for use by another tool.   
Virtual tools are quite similar in concept to Borland's VROOM system or to   
OS/2's Dynamic Link Libraries. Virtual and non-Virtual tools are collectively   
referred to as 'external' tools and they have names that resemble PC-DOS or   
Unix pathnames by which they are accessed. They are normally cached so that a   
subsequent access does not need to reload them from disk, unless memory is in   
very short supply. An application in TAOS thus consists largely of named   
references to external tools, allowing a great degree of reuse of code, and   
keeping the individual executable units very small.   
  
As well as external tools TAOS has 'library' tools and 'local' tools.   
Library tools are kept in named libraries and can be shared by many   
applications; like external methods they are cached for future use. Local   
tools are part of the actual code of an application and have single unique   
names, not pathnames. A local tool always overrides any external tool with the   
same name.    
  
All TAOS programs are started up by a 'control object'. A control object is   
primarily a data object, a sort of template, which contains all the   
information necessary to load and run the tools which make up the program, but   
it also has code which sets the loading of tools in motion. A control object   
roughly corresponds to a task or process in other operating systems. It will   
contain a list of the pathnames of all its component tools, the stack space   
each one requires and a bit-mask which define what kind of messages it will   
accept. Control objects are executed by the permanent TAOS kernel which   
resides on each node of a parallel system, which then loads and runs the   
necessary tools. Control objects can spawn children, and it is by this means   
that TAOS programs distribute themselves around a parallel processor network.   
Control objects can be inactivated without being removed from memory, and may   
then be woken by other control objects sending them mail messages.   
  
One way of looking at the TAOS tool system is that all programs employ very   
late, ie. loadtime or runtime, binding. Programs assembled or compiled under   
TAOS will not need to be linked for linkage occurs when a program is run,   
under the control of its control object. You can recompile a single tool   
without recompiling the whole application, and even design applications that   
load different tools according to the runtime environment they encounter.   
  
**MAILBOXES **  
TAOS is a message passing operating system which uses 'mailboxes' for   
communication between processes. All program I/O takes place through the mail   
system, as does the distribution of executable code. Every control object is   
automatically given a mailbox by TAOS, and can send or receive mail from any   
other object whose mailing address it knows. These will always include its own   
parents and children and any named resources like disk drives and VDU displays,   
and may also include its siblings if measures are taken to record their   
addresses when they are created. The kernel on each TAOS node has a permanent   
Mail Guardian tool which handles all incoming mail for local objects on that   
node, all outgoing mail, and mail which is to be forwarded to another node.    
  
The format of a TAOS mail messages includes a header that contains the size and   
type of a message. There are 16 predefined message types including system,   
executable code, error data, and debugging data and the programmer can use   
numbered types up to 255 to make private communications between two objects.   
The type mask allows the Message Guardian to trap system messages such as   
executable code destined for the kernel, and it also allows user objects to   
prioritize the way they read their waiting mail by type.  
  
The header also contains the addresses of the originator and destination of the   
message, of any other intended recipients for forwarding, and where a reply (if   
one is requested) is to be sent. Mail can be sent to an inactivated object,   
and may re-activate it as a child of the sender object so it can read the   
message and respond immediately. In other circumstances such a message may   
just sit in the inactive object's mailbox until some other event wakens it. If   
such an inactive object gets removed due to a shortage of free memory, any   
pending mail is stored in the object's filefolder (ie. is written to disk) and   
re-sent next time the object is loaded. This might also happen when the TAOS   
system is closed down, so that messages as well as objects can be persistent.   
  
TAOS dynamically allocates the buffers that receive mail messages. In the   
event that there is not enough memory to create the buffer, the Guardian reads   
the header, discards the message data and replies to the sender that the   
message has been trashed. The sender can then retry using a different route.    
   
**FILEFOLDERS**  
TAOS stores objects onto mass storage media like hard disks via the mailbox   
system, in objects called 'filefolders'. A filefolder has some similarities to   
a DOS or Unix directory, but rather than being a passive storage structure it   
is an active object (in fact a control object). The tools attached to every   
filefolder are responsible for storing and retrieving objects from the folder   
and for negotiating with the hardware device drivers that are necessary for   
this transfer. Because filefolders are actually instances of a broader category   
of TAOS object called 'filters' they may also process the data they transfer,   
for example compressing and expanding it transparently to the user.   
  
I mentioned above that TAOS tools have pathnames like those used to identify   
files in a hierarchical directory system such as DOS. Because TAOS cannot   
permit the duplication of files that DOS allows, pathnames are actually   
handled rather differently. Where DOS relies on the PATH command and the   
user's own knowledge of the directory tree and its contents, TAOS must   
always be able automatically to locate objects. The pathname of a TAOS object   
IS the object name, rather than just a qualifying prefix indicating its   
current location. Therefore TAOS has built-in defaults related to the object   
type; tools are expected by default to be in the 'tools' filefolder. So if you   
request 'mystuff' TAOS will look for 'tools/mystuff' unless you explicitly   
specify another filefolder. The path 'tools/mystuff' is actually a message to   
the control object 'tools' requesting it to retrieve an object called   
'mystuff'.   
  
In large or multi-user systems there may be multiple server devices, and so   
multiple 'tools' folders. In this case TAOS adds the the mailbox ID of a   
'master server' to the path, roughly equivalent to a DOS drive; for example   
'/dicks_server:/tools/mystuff'. All future objects will be retrieved from this   
server until you explicitly change it.  
  
Filters in general are control objects that receive input from a mailbox, and a   
parameter string, and send output to another mailbox. The destination address   
for the output is contained in the input message as explained above. The   
parameter string  (which may be null) may tell the filter which of several   
actions to perform on its input. Filefolders are just one type of filter. In   
fact all TAOS applications constructed from TaoScript commands (see later) are   
just pipelines of filters running in parallel and passing data from one to the   
other. TAOS is a dataflow operating system, extending the Unix pipe concept to   
its logical conclusion.  
  
**PARALLEL PROCESSING**  
Tao Systems is seeking a patent on the algorithm used to distribute parallel   
programs over a network of processors, and so I am not allowed to describe it   
in detail. It's basically a smarter enhancement of the flood-fill type of   
algorithm, which can take into account the loading of each processor node as   
measured by the number of processes running on it. An application like the   
Mandelbrot which requires a large number of identical processes will get   
distributed in a manner which resembles water running down a mountain, where   
the flow seeks out the 'gullies' or lowest points. Tao System claims that this   
mechanism achieves a high degree of automatic load balancing.   
  
Very crudely, each node knows the current loading of all its nearest neighbors   
and any control object can spawn children onto the neighbour that is least   
busy, using a kernel call which invokes the mail system to transfer the   
executable VP code. Deadlock due to circular network paths is avoided by an   
incrementally created a routing table that remembers which paths have already   
been traversed. This is the part of the algorithm which is the subject of the   
patent, and it ought to work for any network topology at all. The routing   
table allows messages to find their destination mailboxes. The routing   
algorithm may, hardware permitting, generate multiple paths between two nodes   
which can be used as alternatives when mail gets blocked due to a shortage of   
buffer memory or a hardware failure.   
  
When necessary you can eschew the automatic mechanism and specify the   
particular node that an object is to run on. You can also invoke a partially   
automatic mechanism in which you explicitly send a number of objects to a node   
but let TAOS distribute them from there. For example you could specify that a   
1000 process Mandelbrot calculation should be run by sending 10 groups of 100   
objects to different nodes of the network but letting TAOS complete the   
distribution. The TAOS kernel contains a time-slice scheduler that allows many   
objects to run on the same processor. Box 1 lists the TAOS Kernel Calls   
(similar to DOS BIOS interrupts), and if you look at the entries under Control   
Object Management whose names begin with OPEN you will get some idea of how   
distribution is achieved.   
  
From a programmer's point of view remote interprocess communication is   
transparent under TAOS. You only need to know the mailbox address of a remote   
object, and then TAOS will route messages to it without you specifying the   
route. Tao Systems claims that near optimal routings are usually achieved.   
  
**TAOSCRIPT **  
You interact with TAOS via a job control language edit/interpreter called   
TaoScribe which processes a language called TaoScript. This is a dataflow   
language which describes the flow of data through pipelines of tools specified   
by their paths. For example :-  
  
/data2 < proc2 < proc1 < /data1  
  
would pass the data object 'data1' through the two tools 'proc1' and 'proc2'   
and then store the output into data object 'data2'. Tools 1 and 2 will be    
executed concurrently, possibly on different processors, and both will be   
started up before any data is transferred.   
  
/hd/data2 /hd/data3 > proc3   
  
would send both data streams into the same tool, while :-  
  
/dtp_stuff/chapter2 "parameter" > tformat  
  
sends the parameter string as well as the data into a 'tformat' tool. The only   
operators in TaoScript are /,< and > but these can be used in combination to   
create forks and joins as well as linear pipes. The resulting programs are in   
my opinion difficult to read though. There are no control constructs such as   
IF..THEN or DO..WHILE in TaoScript because all such control flow is governed   
inside the tools themselves, by interpreting parameter strings. So :-  
  
/data2 "TRUE, FALSE" > proc3   
  
might tell proc3 to send its output to one of the objects TRUE or FALSE   
according to the value of /data2. Groups of TaoScript commands can be saved   
as named objects and used as single commands, just like DOS batch files. The   
ordering of commands within a TaoScript program is very often irrelevant since   
the tools are all running in parallel and the dataflow governs the order of   
their execution.   
  
**THE GUI **  
There is also a simple Graphical User Interface built-into TAOS. Any control   
object can create a window object, which uses a buffer local to the object for   
maximum speed. These windows are sensitive to mouse events such as button   
clicks and dragging. Control objects do not need to worry about window   
movement or overlapping and refreshing which are handled transparently by the   
GUI supervisor, but they can receive mouse X,Y and time data from button   
clicks.   
  
Only one window, the Input Window, can receive user input at any one time and   
this window is indicated visually by a change of border color and by   
automatically being brought to the top of the pile. An object can send   
messages to its window to define 2D screen areas as Area Event triggers; the   
GUI monitors such areas and sends an Area Event back to the object if the   
mouse pointer enters the area. Areas can range from one pixel to the whole   
window. The GUI can also monitor areas by sending a continuous stream of X,Y   
data whenever the pointer is in the area. These simple facilities allow you to   
implement pop-up menus and dialog boxes.   
  
The GUI supports 8-bit color palettes, of which the first 8 colors are defined   
as EGA compatible defaults.  
  
**CONCLUSIONS **  
I have seen prototype versions of TAOS running on 5 or 6 Inmos Transputers in   
a PC host. The GUI is lightning fast and the demonstrations of multiple   
windowed Mandelbrot plots are very impressive indeed. However I have had no   
direct experience of programming under it, nor do I have complete   
documentation. Certain parts of TAOS, including the ALEX language translators,   
were not complete when this article went to press and some aspects of the   
design are still undergoing evolution. Tao Systems claims for the efficiency   
of parallel program distribution and message routing are very strong and   
will need to be independently tested by some parallel computer vendors.   
  
There is no doubt though that TAOS brings together many clever ideas in an   
elegant way. The philosophy it embodies is right on target for the next   
generation of operating systems, with its emphasis on persistent objects,   
dataflow and re-usable modular tools. The VP system for supporting multiple   
processor types is so ingenious that you wonder other operating system vendors   
have not tried it, until you reflect that it is only really viable for a   
starting-from-scratch OS; the effort of re-writing all PC, or Mac or Unix   
software in VP would clearly be prohibitive.   
  
Tao Systems is now busy demonstrating TAOS to a number of big names in parallel   
processing, including some from Japan, and I shall be following the progress of   
TAOS with great interest.   
  
Dick Pountain, Nov 1990  
  
\-------------------------------------------------------------------------------  
BOX 1.   
        
The TAOS Kernel Calls listed in functional groups.  
  
**Memory Management  
**  
ALLOCFAST       allocate memory block from fast memory pool  
ALLOCMIN        allocate memory block given minimum size required  
ALLOCMAX        allocate memory block given maximum size required   
FREEMEM         free memory block  
  
**Object Memory Management**  
  
COPYNODE        copy object  
COPYHEAD        copy object to head of linked list  
COPYTAIL        copy object to tail of linked list  
DUMPLIST        free memory of all nodes on a list  
FREELIST        UNALEX and free memory of all nodes on a list  
  
**Mailbox Management**  
  
SENDMAIL        Send mail message  
COPYMAIL        Copy mail message then send copy  
READMAIL        Read mailbox  
  
**Control Object Management**  
  
STARTCONTROL    Start a control object locally   
OPENCONTROL     Copy a control object and start locally   
OPENCHILD       Distribute and start a control object in network  
CLOSECONTROL    Close a local control object   
OPENARRAY       Distribute and open a number of control objects  
                 in the network  
OPENFARM        Distribute and open multiple copies of a control  
                 object in the network   
OPENDEVICE      Transport a control object to a specified network  
                 node and start  
OPENREMOTE      Transport a control object to a specified network  
                 node for distribution from that node, then start  
  
**Tool Object Management  
**  
VCALL           Virtual Call tool object  
FINDTOOL        Enquire if tool is available locally  
OPENTOOL        Request tool load  
FLUSHPETL       Flush un-referenced tools from Permanent and  
                 External Tool List  
  
**General Object Management  
**  
VADDR           Obtain address of an embedded object  
OBJPROC         Process an object in same thread  
LISTPROC        Process a linked list of objects in same thread  
LISTTEST        List enquiry for types of objects  
LISTINFO        Enquire general list information  
  
**Global Variable Management**  
  
DECLARE         Declare named 64 bit integer value to child control  
                 objects  
ENQUIRE         Obtain 64 bit value for declared variable name from  
                 family tree  
UNDECLARE       Locally remove last instance of a named variable  
                 declaration from declaration stack  
  
**Processor Type Node Identification**  
  
FINDTYPE        Enquire processor ID of processor node conforming  
                 to specified processor type and minimum memory  
                 requirement  
  
Local Timer Functions  
  
GETTIME         Obtain local processor timer count  
DELAY           Timed deschedule   
  
**Template Object Management**  
  
ALEX            Convert template to Process Ready  
UNALEX          Invalidate Process Ready status of object  
  
  
  

 | 

Comments

 | 

[Sign in][38]|[Report Abuse][39]|[Print Page][40]|Powered By [**Google Sites][41]**

[1]: http://www.dickpountain.co.uk/
[2]: http://www.dickpountain.co.uk/home
[3]: http://www.dickpountain.co.uk/home/blogs
[4]: http://www.dickpountain.co.uk/home/biog
[5]: http://www.dickpountain.co.uk/home/computing
[6]: http://www.dickpountain.co.uk/home/photo-gallery
[7]: http://www.dickpountain.co.uk/home/zen-brush-paintings
[8]: http://www.dickpountain.co.uk/home/cool-quotes
[9]: http://www.dickpountain.co.uk/home/materialism
[10]: http://www.dickpountain.co.uk/home/music
[11]: http://www.dickpountain.co.uk/home/materialism/sampling-reality-book
[12]: http://www.dickpountain.co.uk/home/computing/byte-articles
[13]: http://www.dickpountain.co.uk/home/computing/byte-articles/limits-of-computing
[14]: http://www.dickpountain.co.uk/home/computing/byte-articles/oberon-f
[15]: http://www.dickpountain.co.uk/home/computing/byte-articles/parallel-course-1994
[16]: http://www.dickpountain.co.uk/home/computing/byte-articles/the-oberon-language
[17]: http://www.dickpountain.co.uk/home/computing/byte-articles/the-oberon-system
[18]: http://www.dickpountain.co.uk/home/computing/pripar-machines
[19]: http://www.dickpountain.co.uk/home/computing/ruby-projects
[20]: http://www.dickpountain.co.uk/home/computing/ruby-projects/maths-libraries
[21]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects
[22]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/creatures-1
[23]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/equation-solver
[24]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/factoriser
[25]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/matcalc
[26]: http://www.dickpountain.co.uk/home/computing/ruby-projects/shoes-projects/wordsieve
[27]: http://www.dickpountain.co.uk/home/computing/scratch-projects
[28]: http://www.dickpountain.co.uk/home/computing/simpleware
[29]: http://www.dickpountain.co.uk/home/computing/simpleware/Download-page
[30]: http://www.dickpountain.co.uk/home/music/a-sad-canticle
[31]: http://www.dickpountain.co.uk/home/music/automusic
[32]: http://www.dickpountain.co.uk/home/music/bela-bartok
[33]: http://www.dickpountain.co.uk/home/music/just-plain-wrong
[34]: http://www.dickpountain.co.uk/home/music/just-plain-wrong-1
[35]: http://www.dickpountain.co.uk/home/music/spotify
[36]: http://www.dickpountain.co.uk/home/photo-gallery/flickr-top-200
[37]: http://www.dickpountain.co.uk/system/app/pages/sitemap/hierarchy
[38]: https://www.google.com/a/UniversalLogin?continue=http://sites.google.com/site/dickpountainspages/home/computing/byte-articles/the-taos-operating-system-1991&service=jotspot
[39]: http://sites.google.com/site/dickpountainspages/system/app/pages/reportAbuse
[40]: javascript:%3B
[41]: http://sites.google.com

