AGOCG logo
Graphics Multimedia VR Visualization Contents
Training Reports Workshops Briefings Index
This report is also available as an Acrobat file.

SIMA Report on Multimedia Toolbook


down Software Requirements
down User Hardware Requirements
down Developer Hardware Requirements
down Network Support
down Portability

This section presents the minimum and recommended system requirements given by Asymetrix in their product documentation and then comments on how realistic they are for various application types and modes of use. It also discusses the issues involved in using ToolBook 3.0 across a local area network and across the Internet. Finally, the prospects for running ToolBook 3.0 on a non-PC Windows platform is examined. Throughout, attention is drawn to known incompatibilities and problems areas.

Software Requirements

ToolBook was developed as a Windows PC optimised and Intel specific program. Unsurprisingly the software requirements listed by Asymetrix are:

  • Microsoft MS-DOS 3.1 or higher
  • Microsoft Windows 3.1 or higher
Some time after ToolBook 3.0 was released Microsoft released Windows 95. ToolBook 3.0 works well under Windows 95 and the program windows and menus take on the Windows 95 look and feel. However, there is no built in support for the Windows 95 interface objects like push buttons, check boxes and radio buttons although these can (relatively) easily be mimicked by using ToolBook's ability to customise the look and feel of interface objects.

Although not stated on the packaging, the software requirement for running under Windows 95 is simply:

  • Microsoft Windows 95 or higher

Regrettably, Asymetrix omitted to specify one extra software requirement which would have made their own life and that of developers using the ToolBook family of products a lot easier. The missing requirement, in the opinion of the authors of this report, is:

  • Windows compatible display driver (small font - not large font)
As it is, this is not a stated requirement and few developers are aware of the minefield this issue of supported display drivers is. The heart of the problem lies in the way ToolBook maps its own internal screen co-ordinates (e.g. the position of a button or graphic in the ToolBook window) on to the physical pixel co-ordinates of the underlying graphics hardware. For normal, so called "small font", display drivers this mapping is 15 ToolBook screen units to 1 real pixel on screen. Unfortunately, end-users are able to configure their Windows system to use a "large font" display driver so that on high resolution screens (e.g. 800x600 or 1024x768) the text, menus and window borders are bigger and easier to read on low-cost monitors (i.e. sub 17"). Why is this a problem? Well, in doing this, the mapping of ToolBook co-ordinates to screen co-ordinates ceases to be 15:1 and becomes, say, 18:1 thereby throwing out the layout of the ToolBook screen. In some cases this may not be a problem, but because the ratios are not multiples of one another, the amount by which the scaling occurs will be irregular - so that a regular grid drawn at 15:1 will be unevenly spaced at 18:1. The reverse is also true - a regular grid drawn at 18:1 will appear irregular at 15:1.

The situation worsens if fonts and word wrap are taken into consideration, where text comfortably filling a box in a small font driver will often overflow the space in a large font driver. Asymetrix's policy on this is, rather unhelpfully, that developers should leave enough space in any text field for this not to matter. However, this would severely limit the type of screens which could be designed using ToolBook and is, for most applications, a ridiculous suggestion.

If developers were aware of this problem from the outset, then there is a simple work around which is to add this missing software requirement to the software requirements of their own product. This does not mean that developers can only develop for small font drivers; rather, that developers must develop using the same driver type as that used by the intended end-users of their product. Typically, 640x480 drivers are all small font so that screen resolution is not a problem. For higher resolutions, small font drivers are the most common, in the authors' experience, in UK higher education student labs. However, many institutions do use large font drivers but can sometimes be persuaded to switch to small font ones. It is therefore important that prospective ToolBook 3.0 developers research their prospective target user base's display driver usage before commencing any development.

Where the users' precise display driver configuration is not known because the software is for general publication rather than for a specific institution, it is possible to check the screen mapping ratio during start up of the application and to advise the user accordingly (see ToolBook's on-line help for sysPageUnitsPerPixel and check that this is, say, "15,15" if your software requires a small font driver).

In summary, this arguably missing software requirement is a problem which is not unique to ToolBook but is serious if the ToolBook developer fails to take this into consideration at the outset of a project. (Incidentally, this problem has not been resolved in ToolBook 4.0 either).

User Hardware Requirements

Asymetrix do not specify separate hardware requirements for end-users and developers; a single minimum machine specification is intended to cover both. For non-Multimedia ToolBook 3.0, the minimum specification stated by Asymetrix is as follows.

  • 20MHz 386 SX processor or higher
  • 2.5MB of free hard disk space for ToolBook 3 runtimes (plus space for courseware)
  • At least 4MB RAM (8MB recommended in User Manual, 6MB recommended on packaging)
  • 1.44MB (3.5") floppy disk drive
  • Mouse or pointing device
  • Windows compatible graphics card (VGA or higher)
  • Sound card (optional)
  • CD (optional)

For Multimedia ToolBook 3.0, the specification on the box is slightly higher in the areas of CPU speed, RAM and, of course, adds multimedia hardware such as a sound card and CD-ROM drive. Again, a single specification is given to cover both end-user and developer.

  • 20MHz 386 or higher
  • 8MB hard disk space (minimum to run - actually needs more for developer's installation)
  • Sound card (recommended)
  • CD-ROM drive

How do these specifications measure up in practice? Taking the non-multimedia specification first, it is claimed that ToolBook 3.0 works on a 20MHz 386SX with only 4MB RAM and, technically speaking, it does. However, depending upon the rest of the machine configuration, it can take several minutes to simply load and initialise ToolBook on a 386SX even before ToolBook starts loading your application into itself. Then, once loaded, simple operations like selecting an item off a pull down menu can take an unusable length of time - particularly if it is the first time you have performed the operation. In fact, very few types of authoring operation are practical on this speed of machine and it is difficult to see how one could realistically develop interactive graphical software under such an unresponsive environment. Only a limited variety of applications can realistically be developed for this hardware specification. Applications requiring high speed animation or anything other than tiny bitmap graphics require a lot of work on the part of the developer to obtain anything approaching a usable execution speed. In particular, the time taken to navigate from screen to screen (or page to page in ToolBook terminology) can easily exceed a minute if the pages contain large bitmaps and if some initialisation has to take place on entering each page.

Moving to the multimedia minimum specification claimed by Asymetrix, this sets the entry point at 386DX with 8MB of RAM. A 386DX is faster than a 386SX but it is the addition of an extra 4MB RAM that makes a noticeable difference in the performance of the package. Under this specification, the pull down menus operate at a usable speed and it would be possible, but not enjoyable, to develop ToolBook applications on this specification of hardware. As with the non-multimedia specification, this specification is still too low to practically support all the types of graphical and interactive software one might wish to develop in ToolBook. It is, at least, plausible that a subset of application types, which do not make great demands in the areas of graphics and animation, could be developed on this level of hardware. However, if software video clips are used then the load times and frame rates are not, in the opinion of the authors, good enough for serious use.

Clearly, the minimum hardware specifications quoted by Asymetrix are at the very lowest extreme of machines capable of running ToolBook and lie some considerable way off a recommended end-user platform and a long way off a recommended developer platform. In fact, Microsoft Windows itself is not very responsive or usable on such low specification machines and so it comes as no great surprise that ToolBook under this environment is also slow and unresponsive. However, it is not uncommon for developers to develop their application on a high end Pentium PC and just assume that their software will be equally usable on machines down at the bottom of the supported hardware list. Such assumptions can render an application unusable by the intended end-user base and the importance of testing software on the lowest specification target hardware can not be over stressed.

Although there is still a large installed base of 386 machines running Windows, these machines are at, or have already come to the end of their useful life and are being replaced with 486 or Pentium based systems. Indeed, at the time of writing this report it is difficult to buy a PC below a 50MHz 486 and a 75MHz Pentium is becoming the entry level machine even for home users.

However, in a cost conscious world, it is still important to know the minimal practical hardware specification. So, if Asymetrix's stated minimum hardware specification is too low, then what is a practical minimal specification? The answer to this question is different for end-users and developers. The authors' recommended minimum specification for developer hardware is given in the next section; however, for end users it is as follows (for both ToolBook 3.0 and Multimedia ToolBook 3.0 alike).

  • 33MHz 486 DX processor or higher
  • 4MB of free hard disk space for ToolBook 3 runtimes (plus space for courseware)
  • 8MB RAM
  • 1.44MB (3.5") floppy disk drive
  • Mouse or pointing device
  • Windows compatible graphics card (Super VGA or higher)
  • Sound card (optional)
  • CD (optional)

If software video is required (e.g. Video for Windows), then a higher CPU clock speed is highly recommended. However, the single most effective add-on to this specification would, for graphically dominated applications, be the addition of a graphics accelerator which brings a significant improvement in screen redraw rates and animation speed. After this, the next best area to optimise would be the speed of the hard disk or CD ROM drive as appropriate.

Developer Hardware Requirements

Asymetrix do not give a separate list of hardware requirements for developers. However, to develop efficiently and effectively in ToolBook requires a slightly higher specification machine than is required by end-users of applications written in ToolBook. The authors' suggested minimum developer hardware requirement is listed below.

  • 66MHz 486 processor or higher
  • 24MB of free hard disk space (plus 9MB extra if WIN31WH.HLP Windows API help is loaded)
  • 8MB RAM or more
  • 1.44MB (3.5") floppy disk drive
  • Mouse or pointing device
  • Windows compatible Super VGA graphics card (at least 800x600 with the required number of colours)
  • Sound card (optional)
  • CD (optional for ToolBook, essential for Multimedia ToolBook)

Of these requirements, the increased screen resolution is one of the most important for the simple practical reason that ToolBook litters the screen with a variety of toolbars and floating palettes (tool button windows) and unless the developer has a larger screen area than the target screen area, a large proportion of the ToolBook window is obscured. If developing for a 640x480 resolution screen, developing with ToolBook in a 640x480 window centred in a 800x600 resolution screen leaves plenty of space around the window to place the potential multitude of tool windows.

Network Support

There is no difference between ToolBook 3.0 and Multimedia ToolBook 3.0 in terms of network support.

In practice, ToolBook works well across a network provided machines have a minimum of 8MB RAM. Also, configuring base memory (memory which lies below 640K) to have as much free space as possible can make quite an improvement in overall performance of both Windows and ToolBook. Sadly, many current network drivers occupy a great deal of this bottleneck space.

Multiple users can share ToolBook applications on a network if the ToolBook utility TB30NET.EXE is in each user's path. TB30NET guards against two or more users changing a book at the same time. This utility comes with ToolBook and is installed in the same directory as ToolBook itself and so it will usually be in the path by default.

ToolBook supports two modes of use on any networked system.

Mode of use File properties No. simultaneous users
read/write rw single
read-only r multiple

If a ToolBook file (aka book) is read-only, then any number of users can open and use that book simultaneously. ToolBook behaves as if each user were using their own private, separate installation of that book even though there is only one physical copy on the file server.

By contrast, if a ToolBook book is not set to read-only then only one user will be able to open the book. Until this user has closed the book, subsequent users attempting to open the same book will get a message saying that the book can not be opened because it is already in use.

The obvious design restriction which results from the inability to give multiple users simultaneous write access to the same book (via some sort of record/page locking) is that some external means of recording persistent information must be used in a networking application. For example, a computer based assessment package implemented in ToolBook must find some way of recording the users' scores in tests other than by simply saving the book. Common solutions to this sort of problem include writing to an ANSI text file, a Windows .INI file or a database such as Paradoxš or dBaseš.

To be fair to Asymetrix, this restriction is an reasonable trade-off for impressive ease of data access within ToolBook and for the ability to perform a broad range of non-persistent write operations which may differ from instance to instance without any central data locking bottleneck.

In terms of performance, ToolBook itself takes somewhat longer to load across a network than from a local hard drive. The precise figure is highly dependant on the network infrastructure and the current network traffic loading but is typically in the range of 30-90 seconds in student teaching labs. The total load time will also include the time to load the ToolBook book (i.e. the application). It is simply not possible to quote a typical time range for this as it depends upon the degree of initialisation which takes place on entering the application and upon the volume of graphics, video and sound on the first page in the book. A minimum figure would be around 15 seconds for a simple, non-graphical first page and rising to around 90 seconds for a graphical first page with a small video clip. However, the only real way to establish loading time across a network is to try out a representative prototype under realistic loading of the network; near local drive performance can be obtained in a student lab with only one machine accessing the network, but this gives absolutely no indication of performance under load.

Once loaded, performance across the network as the user navigates around a ToolBook application is dominated by the amount of graphics, video and sound data needed for each page visited. ToolBook automatically caches graphics so, provided the graphics are not so large and numerous that the cache is flushed for every page, there will be a marked improvement on subsequent pages re-using the same graphics.

Asymetrix recommend that, for improved performance, ToolBook be installed onto the local hard drive (assuming there is one) and that just the applications (books) be stored on the network. Unfortunately, this is frequently at odds with institutional computer support policies which insist on all executables residing on the server. One work around for this is to configure the machines on the network to, on booting, check their file sizes and dates against those in the same directory on the server and to replace any local files which differ with the master versions on the server. This allows local copies of the ToolBook executables to be maintained while providing some protection against tampering by users.

Asymetrix make no recommendations for the situation where the workstations on the network are entirely diskless; no local hard drive exists on which to install the ToolBook executables locally. In such circumstances, the best course of action is to opt for extra RAM on the machines so that Windows can run more efficiently and, possibly, so that a RAM drive can be established to hold the executables. Applications intended to be run on diskless workstations should be designed with this in mind and options to switch off non-essential graphics can be included to dramatically improve their network performance.


ToolBook 3.0 is a PC only product. Asymetrix have repeatedly stated that they monitor the Mac and UNIX markets but that these markets are not large enough to justify the sizeable investment required to develop versions for these platforms. This situation has remained unchanged in the upgrade to ToolBook 4.0 and seems unlikely to change in the near future (although the new Java product may be a step along the road to platform portability).

The Internet ToolBook discussion list from time to time discusses running ToolBook 3.0 under emulators on, say the PowerMacš or SoftPCš. However, performance is a major problem and there are numerous little incompatibilities which render this approach to portability useless or, at best, extremely restrictive.

[Previous Page] Copyright © 1996. Last Updated: 12/06/96 [Next Page]

Graphics     Multimedia      Virtual Environments      Visualisation      Contents