Jump to content

Portable application: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
m How could we forget CD-ROMs? :-)
FrescoBot (talk | contribs)
Bots
1,135,457 edits
m Bot: link syntax and minor changes
 
(537 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|Type of computer program}}
[[Image:USB flash drive.jpg|thumb|right|A USB drive, shown with a 24 mm [[Quarter (U.S. coin)|US quarter coin]] for scale.]]
{{Distinguish|software portability|portable executable|multiarchitecture binary}}
{{multiple issues|
{{clarity|date=April 2018}}
{{Original research|article|date=August 2009}}
}}
[[Image:USB flash drive.jpg|thumb|right|200px|A [[USB flash drive|USB drive]] can carry portable applications]]


A '''portable application''' ('''portable app'''), sometimes also called [[Standalone program|standalone software]], is a [[computer 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.<ref name="PortableApps.com">{{cite web | title = What is a portable app? | publisher = PortableApps.com | access-date=2022-11-15 | url = https://portableapps.com/about/what_is_a_portable_app#definition |at = Definition}}</ref>
A '''portable application''', or portable app for short, is a [[software program]] that does not require any kind of formal [[software installation|installation]] onto a computer's permanent storage device to be executed, and can be stored on a removable storage device such as a [[CD-ROM]], [[USB flash drive]], [[flash card]], or even a [[floppy disk]], enabling it to be used on multiple computers. This does not mean that it can be taken and used on a different operating system, processing platform, or another computer with completely different hardware (i.e., those that are not compatible with the software as stated by its requirements), so it is not to be confused with the concept of [[porting|software portability]], which is the ability for software to be run or compiled with little modification on diverse computing platforms. Ideally it can be configured to read its configuration from the same location as the software.


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.<ref name="PortableApps.com" />
⚫
== Portable Macintosh applications ==


Portable applications can be stored on any [[data storage device]], including internal [[mass storage]], a [[Shared resource|file share]], [[File hosting service|cloud storage]] or external storage such as [[USB flash drive|USB drives]], pen drives<ref>{{Cite web |date=2007-01-08 |title=Free Portable Apps and Games for USB ▷ Pendrive Software |url=https://pendriveapps.com/ |access-date=2024-06-17 |website=pendriveapps.com |language=en-us}}</ref> and [[floppy disk]]s—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 from [[file system permissions|read-only]] storage such as [[CD-ROM]]s and [[DVD-ROM]]s. Some applications are available in both [[Installer|installable]] and portable versions.
Many programs for the [[Apple Macintosh|Macintosh]] [[Mac OS X|OS X]] have an inherent degree of portability as they are packaged as "drag-install" [[bundle (NEXTSTEP)|application bundles]], rather than as [[Installer (Mac OS X)|Installer]] packages. However, many applications bundles are not be truly portable as they store their preferences in files on the [[local disc]] where the OS is installed. Macintosh applications in the below list (and others designed to be portable) store their preferences in the drive they are being run from.


Some applications which are not portable by default do support optional portability through other mechanisms, the most common being [[Command-line interface#Arguments|command-line arguments]]. Examples might include <code>/portable</code> to simply instruct the program to behave as a portable program, or <code>--cfg=/path/inifile</code> to specify the configuration file location.
⚫
== Double portability ==


Like any application, portable applications must be compatible with the computer system hardware and [[operating system]].
There is a very restricted category of software that can sport a sort of double portability, being both stand alone and cross-platform compatible, able to run on different hardware with little or no modifications, eventually with only minor restrictions. One such software is [[SymbOS]], whose main modules can in their present form be executed on both [[Amstrad CPC]] and [[MSX]] machines without modification. Only some of its bundled applications are hardware-dependant. To a much lesser extent, Macintosh [[fat binary]] applications could be considered as cross-platform , but not always truly portable.


Depending on the operating system, ''portability'' is more or less complex to implement; to operating systems such as [[AmigaOS]], all applications are by definition portable.
== Property, or feature? ==


⚫
== Portable Windows applications ==
For certain classes of [[software tools]] and [[utilities]], being fully portable is not only a convenient feature as much as a vital property, such as in the case of e.g. system/data recovery or diagnostic utilities, which have to be entirely stand-alone and self-sufficient when executed.


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 the [[Windows registry]]<ref>{{cite web | title = "What is a Portable App?" | publisher = PortableApps.com | access-date=2022-11-15 | url = https://portableapps.com/about/what_is_a_portable_app#guidelines |at = Guidelines}}</ref> or store its configuration files (such as an [[INI file]]) in the user's [[home directory|profile]], but today, many portables do; many, however, still store their configuration files in the portable directory. Another possibility, since [[Path (computing)|file paths]] will often differ on changing computers due to variation in [[drive letter assignment]]s, is that portable applications may store them in a [[Relative path|''relative'']] 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 the [[Comparison of desktop application launchers|use 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.
In the earlier days of home and personal computing, where software typically resided on and was executed from a single [[floppy disk]] (usually with only one program per disk) the concept of "portable application" was a property of the software itself, not something requiring specific engineering.


An alternative strategy for achieving application portability within Windows, without requiring application source code changes, is [[application 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.
While entirely portable programs can still be designed today regardless of their size or complexity (with extreme cases being the so-called [[LiveDistro|LiveDistros]] containing whole operating systems such as [[Suse Linux]]), user demand for features such as easy uninstallation and integration with other programs' menus made some kind of installation or at least "registering" with the operating system a necessity.


The same approach is used for individual application components: [[Run-time library|run-time libraries]], [[Component Object Model|COM]] components or [[ActiveX]], not only for the entire application.<ref>{{cite web|title=Portable Application Conversion Technology|url=http://sphinx-soft.com/Portable/|publisher=Sphinx Software|access-date=January 19, 2012|archive-url=https://web.archive.org/web/20100907213345/http://sphinx-soft.com/Portable/|archive-date=September 7, 2010}}</ref> 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 same [[operating 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.
Many older [[Windows 3.1]] applications, as well as some poorly designed [[MS-DOS]] ones, fell somewhere halfway between the portable and unportable category, as "installation" was usually little more than a [[file copying]] operation in a specific [[directory]] (or even a floppy disk), but certain data was implicitly stored in the user's Windows directory or another arbitrary hardcoded directory, thus rendering the user settings non-portable, or at least not readily portable with the rest of the program.


Microsoft saw the need for an application-specific registry for its Windows operating system as far back as 2005.<ref>{{cite web|title=Portable Application Registry|url=http://ip.com/patapp/US20070136241|publisher=ip.com|access-date=January 19, 2012}}</ref> It eventually incorporated some of this technology, using the techniques mentioned above, via its Application Compatibility Database<ref>{{cite web|last=Ionescu|first=Alex|title=Secrets of the Application Compatilibity Database (SDB) – Part 1|url=http://www.alex-ionescu.com/?p=39|access-date=January 19, 2012}}</ref> using its Detours<ref>{{cite web|title=Detours|url=http://research.microsoft.com/en-us/projects/detours/|publisher=Microsoft Research|access-date=January 19, 2012}}</ref> code library, into Windows XP. It did not make any of this technology available via its system [[API]]s.
⚫
==See also==
⚫
*[[List of portable software]]
*[[List of Portable Computer Games]]


== Portability on Unix-like systems ==
==External links==
{{See also|Autopackage|Zero Install}}
Programs written with a Unix-like base in mind often do not make any assumptions. Whereas many Windows programs assume the user is an [[Superuser|administrator]]—something very prevalent in the days of [[Windows 95]]/[[Windows 98|98]]/[[Windows ME|ME]] (and to some degree in [[Windows XP]]/[[Windows 2000|2000]], though not in [[Windows Vista]] or [[Windows 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 the <code>[[$HOME|HOME]]</code> [[environment variable]] to store settings (e.g. <code>''$HOME''/.w3m</code> for the [[w3m]] browser). The dynamic linker provides an environment variable <code>[[$LD_LIBRARY_PATH|LD_LIBRARY_PATH]]</code> that programs can use to load libraries from non-standard directories. Assuming <code>/mnt</code> contains the portable programs and configuration, a command line may look like:

<code>HOME=/mnt/home/user LD_LIBRARY_PATH=/mnt/usr/lib /mnt/usr/bin/w3m www.example.com</code>

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 the [[GNU Compiler Collection|GCC]] [[GNU linker|Linker]] option <code>$ORIGIN</code> which allows a relative library search path.<ref name="lgpl">{{cite web|url=http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/|archive-url=https://web.archive.org/web/20090220234542/http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/|archive-date=2009-02-20 |title= Our new way to meet the LGPL |date=2009-02-08|access-date= 2011-03-09 |first=Eskild |last= Hustvedt |quote= 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!}}</ref>

Not all programs honor this—some completely ignore $HOME and instead do a user look-up in <code>/etc/passwd</code> to find the home directory, therefore thwarting portability.

There are also cross-distro package formats that do not require admin rights to run, like [[Autopackage]], [[AppImage]], or CDE, but which gained only limited acceptance and support in the Linux community in the 2000s.<ref name=glg>{{cite web|url=http://www.gaslampgames.com/blog/2010/11/13/dear-linux-community-we-need-to-talk/|publisher=Gaslamp Games|title=Dear Linux Community: We Need To Talk. |date=2010-10-13 |first=Nicholas |last=Vining |access-date=2011-01-30 |quote=''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.''}}</ref><ref name=byfield>{{cite web|archive-url=https://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124 |url=http://www.linux.com/articles/60124|title=Autopackage struggling to gain acceptance |first=Bruce |last=Byfield |date=2007-02-12 |access-date=2012-01-21 |publisher=linux.com |archive-date=2008-03-31 |quote=''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.''}}</ref><ref>{{cite web|title=AppImages|url=http://elementary-project.com/wiki/index.php?title=AppImages|publisher=Elementary Project |access-date=January 19, 2012|archive-url=https://web.archive.org/web/20101213215610/http://elementary-project.com/wiki/index.php?title=AppImages|archive-date=December 13, 2010}}</ref> Around 2015 the idea of portable and distro independent packing for the Linux ecosystem got more traction when [[Linus Torvalds]] discussed this topic on the [[DebConf]] 2014 and endorsed later [[AppImage]] for his [[dive log]] application [[Subsurface (software)|Subsurface]].<ref name="torvalds2014">{{cite web|url=http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm |title=Q&A with Linus Torvalds |author=Linus Torvalds |author-link=Linus Torvalds |date=2014-08-29 |publisher=[[debian]].net |work=[[DebConf]] 2014 Portland |access-date=2016-05-14 |format=video |at=6:28 |quote=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.}}</ref><ref>{{cite web|url=https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS|title=This is just very cool.|last=Torvalds|first=Linus|author-link=Linus Torvalds|publisher=[[Google+]]|quote=I finally got around to play with the "AppImage" version of +Subsurface, and it really does seem to "just work".}}</ref><ref>{{cite web|url=https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS|title=This is just very cool. |last=Hohndel |first=Dirk|publisher=[[Google+]]|quote=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.|date=2015-11-25}}</ref> For instance, [[MuseScore]] and [[Krita]] followed in 2016 and started to use AppImage builds for software deployment.<ref>{{cite web|last1=Weiss|first1=Isaac|title=MuseScore 2.0.3 is released|url=https://musescore.org/en/node/104676|website=MuseScore.org|publisher=MuseScore|access-date=2016-04-05|archive-url=https://web.archive.org/web/20160423053503/https://musescore.org/en/node/104676|archive-date=2016-04-23}}</ref><ref>{{cite web|title=Krita 3.0 Released|url=https://krita.org/item/krita-3-0-released/ |website=Krita.org |publisher=Krita |date=2016-05-31}}</ref> RedHat released in 2016 the [[Flatpak]] system, which is a successor of Alexander Larsson's ''glick'' project which was inspired by klik (now called AppImage).<ref>[https://blogs.gnome.org/alexl/2007/08/07/experiments-with-runtime-less-app-bundles/ Experiments with run-timeless app bundles] by Alex Larsson (2007)</ref> Similarly, [[Canonical (company)|Canonical]] released in 2016 [[Snappy (package manager)|Snap packages]] for [[Ubuntu (operating system)|Ubuntu]] and many other Linux distros.

Many Mac applications that can be installed by drag-and-drop are inherently portable as Mac application bundles.<ref>{{cite web | title = Distributing Your Application | publisher = developer.apple.com | access-date=2017-05-23 | url = https://developer.apple.com/library/content/documentation/Porting/Conceptual/PortingUnix/distributing/distibuting.html}}</ref> Examples include [[Mozilla Firefox]], [[Skype]] and [[Google Chrome]] which do not require admin access and do not need to be placed into a central, restricted area. Applications placed into <code>/Users/username/Applications</code> (<code>~/Applications</code>) are registered with macOS LaunchServices in the same way as applications placed into the main <code>/Applications</code> 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.<ref>{{cite web | title = Distribution XML Reference | publisher = developer.apple.com | access-date=2017-05-23 | url = https://developer.apple.com/library/content/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW35}}</ref> Such an installation is performed as the user.

⚫
==See also==
* [[Load drive]]
⚫
* [[List of portable software]]
** [[WinPenPack]]
* [[Portable application creators]]
** [[LiberKey]]
** [[PortableApps.com]]
** [[U3 (software)|U3]]
* [[Application virtualization]]
** [[Turbo (software)]]
** [[VMware ThinApp]]
* [[Live USB]]
** [[Ceedo]]
** [[Portable-VirtualBox]]
** [[Windows To Go]]
⚫
* [[Data portability]]
* [[Interoperability]]


==References==
* [http://portablefdm.net/ PortableFDM.net] - Lo Mejor en Software Portable !
{{Reflist}}
* [http://portableapps.com/ PortableApps.com] - Collection of [[Microsoft Windows]] portable applications, well known for its applications
* [http://www.usbspace.com/ USBSpace.com] - Portable software for [[USB flash drive]]s
* [http://www.freesmug.org/portableapps/ OS X PortableApps] - Collection of [[Mac OS X]] portable applications
* [http://www.winpenpack.com/ winPenPack] - Italian site. Collection of portable software
* [http://www.tinyapps.org/ TinyApps] - Specializes in small applications. Portable applications are marked with a "+"
* [http://www.portablefreeware.com/ Portable Freeware] - Also lists applications that are not portable, but can be made portable.
* [http://www.no-install.com/ No-Install] - Collection of USB applications and USB news
* [http://www.theinfobox.com/index.php/Portable_USB_Apps Portable Apps Collection] - Collection of portable applications
* [http://standalone.atspace.org/ StandAlone] - Portable applications for [[USB flash drive]]s
* [http://www.kikizas.net/en/usbapps.html kikizas.net] - Freeware programs to run from a [[USB flash drive]]
* [http://www.apponkey.com/ AppOnKey.com] - Portable environment
* [http://www.framakey.org/ FramaKey] - Collection of packaged or standalone applications
* [http://www.bureaudepoche.com/ Bureau de Poche] - French site. Collection of packaged applications
* [http://www.bureaudepoche.com/english_version/ Bureau de Poche EN] - English version - [http://www.bureaudepoche.com/spanish_version/ Bureau de Poche ES] - Spanish version
* [http://www.stickydrive.com/ StickyDrive] - Portable Environment
* [http://www.app-stick.com/index.php AppStick.com] - Collection of Freeware portable applications
* [http://www.shorttext.com/215t Installing SLAX compilation to a USB flash drive in Windows]
* [http://www.portable-apps.subiectiv.com Portable apps] - Portable applications for [[USB flash drive]]s
* [http://klik.atekon.de klik] - Portable applications for [[Linux]]
⚫
[[Category:Application software]]


⚫
[[Category:Portable software| ]]
[[id:Aplikasi portabel]]

Latest revision as of 03:19, 19 August 2024

Not to be confused with software portability, portable executable, or multiarchitecture binary.
A USB drive can carry portable applications

A portable application (portable app), sometimes also called standalone software, is a computer 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 any data storage device, including internal mass storage, a file share, cloud storage or external storage such as USB drives, pen drives[2] and floppy 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 from read-only storage such as CD-ROMs and DVD-ROMs. Some applications are available in both installable and portable versions.

Some applications which are not portable by default do support optional portability through other mechanisms, the most common being command-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 and operating system.

Depending on the operating system, portability is more or less complex to implement; to operating systems such as AmigaOS, all applications are by definition portable.

Portable Windows applications

[edit]

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 the Windows registry[3] or store its configuration files (such as an INI file) in the user's profile, but today, many portables do; many, however, still store their configuration files in the portable directory. Another possibility, since file paths will often differ on changing computers due to variation in drive letter assignments, is that portable applications may store them in a relative 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 the use 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, is application 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 or ActiveX, 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 same operating 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 system APIs.

Portability on Unix-like systems

[edit]
See also: Autopackage and Zero Install

Programs written with a Unix-like base in mind often do not make any assumptions. Whereas many Windows programs assume the user is an administrator—something very prevalent in the days of Windows 95/98/ME (and to some degree in Windows XP/2000, though not in Windows Vista or Windows 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 the HOME environment variable to store settings (e.g. $HOME/.w3m for the w3m browser). The dynamic linker provides an environment variable LD_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 the GCC Linker 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, like Autopackage, 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 when Linus Torvalds discussed this topic on the DebConf 2014 and endorsed later AppImage for his dive log application Subsurface.[12][13][14] For instance, MuseScore and Krita followed in 2016 and started to use AppImage builds for software deployment.[15][16] RedHat released in 2016 the Flatpak system, which is a successor of Alexander Larsson's glick project which was inspired by klik (now called AppImage).[17] Similarly, Canonical released in 2016 Snap packages for Ubuntu 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 include Mozilla Firefox, Skype and Google 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.

See also

[edit]

References

[edit]
  1. ^ a b "What is a portable app?". PortableApps.com. Definition. Retrieved 2022-11-15.
  2. ^ "Free Portable Apps and Games for USB ▷ Pendrive Software". pendriveapps.com. 2007-01-08. Retrieved 2024-06-17.
  3. ^ ""What is a Portable App?"". PortableApps.com. Guidelines. Retrieved 2022-11-15.
  4. ^ "Portable Application Conversion Technology". Sphinx Software. Archived from the original on September 7, 2010. Retrieved January 19, 2012.
  5. ^ "Portable Application Registry". ip.com. Retrieved January 19, 2012.
  6. ^ Ionescu, Alex. "Secrets of the Application Compatilibity Database (SDB) – Part 1". Retrieved January 19, 2012.
  7. ^ "Detours". Microsoft Research. Retrieved January 19, 2012.
  8. ^ Hustvedt, Eskild (2009-02-08). "Our new way to meet the LGPL". Archived from the original on 2009-02-20. Retrieved 2011-03-09. 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!
  9. ^ Vining, Nicholas (2010-10-13). "Dear Linux Community: We Need To Talk". Gaslamp Games. Retrieved 2011-01-30. 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.
  10. ^ Byfield, Bruce (2007-02-12). "Autopackage struggling to gain acceptance". linux.com. Archived from the original on 2008-03-31. Retrieved 2012-01-21. 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.
  11. ^ "AppImages". Elementary Project. Archived from the original on December 13, 2010. Retrieved January 19, 2012.
  12. ^ Linus Torvalds (2014-08-29). "Q&A with Linus Torvalds" (video). DebConf 2014 Portland. debian.net. 6:28. Retrieved 2016-05-14. 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.
  13. ^ Torvalds, Linus. "This is just very cool". Google+. I finally got around to play with the "AppImage" version of +Subsurface, and it really does seem to "just work".
  14. ^ Hohndel, Dirk (2015-11-25). "This is just very cool". Google+. 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.
  15. ^ Weiss, Isaac. "MuseScore 2.0.3 is released". MuseScore.org. MuseScore. Archived from the original on 2016-04-23. Retrieved 2016-04-05.
  16. ^ "Krita 3.0 Released". Krita.org. Krita. 2016-05-31.
  17. ^ Experiments with run-timeless app bundles by Alex Larsson (2007)
  18. ^ "Distributing Your Application". developer.apple.com. Retrieved 2017-05-23.
  19. ^ "Distribution XML Reference". developer.apple.com. Retrieved 2017-05-23.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Portable_application&oldid=1241063253"