![[Last]](../../bar/last.gif){kind=small}
![[Up]](../../bar/parent.gif){kind=small}
![[Next]](../../bar/next.gif){kind=small}
![[RSS links]](../../images/rss16.png){kind=small}
RISC OS 3.1 had a built in !Configure application, in ROM, which would configure the built in applications that would start on boot up. RISC OS 2, didn't have a ResourceFS, so had no desktop tool. RISC OS 3.5 moved the configuration tool on to disc, and RISC OS 3.6 added network support. But up till then it wasn't all that different.
One of the articles in Acorn User, back in something like '94, had an article talking about possible future developments for RISC OS. One thing they talked about was how the configuration would get wider to include other things, with a little mock-up of a configuration tool. It gave me some ideas.
There was a freeware patch for !Configure which added a few extra configuration options that weren't previously present. The problem of adding new features to the configuration as requirements changed gave me some other ideas.
Config+
!Config+
So I wrote !Config+. The goal was to be modular. Rather than having a fixed set of configuration components, they could be added to. Rather than each component implementing its configuration from scratch, it would share the functions of the main application. By the same token, many applications had similar configuration requirements - so why not let the configuration tool provide them. Rather than defining things in fixed terms, in a template file, it would define them in terms of grouped configuration items.
The main !Config+ application provides:- The core window.
- The module loading code.
- The library routines for constructing new configuration windows.
- Common configuration setting and reading code.
Doesn't look like much, 'cos the library
implementation is main bit.
It's all implemented in BASIC, and the modules that can be loaded just
use LIBRARY when the application starts. The help
makes reference to using OVERLAYs (which would be significantly more
efficient) but this requires the use of a fixed size of array which
would prevent it being dynamically added to if more modules were
required (as might happen if an application requested that it handle
the configuration).
It's very early code, so it's really hard to read, I've just found out! It also includes such gems as:
inc=((spr$="down,pdown")*2+1)*SGN(but-2)
which is kinda fun (button handler for both 'up' and 'down' icons which calculates the increment based on the button type and then inverts the increment if you press Adjust on it). Don't do this, kids. It's not big and it's not clever. Well, it is clever, but that doesn't mean you should do it.
As for documentation, well, it doesn't look like there is anything that tells you how to use it. Very poor - and not surprising that it wasn't taken up by anyone (at least not as far as I remember).
What did exist, though, were configuration modules of all of the
'Standard' configuration icons. Each module could provide multiple
configuration icons and windows - and each of them could be given
independent version numbers.
When the windows were created, they were done
dynamically, and the main application would determine where to put
the icons based on how they were specified and whether there was any
alignment required. From the 'Drives' configuration module:
730 PROCstartblock("IDE hard disc drives")
740 PROCstartrow
750 drv_ide1=FNicon_sprite("Harddisc")
760 drv_ide2=FNicon_sprite("Harddisc")
770 drv_ide3=FNicon_sprite("Harddisc")
780 drv_ide4=FNicon_sprite("Harddisc")
790 PROCloneupdownbuttons("IDE",1)
800 dummy=FNicon_text("Spindown delay",-.58)
810 drv_spindown=FNicon_data(7,7,"Spindown",.58)
820 PROCloneupdownbuttons("Spindown",1)
830 PROCendrow
840 PROCendblock
which would place 4 Harddisc sprites in a row, followed by some
up/down buttons on their right side. The next row would have a
label 'Spindown delay', right aligned to 58% across the window,
followed by a data icon (inset value) called 'Spindown', and then
another pair of up/down buttons.
The 'mouseclick' function would be called when the buttons were
clicked, passing the name that had been associated with it - in
the above example, 'IDE' and 'Spindown'. The 'IDE' handler would
grey out discs, and the 'Spindown' handler would apply the
increment or decrement as appropriate. When the window was confirmed
the module could read back its values and update the configuration
appropriately.
All the usual types of gadgets were provided for - options, radio buttons, sliders and input fields. Interactive help was supported, too, with named icons getting their help from a Messages file.
Eek, apparently there's a 'FreeNet' configuration module as well,
which lets you configure many of the variables in the FreeNet
configuration file - which looks likes a collection of sysctl
named option settings. I have no memory of writing it, but I clearly
did.
A few other things used it - I remember that !IRServer would call out to !Config+ to do its configuration - what's the point in writing more configuration windows if you've already got an application that does it for you ?
If there were failings with it - aside from the atrocious lack of any documentation - it was that it was a little inflexible in its handling of modules. As memory ran out it would not cope well. Similarly, its implementation in BASIC with one application and lots of linked modules limited its usefulness.
Apparently I
uploaded
it to Arcade, long long ago. I just boggle at the number of
cool little utilities and patches that are there. Many people more
talented than I wrote more impressive things around the time I was
still tinkering in BASIC with configuration things 
. It's also
a strong indication of how the user community diminished in the
subsequent years.
Configure
!Configure
The RISC OS 4 configuration system had a little bit of a revamp. Acorn had decided to modularise the configuration system into an application per area of configuration. This meant that there were more applications to maintain, but each one was simpler. They also went down the Toolbox route, committing to making all the configuration applications easier to write and making Toolbox more prominent (although you cannot tell from the interface, which is part of its purpose).
The boot sequence on RISC OS 4 was slightly different to that of the universal boot sequence, but not in a significant way. The universal boot sequence had never been distributed with machines previously, so there were a few configuration that needed updating.
RISC OS 4
The initial RISC OS 4 distribution had the standard configuration tools which had gone before as applications, with the addition of new Boot and Font sections. The Font plug-in offered tools for installing new fonts, configuring the desktop font, updating settings and rescanning the existing fonts. The Boot plug-in could control the applications which were run on start up, booted, or added to the Apps shortcuts. This meant that modifying the boot sequence manually was a little more controlled and easier to manage for the user - less adding things to text files (and having to know which text files to add to), and more obvious drag-and-drop.
Multiple sections
When it came to looking at configuration again for Select, I'd had a little experience of working with the plug-ins, writing them from scratch and problems with those that existed. One of the 'problems' which I'd encountered was that writing the sub-configuration windows meant duplicating a lot of code. Both the Boot and Font tools were very similar to the top level configuration plug-in window.
!CPIShell
I had wanted to separate out some of the other windows into multiple
sections in the past but it had been harder because there wasn't a
simple means to reproduce a hierarchy other than by duplicating the
applications. To help with this, I reworked the main configuration
tool, which handled the plug-ins, etc, so that it could itself be
used as a plug-in, and could work with arbitrary locations in the
configuration hierarchy. This became the !CPIShell -
Configure Plug In Shell - tool which is used to provide the windows
for all the sub-plug-ins.
As a result, most of the plug-ins became more standardised, providing 'Cancel'/'Set' options which would control their sub-windows, and able to be invoked in the same way. The Font plug-in isn't like that, because actually it's a single plug-in that performs a few tasks. Otherwise, the other tools are mostly !CPIShell groups that call down to sub-configuration tools. The configuration plug-ins were also given the opportunity, in their definitions, to declare that they should be greyed out if they were not available. This wasn't used often; it helped for some times when we wanted to offer configuration but make it clear that it wasn't appropriate for the current system.
Configuration groupings, at the top level
Many of the common areas were grouped
so that their configuration wouldn't clutter the main window:
- Boot - merging, boot and run on start up, and adding shortcuts.
- Discs - the different filing system configurations; mount points for network storage should have gone here as well.
- Display - monitor and resolution, and the screensaver; we might have added acceleration options and maybe gamma correction settings here if we'd got to it.
- Input - keyboard and mouse; touchscreen would have gone here along with joystick if I'd gotten around to writing them.
- Network - a collection of the various protocols and device configuration lived here; if I'd got around to writing a name service switcher, it would have been configured here.
- Sound - basic hardware configuration and frequency tracking; this would have also held the system event sound configurations tool as well, but this was never finalised.
- Windows - icons, furniture and other configuration here; if we'd split off skin installation that could have lived here, although it was always tempting to reuse the Themes section that someone else had produced quite well.
Some parts of the configuration already had their own sub-components, such as the screen savers. They had been pretty well defined by Acorn. For RISC OS 4, I ported a simple 'Galaxy' screen saver, just to see how hard it was - it wasn't all that complicated. I also created managers for !DarkHorse and !HangFire screensavers, so that their plug-ins could be used as core screen savers. I'm not sure they were ever released. Maybe on the developer CD. I had also meant to do an !OutToLunch manager as well, so that its savers could be handled in the same way, but I never got around to it. I have a feeling that they were a little more complicated than the other ones.
Icon style
One of the Select releases revamped the icons for all the configuration tools - I believe it was Richard Hallas who did those. I wasn't convinced that some of them were right, but they were very consistent and all followed the right patterns so I bowed to his judgement on them (as I had with a few other things that people had contributed over time). Looking back now, the icons that I feel look worst in Configure are the ones that either I did or were hacked together as placeholders that just stuck. The redesign wasn't huge in some places, but the consistency made things look a little better all around.
I seem to remember that I requested that we retain the jigsaw motif for all the plug-ins. In retrospect this was a bad idea - exposing the fact that the components were plug-ins when the rest of the interface tried to be a single application was silly. Richard had suggested the we do things differently, I believe, and I kinda wish that we had.
Example of the groupings through !CPIShell.
Plug-ins were added over time, as they were needed by other components.
The scroll-wheel support in one version meant that we needed a way to
configure it to work how users might expect. This sat nicely alongside
the keyboard and mouse configuration windows.
Internet configuration
The network configuration was the same as before and essentially it was a single window (which, admittedly could be dynamically resized) which just became a Filer-like view on to the configuration tools. Acorn had defined a good specification of how to add new configuration tools and a messaging system so that tools could cancel or confirm their configuration automatically when the application as a whole was shut down. This made it feel more integrated - that each component was actually just part of a single application. I expect a little of the experience from !ResEd helped here.
As the Internet configuration was split up from being a single
application into lots of little plug-ins, the configuration files that
were generated in Choices were also split up so that
they could be manipulated independently. Otherwise it might have been
necessary to pick apart the files for the sections we wanted so that
we replaced only the data we were changing - which is more error prone
as the contents change in the future. That really did make some things
a bit easier once the system was running, but made the Installer's
life more complex.
Rather than the Installer picking apart the configuration files, it just ignored them, and we stated that the configuration would need to be recreated. It was a little bit of a cop-out, but the configuration wasn't generally that complex for people to repopulate, and you usually knew how your network was set up. Of course, in many cases the reconfiguration was actually something different to what the user had before - you could now just select 'Dynamic' configuration, and the DHCP module would do the job.
The network configuration was also updated to be able to take immediate effect. Earlier versions - back to RISC OS 4 - would need to be rebooted in order to take effect. Really that's not necessary most of the time, so I updated the interface configuration to instead perform the reconfiguration itself. It still offered the option to reboot in case you were paranoid, but could handle the configuration itself.
Actually, prior to RISC OS 4, the system wouldn't just need to be rebooted - it would do so once you confirmed the configuration, without shutting anything down. For RISC OS 4 a new option to shutdown and reboot the machine was added - I recall that the option was labelled with a comment something like "Specially for Mr Inet-'I'm-Too-Important-To-Save-Your-Data'-Setup".
Reconfiguring the network without a reboot shouldn't be a big deal really,
as all the work can be done by most clients, but it was somewhat surprising
(surprising ? should that be embarrassing ?) that it took until late 2002 for
the feature to be added. It might not be something you do often, but lets
not make it a source of annoyance when you do have to change things 
.
Some of the components were later enhanced to add facilities that were available elsewhere. The Resolver configuration window was one such case, although actually its functionality was developed before the equivalent feature was added to the Resolver module itself. It was necessary to enter the IP addresses of the DNS servers that the module would use. This was, usually, relatively easy as you knew the local network configuration. However, I wanted to try to make it as easy as possible to set up for first time users - especially those who might not actually know what a suitable setting was for the resolver address.
I created a simple library - FindResolver - which would
try to locate any DNS servers on the local networks. The algorithm
was pretty simple, but managed to locate most of the DNS servers that
I tested - 2 Windows servers, 2 RISC OS servers (Resolver and my own
!DNServer), and 2 Linux servers. It didn't work with BIND 8.3.3, but
did work with BIND 9 in particular. The library could also use the
Multicast DNS resolver if it was present, to locate any locally
announced servers.
Anyhow, the library was used to populate a menu which appeared during the configuration of the Resolver. This should have made it easier to configure the network manually, however I think most users would have been using DHCP by then so the benefit was marginal. The library itself was reused in the Resolver code as part of the auto configuration which the module could perform when it found that no resolvers were responding.
Wimp configuration
The Windows configuration tool configured many of the settings which affected the way in which the Wimp worked, most of which had been previously available but were behind manual *Commands, or had been unable to be configured except by changing the NVRAM settings directly. New settings had also appeared as well. The selection handling in the desktop was controlled from within the Icons configuration, as was the special highlighting of icons. Tool ordering was configured in another plug-in, as well. But the remainder of the configuration was all grouped into a single configuration tool. Because there were a lot of options, I employed the !Browse style of configuration window which was the way that we were recommending people present such options.
The !Browse style, playing the option sections on the right, with the configuration buttons below and the main window taking up the bulk of the left of the window, was both intuitive and saved space. The use of tabs, as used by other systems, was heavily disliked by users when we got any feedback about them, so this form of selection was the best compromise when multiple related sets of options needed to be presented. It was similar in some respects to the configuration used by Impression Style and Publisher.
Filer configuration
The Filer's configuration was similar, and actually the code that I had written to manage the configuration window buttons was just lifted into the Filer configuration tool , making it slightly more generic as it went. The Filer configuration wasn't as complex and really only had a few sections. However, as I had also added the ability to thumbnail images, the configuration for this could also be controlled from the tool.
Generic options window
At the very end, I began writing an OptionsWindow toolbox object. This mirrored the !Browse style configuration that had been seen to be the most useful way of presenting sections of options without using tabs (which were generally disliked by RISC OS applications). The object was intended to replace all the hard-coded uses of this type of window, making it significantly easier to include such configurations in Configure and other applications. I'm pretty sure I updated the Window configuration to use it, as a test. Whilst it worked, I held off committing to it for another release - which never happened.
Problems?
There were still longstanding issues with some of the configuration tools in that they relied on using *Unplug to remove the modules they were disabling. As the ROM order changed with releases (and towards the end became highly dynamic) this meant that configuring modules to be unplugged was a risky business - you might unplug a module that was important to a different version of the OS. In some cases these were updated so that the modules started but were configured safely, or killed in the boot sequence. In others the commands remained and the system had to take its chances when you installed a new version. Usually I checked the common cases, but really those configurations should have been removed. Maybe they have been by now.
I'm not sure I really agreed with the way that closing the top configuration application would close all the lower windows. It didn't fit with how Filer worked, so I'm not sure that the configuration application should work that way. However it did and I ensured that when you closed the top window every layer down would be queried in turn to make sure that everything was shut down properly, and the necessary messages presented to the user.
Boot sequence
!Boot
Describing the sequence
One of the areas that was identified as needing work when we started at RISCOS Ltd was the boot sequence. I had my doubts that it was structured badly, as the universal boot sequence improved things significantly over the older systems. However, there were areas that weren't very easy to work with which could be improved. A lot of the issues with the boot sequence came from the sequence being unclear. There were things in the sequence that were there for legacy reasons and which might need to be retained if the system were to keep working on those systems. On the other hand, if the boot sequence was not expected to run on those systems, there was little reason to retain them.
Some of the legacy bits were removed - I stripped out RISC OS 3.1 specific support where it complicated the operation of the boot sequence, for example. A lot was retained, however, such as the support for distinct Econet scrap directories when booting over NetFS. That particular case was partly due to a fondness for Econet, partly knowing that there were people still using it and partly the extra work involved in stripping it was too great.
Aside from actual changes for RISC OS 4, Paul wanted a breakdown of the boot sequence's operation for some chart or other. Again, I'm not convinced that this was as useful, but as part of working out the sequence (and the tidy up) I set about commenting all the scripts.
Prior to this work, the scripts had a few comments to indicate what the script was used for, but these were mostly restricted to the user editable scripts. The 'internal' scripts that did most of the work were mostly just lists of commands to perform, with no indication of what they did or why they were there.
Acorn had begun to tidy up some of the scripts that were being used for RISC OS 3.8, which might have allowed configuration tools and the like to identify and change those sections. In many cases, there wasn't as much need to change those things so there weren't any tools created for them. The main boot configuration tools, though were very useful in keeping people away from needing to edit files manually.
In some cases, the documentation on the boot sequence wasn't as useful as it might be, but at least parts of the sequence had some comments now. I'm a strong believer in leaving comments to state what you're trying to do, and (if necessary) why you're doing it.
When you're working with people it is important that the things that you know are documented, so that it's not always necessary to go back to the original author. When you're working on your own there's a tendency to be more lazy and 'know' what you're doing, and see no need to explain to yourself. I push the other way, because I know that whatever you might think about things, someone else will inevitably see the code (even if that 'someone else' is you in 3 months time). It is more professional to have code that justifies itself, or at least shows a reason for the work that is being done.
It also provides a self review, which is important when you're working on your own. If you can describe what you're doing concisely without asking yourself any questions then things can't be that bad. In RISC OS there are a lot of things that fail this, either because of special cases, or because there is background information that you need to know in order to make even a simple operation work.
Anyhow, the comments were useful (in my opinion) and they made it easier during the Select development to identify problems and to extend the system in the right ways.
Changing Choices:
When working on Select, I wanted to improve the behaviour of the system when booting with different configurations. One of the areas that I had changed was the boot sequence's handling of choices. Instead of just a single area, there were 3 areas - the hardware configuration, the common (default) configuration, and the user configuration.
The idea was that...
- ... the hardware configuration would contain things like 'how to set up your Ethernet card', 'monitor type configuration', and any special configuration to set up the system that was running.
- ... the default configuration would contain things that were set up for all users and all hardware on the system, such as 'every user runs a given application', or all applications start out with a given template configuration.
- ... the user configuration would be things that the user set up which would change between users, like the screen mode to use (arguably that could live in the hardware configuration, but it was user specific at the time), or the Pinboard and Filer configuration, etc.
Part of the idea was that network booting (or moving the disc to another machine) would be detected by the hardware being different, and the system could be configured differently based on that. Similarly, removing a Podule such as ViewFinder would be detected and the hardware profile switched to one that didn't have that configuration. I'm pretty certain that the idea was reasonable for the network booting case, but flawed for the hardware changing case.
User changes
The boot configuration tools were updated so that the user configuration was restricted to the current user, or could control the default configuration that was common to all users. This was more successful and would be more useful if you were sharing a system between users. Partly I drew on the work that I'd done previously for the !AreaFiler on the family machine, but without quite the level of customisation.
Back in the past, before I started at RISCOS Ltd, I'd tried to explain better
how the Choices system should be used.
The document
had been updated through the years, but still essentially said that same
thing - that you read from Choices:path and you write to
<Choices$Write>.path. That could be varied slightly
if you were operating on configuration in the default or hardware
configurations in Select, but the principle was the same.
Despite this, there were still some applications that wrote to
Choices:path directly. This caused some problems as the
Choices$Path variable now contained multiple components. To make
sure that such applications continued to work, FileSwitch was updated to
automatically use variable$Write for any attempts to
write to a path which contained multiple components.
Chris Johns wrote the user selection tool which could be enabled to allow users to log in when the machine booted. We had a few problems with this as it was originally based on UnixLib and this caused problems for some people, and the code was eventually updated to use the standard system libraries.
The user system also allowed each user to have a 'home' directory which could be configured. The !HomeFiler would appear on the IconBar and gave a shortcut to the configured directory. This was essentially the same as the way that the !AreaFiler worked in the user system I had set up on the family machine.
I don't know if many people used the facility - there had been repeated requests for user separation, but that doesn't equate to people actually using it once it is set up. The user separation was purely functional - if one user wished to interfere with files owned by another there would be nothing preventing that. Given the file system and protection model of RISC OS it wasn't possible to provide much more without redesigning quite a bit of the way that things worked.
Hardware profiles
The HWScan tool would detect hardware changes and prompt the user for how to deal with the differences - whether it was the same configuration, or a clone of another configuration or whether it just didn't matter. It wasn't friendly and, although I included help in the tool itself, it did not lend itself to being used by users. The tool was left disabled initially, and whilst it was described in the release notes, it was never really pushed.
I think it was a pretty bad as a feature, and I'm glad I never made it a default option. The idea made sense in some respects, but the feature was of such limited usefulness that it shouldn't have made it to a release, not to mention the fact that the execution was poor. Having the hardware configuration separated was a good idea, so that it didn't have to be reconfigured on a per user basis, but the selection mechanism wasn't so helpful. Ah well, mistakes happen.
Library changes
The Library also underwent a small change to its structure to try to give more structure to it and to provide more information to users of the commands. There were a number of tools being supplied with Select which could be grouped together, and there were lots of additional tools which could be obtained from other sources. Not to mention the tools supplied for development as part of the GCC and Norcroft suites (and the others). The number of tools meant that managing the Library directory was becoming a more difficult task (assuming you wanted to). Splitting the library up into functional areas would make it easier to manage.
The Run$Path had always been intended to be able to be used
for multiple library directories, and this was more important as the old
style of 'library per filesystem' was unworkable since about RISC OS 2.
I already had a tool which would construct a new Run$Path
based on a directory, as I'd used it as part of my earlier !Boot sequence
on my own systems. This SetPaths tool was updated to
be more reliable and a little better written, and the library was split
up.
A small !Help file described the way in which the Library was used, so that it would be clear to anyone who looked at the changes themselves. It's possible that this wasn't a problem that anyone else viewed as important, but I believe that it made things tidier.
Back when I was writing little tools and patches, around University time, I
wanted to make it easier to find out how to use the tools. Normally when you
used *Help you would get all the details from the
currently resident module commands. That's fine if you're using those
commands, but some commands (such as those I had written, or downloaded)
live in the library, and to get help you have to either know that they
support some '-h' or '-help' option, or dig out
their documentation.
It was also possible that the 'command' you were trying to invoke was actually an alias for something else, and for that you'd need to use *Show Alias$command to see what it was doing. A little module that I wrote to help with this was ExtraHelp.
This module listened for Service_Help and would respond
by locating the help for the library command supplied and printing it out.
The help would be in the 'Help' directory on the path. It would
merely search for the 'Run:Help.command' and display the
file, pretty printed, along with a header just like the regular
*Help would.
It also supported a '-x' option, which would display 'extended'
information - anything bracketed by ctrl-a (byte 1) - which would have been
hidden previously.
For Select I couldn't use ExtraHelp. It was written in !JFPatch assembler, and it wasn't particularly nice. I rewrote the module in C, which made it a lot simpler in general, but also gave me the opportunity for more flexibility. The 'extended' information switch wasn't as useful, so I dropped it, but the remainder of the behaviour was retained.
The file format was slightly changed to define that the first line of the help would be the command name, version and date, in the same format as used by modules. This version message would be printed with any help message so that it was clear which version of the command was installed.
==> Help on keyword ImgConvert (library command)
Command is: ImgConvert 0.05 (09 Jan 2004)
*ImgConvert converts between different image file formats. The input
file is converted from its current format into another format. The
conversion is performed by the ImageFileConvert system.
Syntax: *ImgConvert [-h] -t <type> <inputfile> <outputfile>
Switches:
-h Display help
-t <type> Select the filetype to which the file should be
converted.
A new help keyword 'Library' was supported, which would print out the installed library tools, in the same way that *Help Modules would list the modules installed.
*Help Library
==> Help on keyword Library
MD5Hash 0.06 (31 Oct 2005)
MiniGZip 0.06 (04 Feb 2004)
MiniUnzip 0.16 (13 Oct 2005)
MiniZip 1.18 (04 Mar 2004)
Squash 0.63 (06 Oct 2004)
CJPEG 1.05 (17 Jan 2005)
DJPEG 1.05 (17 Jan 2005)
ImgConvert 0.05 (09 Jan 2004)
JPEGTran 1.05 (17 Jan 2005)
MiniJTran 1.02 (18 Feb 2005)
RdJPGCom 1.05 (17 Jan 2005)
WrJPGCom 1.05 (17 Jan 2005)
ARP 0.07 (11 Apr 2002)
Finger 0.11 (25 Apr 2004)
GetHost 0.12 (11 Apr 2002)
Host 0.18 (06 Dec 2002)
IFConfig 2.09 (18 Mar 2006)
IFRConfig 1.09 (20 Dec 2001)
INetFW 1.08 (06 Dec 2002)
INetStat 1.07 (13 Oct 2005)
MDNSShow 0.01 (22 Dec 2004)
Ping 1.06 (11 Dec 2004)
Pong 1.06 (07 Oct 2004)
Route 2.08 (13 Oct 2005)
RTime 0.20 (16 Mar 2004)
SetProxies 0.02 (02 Jan 2003)
ShowStat 1.19 (14 Mar 2006)
SysCtl 1.05 (07 Oct 2004)
Telnet 1.05 (21 Nov 2001)
TFTP 1.02 (01 Sep 1992)
TraceRoute 1.05 (07 Oct 2004)
RExec 1.07 (02 Feb 2002)
RLogin 1.01 (02 Feb 2002)
RSH 1.01 (16 Mar 2002)
MD5Hash 0.02 (15 Apr 2002)
Addr 0.14 (08 Oct 2003)
AddApp 1.06 (20 Feb 2006)
AppPath 0.09 (13 Feb 2006)
AppSize 1.07 (20 Feb 2006)
Do 1.05 (20 Feb 2006)
IfThere 1.06 (22 Feb 2006)
LoadCMOS 0.07 (04 Feb 2004)
MiniGrep 0.06 (21 Mar 2004)
PrepPath 0.09 (13 Feb 2006)
Repeat 0.04 (13 Oct 2005)
SafeLogon 0.08 (04 Feb 2004)
X 1.06 (20 Feb 2006)
NASM 1.00 (04 Jun 2002)
NDISASM 1.00 (04 Jun 2002)
xmlcatalog 1.16 (03 Apr 2002)
xmllint 1.19 (03 Apr 2002)
xsltproc 1.27 (29 May 2002)
Aliases were expanded as well, printing out the expansion. Because there's
no way of knowing any more about what the command was intended to do or
where it was set, that's all that can be said. I considered providing more
information about the special aliases, such as '@RunType_xxx'
but decided that adding special cases in there would not help to clarify the
variables to the user, so I left them alone.
*Help Alias ==> Help on keyword Alias (alias) *Alias is an aliased command. Expansion: %If |"%0|"=|"|" Then Show Alias$* Else %If |"%1|"=|"|" Then Show alias$%0 Else %Set Alias$%0 %*1
I'm almost certain that nobody paid much attention to these changes, but they were there. I would hope that people just found them useful when they used the *Help command, though.
Boot logging
As the boot sequence becomes more complex, it is difficult to identify where a problem might lie. In order to try to help address this (and it would never be a simple 'do this and the problem is fixed') the boot sequence was updated and a new module BootLog created which would record the operations performed during the boot sequence to a memory only SysLog log.
This would, at the very least, provide a record of what ran and allowed the boot sequence to record any errors it encountered. Initially it only reported the things that were printed to the screen, but I had planned that later it would offer a 'diagnostic' mode, where it would record file operations and other significant events so that problems might be tracked down a little more easily.
The command *SysLog Boot Show was aliased to DMesg, which made it a little more memorable (well, more memorable if you used Linux or Unix systems).
*dmesg 31 Jan 13:45:12 100 --- Boot log starting --- 31 Jan 13:45:12 100 DefaultUser : Justin 31 Jan 13:45:14 100 Boot:Utils.UnplugTbox 31 Jan 13:45:18 100 HostFS:$.!Boot.Choices.Hardware.ID_13.Boot.PreDesk.SetUpNet 31 Jan 13:45:36 100 HostFS:$.!Boot.Choices.Hardware.ID_13.Boot.PreDesk.Configure 31 Jan 13:45:37 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.!!Wimp 31 Jan 13:45:37 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.Alarm 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.Aliases 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.AMSetup 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.ARPlayer 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.DefaultDir 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.DiagDump 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.FontSetup 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.GMail 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.IconSetup 31 Jan 13:45:38 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.LoadURI 31 Jan 13:45:39 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.RCS 31 Jan 13:45:39 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.SetUpUSB 31 Jan 13:45:39 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.WimpMode 31 Jan 13:45:39 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.WinSetup 31 Jan 13:45:39 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.AMPlayer 31 Jan 13:45:40 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.bluedirs 31 Jan 13:45:41 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.bluemenus 31 Jan 13:45:41 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.Filer 31 Jan 13:45:41 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.Green 31 Jan 13:45:41 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.LineEditor 31 Jan 13:45:42 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.NoCoverIB 31 Jan 13:45:42 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.PurpleBack 31 Jan 13:45:42 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.styled 31 Jan 13:45:42 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.TaskWindow 31 Jan 13:45:43 100 HostFS:$.!Boot.Choices.Users.Justin.Boot.PreDesk.WimpR 31 Jan 13:45:53 100 --- Boot pre-desktop log ended --- 31 Jan 13:46:11 080 Add to Apps: Could not locate 'Boot:^.Apps' 31 Jan 13:46:12 080 Look at: Could not locate 'Inter:£.Mail.!NewsDir' 31 Jan 13:46:27 080 Add to Apps: Could not locate 'Inter:£.Mail.!GMail'
Disclaimer: By submitting comments through this form you are implicitly agreeing to allow its reproduction in the diary.