Settings

• Platform: the platform for which you want the .sis file. This is the only mandatory setting.

• UID: the UID (UID3) of your application, uniquely identifying it in the Symbian Universe. The UID is a 32-bit number and must be specified as eight hexadecimal digits (e.g. e7a1f1c0). If you don't specify a UID, the conversion process will pick one based on the name of your .mex file, so the same file name will also produce the same UID each time you create the .sis file.

  For any application you plan to distribute, you should obtain an UID from Symbian. Picking one randomly may cause a conflict of your application with other applications. Note also that the valid UID range depends on the platform and signing type.

• Application Name: a short name for your application, shown to the user. It must not contain quotes or unprintable characters, and defaults to the .mex file name.

• Caption: a caption for your application, shown to the user. It must not contain quotes or unprintable characters, and defaults to the Application Name.

• Description: a description for your application, presented to the user during installation. It must not contain quotes or unprintable characters, and defaults to the Caption.

• Version: the version number of your application, presented to the user during installation. It must be in the format x.yy, and defaults to 1.00.

• m Environment Inclusion: determines whether and how the produced .sis file should include the m runtime environment. There are three options:

  Static: statically link the m runtime environment and the required library modules, and store other m resources in an application specific directory. This is the safest option under most circumstances.

  Dynamic, included: dynamically link to the m runtime environment, and include it as an embedded .sis file. This is the best option to elegantly save space when having potentially many m applications installed simultaneously on the same device.

  Dynamic, excluded: dynamically link to the m runtime environment, without including it. You should probably only select this option either during testing, as the resulting .sis will be much smaller, and the environment is already present on a device where m is installed, or if you are requesting Extended or Certified capabilities with a pre-installed m runtime environment and you are going to sign the resulting .sis yourself.

  The following table summarizes the three options:

  Option	Static	Dynamic	Dynamic
  		included	excluded
  Depends on mEnvironment.sis	no	yes	yes
  Requires pre-installed m environment	no	no	yes
  Signing requires signed environment	no	n/a	yes
  use try supports missing modules	no	yes	yes
  75-200 kB overhead per application	yes	no	no
  Minimal .sis size and quick install	no	no	yes

• Vendor: the name of the vendor of your application (probably your name), presented to the user during installation if you will properly sign your application. It must not contain quotes or unprintable characters, and defaults to "m User".
  This setting is ignored for 2nd edition platforms.

• Signing: if set to "Self-sign", the produced .sis file will be self signed and ready to install. If you are requesting Extended or Certified capabilities and are going to sign the resulting .sis yourself, set this to "dont sign".
  This setting is ignored for 2nd edition platforms.

• Capability Set: the requested set of capabilities (see also * ()). The required capabilities depend on the m functions your application is using. If they require Extended or Certified capabilities, you should not set "m Environment Inclusion" to "Dynamic, included", and you must sign the .sis file yourself.
  This setting is ignored for 2nd edition platforms.