In this chapter of the Tutorial, we take a brake from the description of the system itself and delve a little deeper into how RISC OS applications work. RISC OS applications are typically held within special Application directories, this allows some of the complexity of the application and its required files to be hidden from the user within its own directory structure. The Application directory also allows the application to be kept with the support files it supplies. For the most part, RISC OS applications do not need to be supplied with bloated installer programs, as quite often, it is just a case of copying the application directory to the media from which the user would like to run it. The exception to this, is when applications use System Modules or provide modules which are likely to be used by other applications. Most often, these modules are actually updates to the standard system modules as supplied with RISC OS, but occasionally they are possibly only required for the application itself. Applications can contain an almost unlimited number of files and other sub-directories (only limited by the filing system in use).
An application directory is a special case of a normal directory and is created in exactly the same way as a normal directory but with one difference. RISC OS application directories all have names which begin with a "!" such as !Boot (The boot sequence), or !MyApp. If you create a new directory and give it a name beginning with a "!", then the resulting icon will be a special generic application icon. Existing normal directories may also be renamed to have a "!" at the beginning of their names.
Once you've created an Application Directory, try double clicking on it, you will see an error. This is because once an application directory is seen by the Filer, the Filer knows that it is a special directory and will try to locate some special files within it.
A typical RISC OS application directory will contain the following files:
!Boot
!Run
!Help
!RunImage
!Sprites
!Sprites22
Messages
All of the above files are completely optional, but if a !Run is not present, then double clicking on the application will produce an error because the Filer will try and execute such a file. One point to note is that !Boot files shouldn't be confused with !Boot the application (Boot Sequence) in the root of your bootable drive.
!Boot, !Sprites, !Sprites22 and !Help are also special cases which the Filer will attempt to use in particular circumstances, although if not present, these will not produce errors.
Whenever a new application is "Seen" by the Filer, it will attempt to Execute !Boot from within the directory. If no !Boot file is found, then nothing will happen, but when one is, then it will be executed. This is the mechanism which allows the application to identify itself to the system and set up icons and filetypes which it can recognise. It is important to note that the Filer will only try and run the !Boot of an application once during the computing session, so any initialisation can be done in the !Boot files.
!Help is associated with the Filer's Help entry on the Filer menu. If the Filer sees a !Help file within the application directory, then this menu entry will be activated for that application and the file will be executed when the help entry from the Filer menu is selected.
!RunImage is more a convention than a special name and the Filer doesn't directly call this, although it does have a special feature in that the application's datestamp takes its information from the !RunImage file if present. This allows the application to exhibit a timestamp which relates to the real timestamp of the application code rather than just when the application directory was created.
Up until this point, we have not mentioned anything about the filetypes of the common files within the application directories. This is largely because it does not matter to the Filer what type a file is, the Filer just calls the same operation on the files regardless of their type. By convention, the !Boot and !Run files are of type "Obey" and the !Help is often a Text file. !RunImage is often either BASIC, or Absolute.
When the Filer calls !Boot and !Run within application directories, it does so with the following commands Filer_Boot and Filer_Run. Filer_Boot. They are actually called on the application Directory. That is to say the whole application is Filer_Booted and this operation looks for a !Boot file within the directory and if present executes it. The Filer_Run command attempts to execute !Run within the application directory regardless of whether it is actually present, and therefore this is why you will see an error if the file is not present. Both Filer_Boot and Filer_Run Run the !Boot and !Run files as if they were double clicked and therefore if you wish to experiment with them, you can open up the application directories and double click these files to see what they do.
!Sprites & !Sprites22 are files which are expected to have particular types and as you might guess, these should be Sprite files. These are the files which hold icons for the application and are also looked for when the Filer first sees the application. !Sprites is for lower resolution modes, such as those used on TVs and !Sprites22 is used for high resolution modes. !Sprites uses rectangular pixels, !Sprites22 uses square pixels. There are guidelines for the size of these !Sprites, but the easiest way to create one of the correct size is to copy and modify an existing system sprite. One important point to note about the Filer's automatic use of these files is that they are only looked at when the Filer first sees the application during a Filer_Boot and so any changes to the sprites will not be refreshed automatically. To force the system to re-read a sprite file and update the System Sprite Pool, you must issue a *Iconsprites command, with a parameter telling the system which file to re-read. The system Sprite Pool is an area in memory which holds all known sprite icons. These are icons which programs and the RISC OS desktop interface use for displaying all sorts of buttons and icons. Once a sprite is in the pool, it can be referenced by name and does not have to be reloaded from disc each time it is required. It is this Sprite Pool and the updating of it which allows users to customise the look of their desktop icons for the standard system applications and tools, such as hard drive and floppy drive icons on the Iconbar.
To give an application an icon of your choosing rather than the generic system application sprite, all you need to do is to create a sprite within the special files !Sprites and !Sprites22, which has the same name as the application directory (including the "!"). That is, if your application is called !Myapp, then it should contain a !Sprites & !Sprites22 which contain a picture called !myApp. These files are created and modified with !Paint. When displayed in Paint, all sprite names within a sprite file are lower case. RISC OS filenames are not case sensitive.
A normal directory, when double clicked, will open. Application directories when double clicked will attempt to run, so how do you open up the directory? Answer, you hold shift down and then double click. This prevents the Filer doing a Filer_Run on the application and instead allows the user to see inside the directory. Normally you wouldn't want to do this as a user, because you just want to run application programs and use them, but if you are designing your own applications, or just want to see how other people did, then this is the first place to start. Remember, applications don't have to be complex programs with loads of machine code etc. There is nothing to stop you having an application directory which just runs a list of commands. That is a subject for another tutorial though.
That's all for now, but why not have a browse around your own hard disc and delve into some of the applications which you have installed.