Scribd
Upload
88 views3 pages

Portable Application (Portable App), Sometimes Also Called Standalone, Is

Portable applications are programs designed to run from external storage devices like USB drives without needing to be installed. They store configuration files and data in the same folder as the application itself rather than making system-wide changes. This allows users to easily transfer programs between computers. On Windows, portable apps avoid writing to the registry or user profile and instead use relative file paths. On Linux and Unix systems, portable apps rely on environment variables and don't assume administrator privileges. Many Mac apps are also inherently portable when installed to the user's home folder.

Uploaded by

Angel Barrios
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
88 views3 pages

Portable Application (Portable App), Sometimes Also Called Standalone, Is

Portable applications are programs designed to run from external storage devices like USB drives without needing to be installed. They store configuration files and data in the same folder as the application itself rather than making system-wide changes. This allows users to easily transfer programs between computers. On Windows, portable apps avoid writing to the registry or user profile and instead use relative file paths. On Linux and Unix systems, portable apps rely on environment variables and don't assume administrator privileges. Many Mac apps are also inherently portable when installed to the user's home folder.

Uploaded by

Angel Barrios
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

A portable application (portable app), sometimes also called standalone, is

a program designed to read and write its configuration settings into an accessible folder in the
computer, usually in the folder where the portable application can be found. 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.
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 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
A portable application does not leave its files or settings on the host computer or modify the existing
system and its configuration. The application does not write to the Windows registry or store its
configuration files (such as an INI file) in the user's profile; instead, it stores its configuration files in the
portable directory. Another requirement, since file paths will often differ on changing computers due to
variation in Windows drive letter assignments, is the need for applications to store them in
a relativeformat. 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.[1] 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.[2] It eventually incorporated some of this technology, using the techniques mentioned above, via
its Application Compatibility Database [3] using its Detours [4] code library, into Windows XP. It did not
make any of this technology available via its system APIs.

Portability on Linux and Unix-like systems


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 w3mbrowser). 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.[5]
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, klik(now called AppImage), or CDE, but which gained only limited acceptance and
support in the Linux community in the 2000s.[6][7][8] 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 logapplication Subsurface.[9][10][11] For
instance, MuseScore and Krita followed in 2016 and started to use AppImage builds for software
deployment.[12][13]RedHat released in 2016 the Flatpak system, which is an successor of Alexander
Larsson's glick project which was inspired by klik (now AppImage).[14]Similarly, Canonical released in
2016 Snap packagesfor Ubuntu and many other Linux distros.
Many Mac applications that can be installed by drag-and-drop are inherently portable as Mac application
bundles[15]. Examples include Mozilla Firefox, Skypeand 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[16]. Such an installation is performed as the user.

You might also like