Application support was introduced in SXD System 7.2, released on February 14, 2015. Similar to support on other platforms, applications on NS operating systems are self-contained native-code programs written by first- or third-party developers that extend the functionality of the device in some way. They consist of, at a minimum, one LSL script, sometimes referred to as a user module. Developers are encouraged to use as few scripts as possible when writing applications to prevent unnecessary script counts, which may impact simulator performance.

lookup table for part numbers of common first-party controllers

Applications reside in the user memory prim, also known as the memory card, or as the 'program' prim, due to its description, program. This tag is used by the system to identify where user software and data is installed, and allows user programs to communicate amongst themselves without incurring a penalty due to crosstalk with the operating system.

To communicate with the operating system and with other scripts in user memory, your application must send and respond to certain linked messages, as described in the linked messages documentation. For consistency, you should use the Firestorm preprocessor, which will allow you to use the header files, and therefore refer to messages by name instead of number. The most important messages to handle are the APPLICATION_... messages:

In order to detect applications, the system sends the APPLICATION_QUERY message. Applications should respond with APPLICATION_REPORT. For example:

#include <system.lsl>
#include <application.lsl>


string program_name; // shown on menu button; keep it short

default {
	state_entry() {
		program_name = llGetScriptName();
		// send immediately on script initialization so it will show up after install:
		llMessageLinked(LINK_THIS, APPLICATION_REPORT, program_name, "");
	}

	link_message(integer src, integer n, string m, key id) {
		if(n == APPLICATION_QUERY) {
			llMessageLinked(LINK_THIS, APPLICATION_REPORT, program_name, "");
		}
	}
}

To signal that your application has been accessed from the menus (or with the open command), the system will send APPLICATION_START with the same string parameter you provided, e.g.,

#include <system.lsl>
#include <application.lsl>

string program_name; // shown on menu button; keep it short

default {
	state_entry() {
		program_name = llGetScriptName();
		// send immediately on script initialization so it will show up after install:
		llMessageLinked(LINK_THIS, APPLICATION_REPORT, program_name, "");
	}

	link_message(integer src, integer n, string m, key id) {
		if(n == APPLICATION_QUERY) {
			llMessageLinked(LINK_THIS, APPLICATION_REPORT, program_name, "");
		} else if(n == APPLICATION_START && m == program_name) {
			// present a menu or otherwise interact with the user
		}
	}
}

To handle other linked messages, you must be aware of the version of the operating system you are targeting. Companion 8.4 and earlier use a different scheme from ATOS/CX and Companion 8.5+, as described below:

versionreceived as...send to OS as...
pre-8.5 Companionapplication.lsl formatsystem.lsl format
8.5+ Companion and ATOS/CXsystem.lsl formatsystem.lsl format

To use system.lsl format, use the normal names for the messages, as described on the linked messages page. To use application.lsl format, prefix APP_ before the message name, e.g. APP_EXECUTE instead of EXECUTE. Numerically, these messages are equivalent to –1000 – n, where n is the message number, e.g. message 1 (COMMAND) becomes -1001 (APP_COMMAND). This format is being deprecated because it is confusing and redundant. As of this writing (January 2018), most units run some version of 8.4, but after 8.5 is released a special compatibility mode will need to be enabled for applications that process application.lsl format. There are also other important changes that an application developer should be aware of; for more, see: Best practices for application development.