Specifications

1 SERIES 3 PROGRAMMING OVERVIEW
1-3
Running programs via RunImg
An alternative to installing a program in the System Screen with its own file list is to run it from the
RunImg icon:
•
the user presses
TAB
while the highlight is within the RunImg file list
•
the user navigates the file selector until it selects the program file
•
the user presses
ENTER
to start this program.
This procedure can be simplified if the program is placed in a top-level
\img\
directory, and given the
extension
.img
. In this case, the program will automatically appear as an entry in the RunImg file list.
However, a program run in this way will receive no special command line from the System Screen. Nor
will it receive any
Shutdown
or
Switchfile
messages from the System Screen. (These messages are
discussed in the following chapter).
Program files with and without icon files
An application can simply not have an icon, although in this case the system screen will simply refuse to
install it. The application can, however, still be run from RunImg, in which case, an empty icon boundary
will be displayed in any status window used.
Icon files, such as
tele.pic
, may be produced by a variety of means:
•
using the
Iconed
demo application that can be built using the Hwif part of the SDK or, for the
Series 3a and Work
about
, the
Iconeda
application that is installed in a
\sibosdk\s3atool
directory
•
using the Window Server tool
wspcx.exe
on the
.pcx
output of a PC program such as
Windows
PaintBrush
.
The
.pic
file can contain:
•
a 24x24 bitmap for a Series 3 icon.
•
two 48x48 bitmaps for a Series 3a icon - the first and second bitmaps specify the black and grey
planes respectively.
•
a 24x24 bitmap for a Series 3 icon followed by two 48x48 bitmaps for a Series 3a icon.
The format of
.pic
files is given in the
Bitmaps
section in the
Window Server Reference
manual.
Resource files and shell data files
See the
Resource Files
chapter of the
Additional System Information
manual for a description of the
format and uses of resource files.
Shell data files are discussed in the following chapter.
Customised add-files
In most cases, at least one add-file slot will be free for use by the application itself.
One important reason to build an extra file into the
.app
file, rather than leaving such a file separate, is
that it diminishes the chance of a user copying the
.app
file from one SSD to another but neglecting to
copy a vital associated file at the same time.
Finding add-files within a .app file
Ordinarily, applications have no need to find add-files within themselves, since system code takes care of
this on their behalf.
One possible exception is when an application needs to access a
customised
add-file. In this case,
knowledge of the format of the header of a
.img
(or a
.app
) file is required. In fact, this header just
contains the same information as is returned by invoking
edump.exe
.
The header of a
.img
file is described by the
ImgHeader
struct, defined in
epoc.h
. See the chapter
Processes and Inter-process Messaging
in the
Plib Reference
manual for a discussion on this struct.