Package header

The package header contains the component name in each of the supported languages, the UID of the package, the major and minor version number and build number, and package options.

The syntax for a package header is:

#{"Package name for language 1", ...}, (package-uid), major, minor, build-number[, package-options, ...]

For example:

#{"MyApp-EN", "MyApp-FR", "MyApp-Zulu"}, (0x1000001F), 1, 2, 3, TYPE=SA

• package-options

  • package-type

• Notes

In the package-header statement, package-options may be any of the following:

Abbreviation Name Description TYPE=package-type Specifies the package-type that identifies the purpose of the package SH SHUTDOWNAPPS Shuts down all applications on the device. Because Software Install terminates running applications on the device as needed during the installation process, this flag is deprecated. NC NOCOMPRESS Files will not be compressed within the SIS file.

package-type may be any one of the following:

Abbreviation Name Description SA SISAPP A package containing an application (the default type). For details on upgrading applications, see Upgrading. SP SISPATCH A package that patches an existing component. It may be uninstalled separately from the package it patches. For more details, see Upgrading. PU PARTIALUPGRADE This is a variation of SA in that files present in the original package now missing in the upgrade package are not removed. It may not be uninstalled separately from the package it upgrades. For more details, see Upgrading. PA PIAPP This is a special indicator for use with applications which are pre-installed, in-place, on media cards. For more information, see the section on Installing software via a media card, below. PP PIPATCH This is a special indicator for use with patches which are pre-installed, in-place, on media cards and augment an application present on the device (for example, to provide extra game levels). For more information, see the section on Installing software via a media card, below.

• These options are mutually exclusive.

• All package files require a UID, even if the installed components do not strictly require one. It is used to identify packages when installing, upgrading and removing.

  • The UID value specified in an application's (SISAPP) package header must be unique. It uniquely identifies the SIS file, and is never the same as the application's UID.

  • The package UID is allocated in the same way as an application's 3rd UID, through https://www.symbiansigned.com. The process is described here.

  • The package UID for the following types of SIS files should be identical to the UID for the main application or system component with which they are associated:

    • Patches (SISPATCH)

    • Upgrade components (PARTIALUPGRADE)

• The package's major and minor version numbers are required for version control (e.g., AppName 3.1 specifies a major build 3, and minor build 1.)

• The build-number replaces the variant value which was unimplemented in previous versions of MakeSIS.

• All numbers can be hexadecimal.

• The package name is language-dependent. It is used to identify the package in the installation dialogs and in the list of installed programs in the control panel's Add\remove program.

• The number of package names must equal the number of languages specified in the languages line, and should be in the same order.

• The package options and package type values can either be specified in full, or as two letter abbreviations.

Pre-installed applications

An application can be pre-installed to a media card before sale, in other words at the factory.

To prepare such a media card, a PKG file of type PA ('preinstalled application') is required.

When the Makesis tool is run on a PKG file of type PA, it produces a 'stub' SIS file which is required by the software installer to validate the application. Although all EXEs and DLLs must be listed in the PKG file (so that they can be validated), with ! as the target drive letter, no files are copied into the SIS archive. The media card should contain the application and other required files in a pre-installed form (in other words, not packaged in the SIS file), together with the stub SIS file. Stub SIS files should be located in the card's \private\10202DCE\ directory in order to be detected by the process that monitors for media card insertion.

When the media card is inserted into the phone for the first time (or on phone boot-up), an installation takes place. This differs from a standard SIS file installation in that no files are copied.

If the media card is then removed, the package is not uninstalled. So, for example, saved game levels will not be deleted if the card is removed, then re-inserted.

If the user uninstalls a pre-installed application, no files are removed (except for any data stored in the application's private directory that may have been created on the phone). The media card does not need to be present for an uninstall to take place.

Because the stub SIS file is present on the media card, this installation mechanism allows propagation of the media card to other phones.

Pre-installed patches

A pre-installed patch delivers removable functionality to an existing package in a form which is already extracted to the media card. Applications that support patching in this way may need to be able to recognise that the additional information (for example new game levels) may exist on a different media drive to the one on which the main package was installed.

To create a SIS file containing a pre-installed patch, the PKG file must be of type PP (pre-installed patch).