Upgrading Help Files on the Secure 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 $? [email protected]
                   
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)