 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
Aportable application (portable app), sometimes also calledstandalone software, is acomputer program designed to operate without changing other files or requiring other software to be installed. In this way, it can be easily added to, run, and removed from any compatible computer without setup or side-effects.[1]
In practical terms, a portable application often stores user-created data and configuration settings in the same directory it resides in. This makes it easier to transfer the program with the user's preferences and data between different computers. A program that doesn't have any configuration options can also be a portable application.[1]
Portable applications can be stored on anydata storage device, including internalmass storage, afile share,cloud storage or external storage such asUSB drives, pen drives[2] andfloppy disks—storing its program files and any configuration information and data on the storage medium alone. If no configuration information is required a portable program can be run fromread-only storage such asCD-ROMs andDVD-ROMs. Some applications are available in bothinstallable and portable versions.
Some applications which are not portable by default do support optional portability through other mechanisms, the most common beingcommand-line arguments. Examples might include/portable to simply instruct the program to behave as a portable program, or--cfg=/path/inifile to specify the configuration file location.
Like any application, portable applications must be compatible with the computer system hardware andoperating system.
Depending on the operating system,portability is more or less complex to implement; to operating systems such asAmigaOS, all applications are by definition portable.
Most portable applications do not leave files or settings on the host computer or modify the existing system and its configuration. The application may not write to theWindows registry[3] or store its configuration files (such as anINI file) in the user'sprofile, but today, many portables do; many, however, still store their configuration files in the portable directory. Another possibility, sincefile paths will often differ on changing computers due to variation indrive letter assignments, is that portable applications may store them in arelative format. While some applications have options to support this behavior, many programs are not designed to do this. A common technique for such programs is theuse of a launcher program to copy necessary settings and files to the host computer when the application starts and move them back to the application's directory when it closes.
An alternative strategy for achieving application portability within Windows, without requiring application source code changes, isapplication virtualization: An application is "sequenced" or "packaged" against a runtime layer that transparently intercepts its file system and registry calls, then redirects these to other persistent storage without the application's knowledge. This approach leaves the application itself unchanged, yet portable.
The same approach is used for individual application components:run-time libraries,COM components orActiveX, not only for the entire application.[4] As a result, when individual components are ported in such manner they are able to be: integrated into original portable applications, repeatedly instantiated (virtually installed) with different configurations/settings on the sameoperating system (OS) without mutual conflicts. As the ported components do not affect the OS-protected related entities (registry and files), the components will not require administrative privileges for installation and management.
Microsoft saw the need for an application-specific registry for its Windows operating system as far back as 2005.[5] It eventually incorporated some of this technology, using the techniques mentioned above, via its Application Compatibility Database[6] using its Detours[7] code library, into Windows XP. It did not make any of this technology available via its systemAPIs.
Programs written with a Unix-like base in mind often do not make any assumptions. Whereas many Windows programs assume the user is anadministrator—something very prevalent in the days ofWindows 95/98/ME (and to some degree inWindows XP/2000, though not inWindows Vista orWindows 7)—such would quickly result in "Permission denied" errors in Unix-like environments since users will be in an unprivileged state much more often. Programs are therefore generally designed to use theHOMEenvironment variable to store settings (e.g.$HOME/.w3m for thew3m browser). The dynamic linker provides an environment variableLD_LIBRARY_PATH that programs can use to load libraries from non-standard directories. Assuming/mnt contains the portable programs and configuration, a command line may look like:
HOME=/mnt/home/user LD_LIBRARY_PATH=/mnt/usr/lib /mnt/usr/bin/w3m www.example.com
A Linux application without need for a user-interaction (e.g. adapting a script or environment variable) on varying directory paths can be achieved with theGCCLinker option$ORIGIN which allows a relative library search path.[8]
Not all programs honor this—some completely ignore $HOME and instead do a user look-up in/etc/passwd to find the home directory, therefore thwarting portability.
There are also cross-distro package formats that do not require admin rights to run, likeAutopackage,AppImage, or CDE, but which gained only limited acceptance and support in the Linux community in the 2000s.[9][10][11] Around 2015 the idea of portable and distro independent packing for the Linux ecosystem got more traction whenLinus Torvalds discussed this topic on theDebConf 2014 and endorsed laterAppImage for hisdive log applicationSubsurface.[12][13][14] For instance,MuseScore andKrita followed in 2016 and started to use AppImage builds for software deployment.[15][16] RedHat released in 2016 theFlatpak system, which is a successor of Alexander Larsson'sglick project which was inspired by klik (now called AppImage).[17] Similarly,Canonical released in 2016Snap packages forUbuntu and many other Linux distros.
Many Mac applications that can be installed by drag-and-drop are inherently portable as Mac application bundles.[18] Examples includeMozilla Firefox,Skype andGoogle Chrome which do not require admin access and do not need to be placed into a central, restricted area. Applications placed into/Users/username/Applications (~/Applications) are registered with macOS LaunchServices in the same way as applications placed into the main/Applications folder. For example, right-clicking a file in Finder and then selecting "Open With..." will show applications available from both /Applications and ~/Applications. Developers can create Mac product installers which allow the user to perform a home directory install, labelled "Install for me only" in the Installer user interface.[19] Such an installation is performed as the user.
You can use a special keyword $ORIGIN to say 'relative to the actual location of the executable'. Suddenly we found we could use -rpath $ORIGIN/lib and it worked. The game was loading the correct libraries, and so was stable and portable, but was also now completely in the spirit of the LGPL as well as the letter!
The Linux community, in their infinite wisdom, proceeds to flame the hell out of CDE. [...] "We should all just be using package management." Here is what I want to say, and let my words be carried down from the mountaintops, written on tiny stone tablets: Package management is not a universal panacea.
If Hearn is correct, the real lesson of Autopackage is not how to improve software installation, but the difficulty -- perhaps the impossibility -- of large-scale changes in Linux architecture this late in its history. It's a sobering, disappointing conclusion to a project that once seemed so promising.
I have seen this first hand with the other project I'm involved with, which is my dive log app. We make binaries for Windows and OSX, we basically don't make binaries for Linux. Why? Because making binaries for Linux desktop applications is a major fucking pain in the ass.
I finally got around to play with the "AppImage" version of +Subsurface, and it really does seem to "just work".
I, as the app maintainer, don't want my app bundled in a distribution anymore. Way to much pain for absolutely zero gain. Whenever I get a bug report my first question is "oh, which version of which distribution? which version of which library? What set of insane patches were applied to those libraries?". No, Windows and Mac get this right. I control the libraries my app runs against. [...] With an AppImage I can give them just that. Something that runs on their computer.
