diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-75E5D15C-83F1-5A32-BFC5-B5DC10FCDB99.dita --- a/Symbian3/PDK/Source/GUID-75E5D15C-83F1-5A32-BFC5-B5DC10FCDB99.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-75E5D15C-83F1-5A32-BFC5-B5DC10FCDB99.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,53 +1,53 @@ - - - - - -Upgrading Help Files on the Secure PlatformThis page describes how to upgrade help files on the secure Symbian platform.
Introduction

Platform Security makes replacing help files more difficult than it was in earlier, non-secure platform releases. On the secure platform, help files can be loaded only from \resource\help\ on any drive. This directory is read-only and can only be written to by processes with very high capabilities, such as the kernel and the software installer. An exception to the rule that help files cannot be overwritten occurs when the vendor name - held in stub SIS files in the \system\install\ directory on any drive - is the same as that for the previous installation. In this situation the software installer allows the upgrade.

The only way to add a help file to a \resource\help\ directory is to install software with the help file packaged in a SIS file. To prevent malicious code from overwriting other applications’ help files (including those of core applications stored in ROM), the software installer will not install a help file if a file with the same name already exists in the \resource\help\ directory, on any drive (unless it is identified by the installer as a valid upgrade).

The installer not only prevents you from overwriting another package's help files, but it also prevents you from eclipsing them. For more information, see Language-Neutral Files.

Creating stub SIS files during a build

Apart from the vendor name, a stub SIS file also contains the information needed to remove the application or file; for example, the full paths of the installed files and application components. Stub SIS files can be distinguised from normal SIS files by their size - stub SIS files are usually several hundred bytes long, much smaller than normal SIS files.

Core applications such as Calendar and Contacts are part of the ROM, and so are never installed. To be able to upgrade them and their help files, you must first create stub SIS files for them in the z:\system\install\ directory.

You create SIS files from package (.pkg) files using the makeSIS utility with the -s flag, which excludes binaries and media from the SIS file.

For more information, see Upgrading OS Components.

Create stub SIS files as part of the build as follows:

  1. Create a make file that calls the makeSIS utility (see the example, below).

  2. Add the make file to the PRJ_MMPFILES section of the component’s bld.inf file. For example, adding the make file Foo.mk:

    ///Bld.inf -PRJ_MMPFILES -makefile Foo.mk

An example make file - called Foo.mk, which is used to create Foo.sis - is shown below:

# Build Stub SIS file - -SISNAME=Foo -SRCDIR=.\ - -# Select appropriate directory and ensure it exists -!if "$(PLATFORM)"=="WINS" || "$(PLATFORM)"=="WINSCW" -TARGETDIR=$(EPOCROOT)EPOC32\RELEASE\$(PLATFORM)\$(CFG)\Z\System\Install -!else -TARGETDIR=$(EPOCROOT)EPOC32\Data\Z\System\Install -!endif - -$(TARGETDIR) : - @perl -S emkdir.pl "$(TARGETDIR)" - - -# Build stub SIS file -SISFILE= $(TARGETDIR)\$(SISNAME).sis - -$(SISFILE) : $(SRCDIR)\$(SISNAME).pkg - makesis -s $? $@ - -do_nothing : - rem do_nothing - -# The targets invoked by abld -MAKMAKE : do_nothing -RESOURCE : $(TARGETDIR) $(SISFILE) -SAVESPACE : BLD -BLD : do_nothing -FREEZE : do_nothing -LIB : do_nothing -CLEANLIB : do_nothing -FINAL : do_nothing - -CLEAN : - erase $(SISFILE) - -RELEASABLES : + + + + + +Upgrading Help Files on the Secure PlatformThis page describes how to upgrade help files on the secure Symbian platform.
  • Introduction. This section is intended for a general audience.

  • Creating stub SIS files during a build. This section is intended for Licencees.

Introduction

Platform Security makes replacing help files more difficult than it was in earlier, non-secure platform releases. On the secure platform, help files can be loaded only from \resource\help\ on any drive. This directory is read-only and can only be written to by processes with very high capabilities, such as the kernel and the software installer. An exception to the rule that help files cannot be overwritten occurs when the vendor name - held in stub SIS files in the \system\install\ directory on any drive - is the same as that for the previous installation. In this situation the software installer allows the upgrade.

The only way to add a help file to a \resource\help\ directory is to install software with the help file packaged in a SIS file. To prevent malicious code from overwriting other applications’ help files (including those of core applications stored in ROM), the software installer will not install a help file if a file with the same name already exists in the \resource\help\ directory, on any drive (unless it is identified by the installer as a valid upgrade).

The installer not only prevents you from overwriting another package's help files, but it also prevents you from eclipsing them. For more information, see Language-Neutral Files.

Creating stub SIS files during a build

Apart from the vendor name, a stub SIS file also contains the information needed to remove the application or file; for example, the full paths of the installed files and application components. Stub SIS files can be distinguised from normal SIS files by their size - stub SIS files are usually several hundred bytes long, much smaller than normal SIS files.

Core applications such as Calendar and Contacts are part of the ROM, and so are never installed. To be able to upgrade them and their help files, you must first create stub SIS files for them in the z:\system\install\ directory.

You create SIS files from package (.pkg) files using the makeSIS utility with the -s flag, which excludes binaries and media from the SIS file.

For more information, see Upgrading OS Components.

Create stub SIS files as part of the build as follows:

  1. Create a make file that calls the makeSIS utility (see the example, below).

  2. Add the make file to the PRJ_MMPFILES section of the component’s bld.inf file. For example, adding the make file Foo.mk:

    ///Bld.inf +PRJ_MMPFILES +makefile Foo.mk

An example make file - called Foo.mk, which is used to create Foo.sis - is shown below:

# Build Stub SIS file + +SISNAME=Foo +SRCDIR=.\ + +# Select appropriate directory and ensure it exists +!if "$(PLATFORM)"=="WINS" || "$(PLATFORM)"=="WINSCW" +TARGETDIR=$(EPOCROOT)EPOC32\RELEASE\$(PLATFORM)\$(CFG)\Z\System\Install +!else +TARGETDIR=$(EPOCROOT)EPOC32\Data\Z\System\Install +!endif + +$(TARGETDIR) : + @perl -S emkdir.pl "$(TARGETDIR)" + + +# Build stub SIS file +SISFILE= $(TARGETDIR)\$(SISNAME).sis + +$(SISFILE) : $(SRCDIR)\$(SISNAME).pkg + makesis -s $? $@ + +do_nothing : + rem do_nothing + +# The targets invoked by abld +MAKMAKE : do_nothing +RESOURCE : $(TARGETDIR) $(SISFILE) +SAVESPACE : BLD +BLD : do_nothing +FREEZE : do_nothing +LIB : do_nothing +CLEANLIB : do_nothing +FINAL : do_nothing + +CLEAN : + erase $(SISFILE) + +RELEASABLES : @echo $(SISFILE)
\ No newline at end of file