Standalone software
From Wikipedia, the free encyclopedia
| This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2008) |
| This article may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (June 2008) |
A standalone program is any program that is run in a standalone PC. It may be an application program or any system program. However this distinction does not stand up to scrutiny outside the context of certain embedded systems, since the computer usually has to be running some program that prepares (and sometimes initially processes) the "stand-alone" program to begin with (e.g. .NET Framework). Hence all programs are launched or prepared/processed by other programs (with the sole exception of the bootstrap loader), and no code can really be said to stand alone.
If "stand-alone" is more widely defined as a program not needing the services of other programs (except maybe firmware) once it is running, then most operating systems can also justifiably be called "stand-alone", since they need the bootstrap loader only for starting up. Normal applications are called "hosted applications" in contrast.
In some embedded systems, the one and only application that they run is truly stand-alone, in the sense that it includes all the code that's ever going to be seen by the CPU of those systems. This kind of application has to contain its own (possibly very basic) operating system.
A distinction might be drawn between programs that run as operating system processes and those that are loaded as an add-on in the context of an existing process, e.g. a plugin. This distinction may make some sense, but the term "stand-alone" has been used inconsistently: for instance, on the Macintosh platform, the plugin code has often been referred to as being stand-alone.
A less ambiguous terminology refers to application and non-application code, since "application" seems to be a commonly-accepted cross-platform term for a program that runs as a separate process and is invoked as a direct result of some user action. The "non-application" code then has to be loaded and run as part of the process context of the "application" code, and there is no ambiguity about which is which.

