Thanks to Symbian releasing the SIS file format documentation, plus the secdump tool from the Symbian SDK (running under wine on Linux) it was possible to write a parser for the SIS file format in PHP and scan the parse tree for common faults.
This tool is not really for checking the integrity of your SIS file, it is assumed that if you're using the tools provided by Symbian (that is makesis, signsis and makekeys) then your SIS file will be well formed. This tool does not check CRCs, hashes or signatures, and it makes certain assumptions about certificates when deciding about the signing status of your SIS file. For this reason, you may well know better than the tool and you should disregard any advice that you know does not apply.
FileNull is indeed deprecated from Symbian OS v9.1 onwards. Its use has been replaced by private directories. When you uninstall an application, any private directories owned by that application (on all drives) will be deleted, so there is no need to use FileNull on any file in a private directory.
It is bad practice to create data files that are not readable or usable by the user outside of a private directory, e.g. a camera application may create photos in a public area of the device, but shouldn't store its configuration there. When you uninstall an application, data files that the user may use should persist, while configuration data should be removed. Using private directories and public areas correctly will ensure this happens automatically.
That Symbian Signed recommend using FileNull as a "Best Practice" and require it as a condition of signing is idiotic, and is a result of poor communication inside Symbian. You should contact Symbian Signed and complain that they force you to use this bad practice.
Both DLLs and Executables use much the same file format in Symbian OS, and it is hard for the tool to tell them apart. If the tool flags an error that you are using an innapropriate private directory, but your SIS file install fine it will most likely be because your SIS file installs an executable whose name does not end in .exe. There is no need to use .exe as a file extension for your executables, this is a limitation in the tool.
The Secure ID (SID) is the most important concept in the Symbian OS PlatSec security model. Only an executable has a SID, and there will only ever be at most one executable on a given phone with a given SID at any one time. Since the SID of an executable is unique, it can be used as an identifier to refer to the executable that is far more meaningful that the executable name.
When you are writing an executable, the SID is allocated to the executable in the MMP file. If the MMP file has a SecureId line, then that will be taken as the SID for the process, if this line is not present then UID3 from the UID line will be used as the SID. If neither of these lines are present, then the SID will be zero.
SIDs are primarily used to control access to private directories, only the executable with a given SID can read and write from the private directory /private/<SID>/. The SID of an application can also be used to restrict access to IPC calls, using the CPolicyServer class.
SIDs fall in to two ranges. The so-called protected range have a top bit of zero (i.e. 0x00000000 through to 0x7fffffff) and the unprotected range, (0x80000000 onwards.) The difference between these two ranges is that you may only use a protected SID if your application is Symbian Signed (or signed by an equivalent manufacturer or operator signing program.) A self-signed application that uses protected SIDs will be rejected. Because SIDs are globally unique, it is important to reserve the SIDs you use by creating an account with Symbian Signed and reserving them through the web interface. This service is entirely free of charge, and you may reserve as many as you like for your own use.
Both executables and all types of DLLs may have a Vendor ID which is UID that uniquely identifies the author of the application. The vendor ID is set in the MMP file for an application by including a VendorId line. If the VendorId line is unspecified in the MMP file, it defaults to zero.
An application that includes an executable or DLL with a non-zero vendor ID will need to be Symbian Signed (or signed by an equivalent manufacturer or operator signing program.)
At the time of writing, Symbian Signed has no method or process of obtaining an official Vendor ID for your applications. Either you should use zero, or contact Symbian Signed directly to request an ID.
The package UID is the unique identifier given to a SIS file. It is specified in the package (pkg) file, as part of the package header. If you ever create an upgrade for the package, you'll use the pUID to refer to the original package you wish to upgrade.
It should be noted that the pUID and the SID are completely seperate and unrelated. The pUID should not be the same as any SID included in the package, though this is technically allowed by the installer it is considered poor style. Obviously, a package only has a single pUID, but may contain may executables, and therefore many seperate SIDs.
However, the pUID and the SID do have common ground in that they are both seperated in to the protected and unprotected ranges. A package that has a pUID taken from the protected range must be Symbian Signed (or signed by an equivalent manufacturer or operator signing program.)
WTFWMSFI is copyright 2006 Chris Davies. It was born out of the common frustration of everyone who has ever asked me about their installation problems, and my frustration with answering the questions. Enjoy, and for those inside Symbian, use the techview installer, dammit! I didn't slave over that thing 18 hours a day for two weeks for nowt :)