Standard for Portable Applications

This page contains the report describing the standard for portable applications and gives links to documents that deal with this standard.

SPA Resources

Below is a list of resources containing other information about the SPA.

Implementing SPA into your applications

Standard for Portable Applications

The Standard for Portable Applications (SPA) describes the format in which all SPA-compliant applications should be organized in. SPA outlines three standards that must be met. It describes the way applications can store their settings - the Portable configuration standard, it sets forth a format for a directory file describing which files may be run - the Directory file standard, and how multiple portable applications can be organized together - the Coexistence standard. If an application is able to meet all three of these standards, it is considered SPA-compliant.

The portable configuration standard is very simple. In the directory where the portable application exists should be a file called locate.cfg. This file should contain the location(s) where the application should look for its settings and stored files. In the following example, the application will search for its settings first in "application data\application", then in the current directory.

%appdata%\application
.

Note that all Windows environment variables are expanded. Placing a colon (:) at the beginning of any line will comment that line out - that directory will not be searched.

The directory file contains information about how to start the application along with other references/components that may be accessed. This file can be read either manually or by an external program. The following is an example of a fake directory file that might be associated with an application called "Example."

[main]
Display=Example
Open=example.exe
Params=-w example
Icon=example.ico
[web]
Display=Example on the Web
Open=http://www.example.com
[readme]
Display=Readme for Example
Open=readme.txt

The "open" parameter is required; it specifies which resource must be opened - the resource may be a web site, a readme, or the application itself. The display parameter is also required as it specifies the text an external program will show for that entry. All other fields are optional, but the "params" and "icon" parameters should be universally supported.

An application reader, a program that is capable of parsing this file, might display it as the following:

Example
- Example
- Example on the Web
- Readme for Example

Section names, for the most part, do not matter, but they should be similar to that of their entry. [web] or [readme] are great names to describe their respective entries even though the display parameter might be set to "Example on the Web" or "Readme for Example." The exception to this rule is for the [main] section. This section must be used for the main component of the portable application; an application reader will display the name of the application as the value of the display parameter in the [main] section. All directory files must be in the root of the application's directory and must be called "dirfile.cfg."

The coexistence standard states that all portable applications should be able to coexist in a single directory - a user can create a "portable" directory with subdirectories containing all of his or her portable applications. Below is a possible example of the directory structure that a portable applications directory might resemble.

Example
- dirfile.cfg
- example.dll
- example.exe
- example.ico
- locate.cfg
- readme.txt
Example2
- dirfile.cfg
- example2.exe
- example2.wav
- locate.cfg

As demonstrated above, all portable applications must have in their root directory a file called dirfile.cfg, a main application to run, and a file called locate.cfg. With this in mind, an application reader might show this directory as the following:

Example
- Example
- Example on the Web
- Readme for Example
Example2
- Example2

Below is a list, from the highest version to the lowest, of all version changes this document has gone through along with the date it was modified, the new version number, the modifier's name and amendment. If amending this document, add your entry to the top of the list below, formatting it exactly like the original - the last entry on this list. When making amendments, add a second decimal point followed by a 0.1 increase solely for spelling and grammatical/organizational corrections. This means that if making a correction to version 0, the new version will be 0.0.1, then 0.0.2, and so on. For minor changes to the actual standard itself, increase the version number by 0.1. In this case, the second decimal point should be removed. For example, if making a standard change to 0.0.2, the next version will be 0.1. If making a major change or a complete rewrite of the standard, increase the version number by 1, as well as again, removing the second decimal point. The version of this document is described in the first entry of this list. Please send all changes to nik62591@gmail.com so the modifications can be evaluated and republished.
Thank you.

Date	Version	Amender's name	Amendments
2009-08-22	0.0.1	Niko Carpenter	Organization changes; XHTML now validates
2009-04-05	0	Niko Carpenter	Original