imported>Trustable: Kleinigkeiten verbessert

2026-04-06T00:09:29Z

Kleinigkeiten verbessert

Neue Seite

'''Portable Software''' (über [[Französische Sprache|französisch]] ''{{lang|fr|portable}}''<ref>[https://www.duden.de/rechtschreibung/portabel portabel] – ''[[Duden]]'', ''[[Bibliographisches Institut]]''; 2016</ref> aus {{laS|portare}} ‚[mit sich] tragen‘), auch '''Standalone-Software''' oder [[USB-Stick|('''USB-''')'''Stick''']]'''-Ware''' genannt, ist [[Software]], typischerweise [[Anwendungssoftware]], die ohne weitere Anpassungen oder Einrichtung (''[[Installation (Software)|Installationen]]'') auf verschiedenen [[Computer|Rechnern]] läuft. Sie kann zum Beispiel auf einen [[Wechseldatenträger]] übertragen (oder ''kopiert'') und von dort aus auf jedem (kompatiblen) Rechner ausgeführt werden, ohne sie auf diesem zu installieren.

== Motivation und Nutzen ==
Bestimmte Programme, aber auch deren Einstellungen und persönliche Daten möchten viele Nutzer an verschiedenen Computern zur Verfügung haben. Mit Hilfe portabler Software können diese auf einen [[USB-Stick]] (oder einen anderen [[Wechseldatenträger]]) kopiert werden, so dass der Benutzer nur diesen Stick einstecken muss, um Zugriff auf seine Programme und Einstellungen zu haben.

Da portable Software keine Spuren auf dem Wirtscomputer hinterlässt und keine Installation braucht, kann man sie auch auf Computern nutzen, auf denen diese Software nicht vorhanden ist, obwohl man keine [[Administrator (Rolle)|Administrator-Rechte]] oder auch keine Schreibrechte auf einem System-Datenträger hat.

== Definition und Abgrenzung ==
Wozu eine Portable Software als „portabel“ bzw. „unabhängig“ angenommen wird, variiert etwas: Teilweise wird die Unabhängigkeit innerhalb einer (Betriebs)system-Installation gemeint (d. h. die Anwendungsprogramme können also ohne Verlust der Funktionalität im [[Verzeichnisbaum]] verschoben werden), manchmal wird damit die Unabhängigkeit von einem spezifischen Hardwaresystem gemeint (d. h., die Software ist auch auf anderen aber [[Kompatibilität (Technik)|kompatiblen]] physikalischen Rechnersystemen voll funktionsfähig). Die Unabhängigkeit spezifischer [[Betriebssystem]]-Familien, normalerweise als [[Plattformunabhängigkeit]] bezeichnet, ist nicht gemeint, wenn von Portabler Software gesprochen wird, da das eine Qualität ist, die typischerweise über die Nutzungsszenarien von Portabler Software hinausgeht.

Für den häufigsten Nutzungsfall Anwendungsprogramme kann Portable Software auch als Variante einer ''[[Anwendungsvirtualisierung]]'' verstanden werden. Mit einer weitergehenden ''[[Virtuelle Maschine|Systemvirtualisierung]]'' können zwar ebenfalls portable Eigenschaften erzielt werden, jedoch mit zusätzlichem Aufwand und weiteren Nachteilen (Dateigröße, Leistungsfähigkeit, schlechtere [[User Experience|UX]]/[[GUI]] Integration).

== Eigenschaften ==
Prinzipiell interagiert Portable Software nur wenig mit dem Betriebssystem bzw. ist nicht (oder nur schwach) in dieses integriert. Es hängt dementsprechend nur von einigen wenigen Eigenschaften des spezifischen Betriebssystems und des (physischen) Computersystems ab.

=== Keine Installation notwendig ===
Typischerweise braucht Portable Software keine [[Installation (Software)|Installation]] und kann direkt vom [[Datenspeicher|Trägermedium]] aus verwendet werden. Manchmal wird sie auch durch Kopieren in ein (beliebiges) Wirtsrechner-Verzeichnis gebrauchsfertig gemacht. Meist kann die gebrauchsfertige Software auch nach Benutzung durch einfaches Kopieren dupliziert werden, was für eine einfache [[Datensicherung]] auf einem weiteren Datenträger sowie ein einfaches Weitergeben der Software vorteilhaft ist. Portable Software wird häufig als gepacktes [[Packprogramm|Archiv]] verbreitet, welches nur in ein Verzeichnis entpackt werden muss, ohne dass systemspezifische [[Installationsprogramm]]e benötigt werden. Dieses einfache Auspacken wird zum Teil irreführend auch als ''Installieren'' bezeichnet, obwohl keine tiefere Integration in das Wirtssystem stattfindet.

Wird eine portable Software doch „installiert“, geht es dabei um die Einrichtung unter sehr nicht-restriktiven Bedingungen, d. h., der Ablageort kann frei gewählt werden, die vorausgesetzten Systembibliotheken sind minimiert und spezielle Nutzerrechte (Admin oder Root) sind nicht notwendig usw.<ref name="klik2" /><ref name="zero" />

=== Keine Spuren auf dem Wirtssystem ===
Im Idealfall hinterlässt portable Software keine Spuren auf dem Wirtssystem.
Spuren können einerseits Installationseinträge jeglicher Art (zum Beispiel in der [[Registrierungsdatenbank]], im [[Benutzerprofil]] oder Ähnliches) oder aber Benutzerdaten sein, die nicht auf einem fremden Rechner zurückbleiben sollten.

=== Funktion mit eingeschränkten Rechten ===
Auf dem Wirtssystem hat man häufig keine [[Administrator (Rolle)|Administratorrechte]]. Die Software soll daher auch mit eingeschränkten Rechten lauffähig sein. Somit kann sie bei ordentlicher Konfiguration des Wirtssystems auch keinen übermäßigen Schaden anrichten.

Das ist allerdings nicht möglich, wenn das Programm direkten Zugriff auf die Hardware oder gewisse Systemkomponenten braucht. So benötigen z. B. die Verschlüsselungsprogramme [[FreeOTFE]] oder [[TrueCrypt]] selbst im „Portable Mode“ bzw. „Traveller Mode“, zum Ver- bzw. Entschlüsseln des Wechseldatenträgers Administratorrechte.

== Entwicklung portabler Programme ==
Oft sind portable Programme angepasste Versionen von konventionellen installationsbedürftigen Programmen. Um sie von diesen zu unterscheiden, wird oft das [[Prädikat (Qualität)|Prädikat]] „portable“ vorangestellt. Es gibt auch Programme, die beispielsweise bezüglich der Schreibzugriffe auf die Verhältnisse der speziellen Datenträger (meist [[Flash-Speicher]]) zugeschnitten sind.
Eine Sonderform ist [[U3 (Standard für portable Software)|U3]]-Software, die nur von einem mit der [[proprietär]]en U3-Software verträglichen USB-Stick ausgeführt werden kann.

Jedoch kann nicht von jedem Programm eine portable Version erstellt werden.

== Grenzen portabler Programme ==
=== Hardwareplattform-Abhängigkeit ===
Anwendungen, welche in einem [[Binärdatei|Binärformat]] (z. B. [[Executable and Linking Format|ELF]] oder [[Portable Executable|PE]]) vorliegen, wurden von einem [[Compiler]] für eine spezifische [[Plattform (Computer)#Hardwareplattform|Hardwareplattform]] generiert (z. B. [[IA-32]]). Verschiedene [[Hauptprozessor#Verschiedene Architekturen|CPU-Architekturen]] variieren in [[Befehlssatzarchitektur|Befehlssatz]], [[Datenwort]]größe (z. B. 32-Bit oder 64-Bit) oder [[Byte-Reihenfolge|Byte-order]]. Das beschränkt den portablen Einsatz auf Plattformen der gleichen Hardware. Ein portabler Ansatz zur Umgehung dieser Problematik sind sogenannte [[Fat Binary|Fat Binaries]], die Varianten für mehrere Hardwareplattformen enthalten. Beispielsweise setzt [[Apple]] seit 2006 Fat Binaries ein, hier [[Universal Binaries]] genannt, um den problemarmen Übergang von den PowerPC-CPUs zu den Intel-CPUs zu ermöglichen.<ref name="Universal Binary">{{Internetquelle| autor=Apple Computer| titel="Universal Binaries and 32-bit/64-bit PowerPC Binaries" in der Mac OS X ABI Mach-O File Format Referenz| datum=2006-03-08 | url=http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-154889| abruf=2006-07-13}}</ref>

=== Systemnahe Software ===
Nicht alle Programme eignen sich zur Verwendung als portable Software. Beispielsweise benötigen Virenwächter, Systemwerkzeuge und andere systemnahe Software die Möglichkeit, tief ins System einzugreifen. Deren portable Versionen haben eine geringere Bedeutung, weil sie in der Regel nicht den gleichen Funktionsumfang wie installierte Software aufweisen können.

Allgemeine Anwendungsprogramme, zum Beispiel Text-Editoren und E-Mail-Clients, kommen hingegen meist ohne Systemeingriffe aus und eignen sich für den portablen Einsatz. So ist zum Beispiel das Office-Paket [[LibreOffice]] in einer portablen Version verfügbar.

=== Rechtliche Probleme ===
Neben den technischen Aspekten spielen beim Einsatz als portable Software auch die [[Endbenutzer-Lizenzvertrag|Software-Lizenz]] und etwaige [[Kopierschutz]]-Mechanismen eine Rolle. Häufig ist das Kopieren von Software vom Hersteller oder Lizenzgeber unerwünscht und wird in der Lizenzvereinbarung verboten. Ein Kopierschutz bindet ein Programm oft an ein bestimmtes System – das Binden an einen mobilen Datenträger ist technisch aufwändig und in der Regel nicht vorgesehen. Daher spielt hier [[freie Software]] eine entscheidende Rolle, weil sie dem Benutzer das Recht auf eine unbeschränkte Benutzung – auch als portable Software – zusichert. Jedoch verhindert die freie, aber strenge [[GNU General Public License|GPL]]-Lizenz manchmal das [[Statisches Binden#Statisches Linken|statische Einlinken]] von Bibliotheksabhängigkeiten, um portable Programme zu erzeugen. Die GPL, unter der viele Bibliotheken stehen, schließt dieses aus, wenn das Programm selbst einer weniger restriktiven oder proprietären Lizenz unterliegt.<ref name="lgp" />

=== Sicherheit im Unternehmen ===
IT-Verantwortliche sind für die Konfiguration und Sicherheit der Systeme im Unternehmensnetzwerk verantwortlich. [[Wechseldatenträger]] und die darauf enthaltenen Daten und Programme entziehen sich jedoch deren Kontrolle und stellen ein Risiko dar. Vorbeugend ist es teilweise üblich, [[Universal Serial Bus|USB]]-Anschlüsse im [[BIOS]] oder im [[Betriebssystem]] des Rechners zu sperren oder das Ausführen von Programmen von externen Medien zu unterbinden.

=== Betriebssysteme und Portabilität ===
==== Windows-Software ====
Windows mit seinen [[MS-DOS]]-Wurzeln besitzt keinen fixen Standard oder eine feste Übereinkunft über den Installationspfad von Programmen; der Anwender wird bei Installationen praktisch immer zu einem Zielpfad befragt. Dadurch sind variierende Ausführungspfade von Programmen häufig kein Problem, sowohl auf Betriebssystem- wie auch auf Anwendungseite, im Gegensatz zu unixoiden Betriebssystemen<ref name="gobolinux">{{Internetquelle| url = http://www.kuro5hin.org/story/2003/5/9/05015/62649| titel = The Unix tree rethought: an introduction to GoboLinux| abruf = 2011-12-19| hrsg = www.kuro5hin.org| autor=Hisham Muhammad| datum=2003-05-09|zitat=''Unfortunately, not all programs have the flexibility to be installed anywhere. Occasionally, hardcoded paths creep in, even in programs that belong in userland (which should, at least theoretically, allow themselves to be installed inside a user's home directory).''}}</ref>, bei denen sich [[Filesystem Hierarchy Standard|Standardorte]] durchgesetzt haben. Die der Portabilität dienliche Ausführbarkeit von Programmen aus beliebigen (Installations)verzeichnissen heraus (siehe<ref name="sharedlibpolicy" /> Zeile 9) mit eigenen lokalen [[Programmbibliothek#Dynamische Bibliotheken|Bibliotheken]] (''Private DLLs''<ref name="endofdllhell">{{Internetquelle| url=http://msdn.microsoft.com/library/techart/dlldanger1.htm| titel=The End of DLL Hell| datum=2000-01-11| archiv-url=https://web.archive.org/web/20010605023737/http://msdn.microsoft.com/library/techart/dlldanger1.htm| archiv-datum=2001-06-05| autor=Rick Anderson| hrsg=microsoft.com| abruf=2012-01-15| zitat=''Private DLLs are DLLs that are installed with a specific application and used only by that application.''}}</ref>) ist etwas, das Windows seinem MS-DOS-Ursprung verdankt; die meisten [[Disk Operating System|DOS]]-Programme sind portabel, und nur wenige benötigen spezielle [[TSR-Programm]]e, welche beim Systemstart geladen werden müssen.

Auch kommt dem Erstellen portabler Software für Windows zugute, dass [[Kompatibilität (Technik)|Abwärtskompatibilität]] für diese [[Plattform (Computer)|Software-Plattform]] eine hohe Priorität hat (stabile Funktionsschnittstellen, Verzeichnisstruktur etc.), es wird also viel Aufwand betrieben, um die Ausführbarkeit binärer Programme über eine breite Palette an Windowsversionen und deren Updates zu gewährleisten.<ref name="murdock">{{Internetquelle |url=http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |autor=[[Ian Murdock]] |titel=On the importance of backward compatibility |datum=2007-01-17 |abruf=2012-01-04 |sprache=englisch |archiv-url=https://web.archive.org/web/20120114153717/http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |archiv-datum=2012-01-14 }}</ref>

Jedoch ist die empfohlene Verwendung der zentralen [[Registrierungsdatenbank]] seit [[Microsoft Windows 95|Windows 95]] anstelle lokaler [[Initialisierungsdatei|INI-Dateien]] ein Hindernis für Portabilität unter Windows.<ref>http://support.microsoft.com/kb/256986 Beschreibung der Microsoft-Windows-Registrierung (3. Dezember 2007)</ref> Speichern Programme ihre Konfigurationsdaten in der Registry, können diese nicht ohne weiteres zwischen verschiedenen Rechnern kopiert werden, und oft ist auch nicht dokumentiert, in welchem Teil dieser Datenbank ein Programm seine Einstellungen ablegt, damit man [[Registrierungsdatei]]en nutzen könnte. Eine verstreute Speicherung von Programmdaten in mehreren Systemverzeichnissen (Profil, Persönliche Einstellungen, Persönliche Lesezeichen etc.) im Rahmen der [[Mehrbenutzersystem|Multiuserverwaltung]] verkompliziert die Portabilität ebenfalls. Seit Windows Vista können Programme zudem im Standard-Programme-Ordner nicht mehr ohne Weiteres schreiben ([[Benutzerkontensteuerung]]), weshalb sie ihre Einstellungen seither in aller Regel in Unterordnern der [[Umgebungsvariable]] <code>%APPDATA%</code> (Anwendungsdaten) oder [[Registrierungsdatenbank#Hauptschlüssel|HKCU\Software]] ablegen, was sie gleichzeitig multiuserfähig macht. Software, die ursprünglich nicht aus der Windows-Welt stammt, nutzt meist einen mit einem Punkt beginnenden Ordner direkt im Profilverzeichnis. Die Verwendung als (im Normalfall nicht multiuserfähige) portable Software müssen die Programme dann allerdings explizit unterstützen, indem sie es erlauben, Einstellungen in einem [[relativer Pfad|Pfad relativ]] zur Anwendungsdatei abzulegen. Einige Programme, insbesondere wenn sie ansonsten portabel sind, fragen den Benutzer bei der Installation oder beim ersten Start, welche Art der Speicherung ihrer Konfiguration er bevorzugt: in der Registrierungsdatenbank, als Dateien in <code>%APPDATA%</code> oder als Dateien im Installationsverzeichnis. Mit letzterer Option wird das Programm zu portabler Software.

==== Linux-Software ====
Unter [[Linux]] werden Programme typischerweise tief ins [[Betriebssystem]] integriert, d. h. mit diesem zusammen kompiliert und ausgeliefert ([[Linux-Distribution]]). Diese schwache Differenzierung<ref name="tonymobilyinstallation" /><ref name="smedberg">{{Internetquelle|url=http://benjamin.smedbergs.us/blog/2006-10-04/is-ubuntu-an-operating-system/ |titel=Is Ubuntu an Operating System?|zitat=''Ubuntu isn’t trying to be a platform for mass-market application software: it is trying to be the primary provider of both the operating system and all the application software that a typical user would want to run on his machine. Most Linux distributions are like this, and I think it is a dangerous trend that will stifle innovation and usability, or even worse make the desktop irrelevant.'' |autor=Benjamin Smedberg |sprache=englisch |datum=2006-10-04 |abruf=2012-01-20}}</ref> zwischen Anwendungen und Betriebssystem und damit nur schwach ausgeprägtes binäres und stabiles [[Plattform (Computer)|Plattformkonzept]]<ref name="lgplibs">{{Internetquelle|url=http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/| autor=Michael Simms|datum=2009-08-18 |abruf=2012-01-15| sprache=englisch |titel=Handling misbehaving libraries in binary products |zitat=''It is a bit of an arcane artform, making a game that runs on all Linux versions. […] [libraries] will load their own dependencies in a way we cannot control. The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn’t work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world.''|hrsg=[[Linux Game Publishing]] |archiv-url=https://web.archive.org/web/20140222145251/http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/|archiv-datum=2014-02-22}}</ref><ref name="keller">{{Internetquelle|archiv-url=https://web.archive.org/web/20081123005829/http://www.upl.cs.wisc.edu/~psilord/blog/3.html|url=http://www.upl.cs.wisc.edu/~psilord/blog/3.html |zitat=''Don't break APIs and behavior across revisions of dynamic libraries. Yes, this means YOU Linux. This is one of the single greatest causes of portability failures. Just Stop Doing It.'' |autor=Peter Keller |archiv-datum=2008-11-23 |datum=2005-05-24|abruf=2012-01-12|sprache=englisch|titel=The Road to Hell Is Paved with Good Intentions}}</ref><ref name="douthitt">{{Internetquelle |url=http://administratosphere.wordpress.com/2011/07/20/why-doesnt-my-binsh-script-run-under-ubuntu/ |autor=David Douthitt |hrsg=administratosphere.wordpress.com |titel=Why doesn’t my /bin/sh script run under Ubuntu? |datum=2011-07-20 |abruf=2012-01-10 |sprache=englisch |zitat=''In Ubuntu 6.10 […] the decision was made to replace the Bourne Again Shell (bash) with the Debian Almquist Shell (or dash) as /bin/sh in Ubuntu. There was considerable uproar […] as using dash instead of the original bash caused numerous scripts to break. […] If the focus of Ubuntu were to provide a stable and unchanging environment, then their decisions would be different – and would result in an improved customer experience.''}}</ref><ref name="jones" /><ref name="linuxfordevices">{{Internetquelle |url=http://archive.linuxgizmos.com/lsb-40-certifications-aim-to-heal-linux-fragmentation/ |titel=LSB 4.0 certifications aim to heal Linux fragmentation |autor=Eric Brown |datum=2010-12-08 |abruf=2011-11-16 |sprache=englisch |hrsg=linuxfordevices.com |zitat=''[…] LSB helps to reduce fragmentation, it does not eliminate it. "The issue of packaging and broader dependencies is still a big one (for me) at least," writes Kerner. "The same RPM that I get for Fedora won't work on Ubuntu, and Ubuntu DEB packages won't work on SUSE etc etc."[…]'' |archiv-url=https://web.archive.org/web/20131224204224/http://archive.linuxgizmos.com/lsb-40-certifications-aim-to-heal-linux-fragmentation/ |archiv-datum=2013-12-24 }}</ref>, erschwert die Erstellung portabler Anwendungen deutlich.<ref name="portableapps" /> Dazu gehört die im Allgemeinen strikte, systemweite<ref name="tonymobilyinstallation" /> Verwaltung von Anwendungen und Programmbibliotheken per [[Paketverwaltung]], die Portabilität erschweren. Nach einer Analyse des [[AppImage#klik|klik]]-Projekts über die verschiedenen Paketverwaltungssysteme unter Linux fehlen den am häufigsten genutzten Systemen [[RPM Package Manager|RPM]] und [[Advanced Packaging Tool|APT]] wichtige Fähigkeiten, um portable Installationen zu ermöglichen. Zu den fehlenden Eigenschaften gehören die Installierbarkeit ohne Root-Rechte ('Non-root package installation'), die Unmöglichkeit, das System oder andere Applikationen zu beschädigen ('Impossible to mess base system', 'Impossible to mess other apps') und die Möglichkeit, mehrere Versionen einer Anwendung zu installieren ('Multiple versions coexist').<ref name="klik2">{{Internetquelle |titel=Comparison table |url=http://klik.atekon.de/wiki/index.php/Comparison |hrsg=klik.atekon.de |datum=2009-01-29 |abruf=2010-03-26 |sprache=englisch |autor=Simon Peter |archiv-url=https://web.archive.org/web/20151223201154/http://klik.atekon.de/wiki/index.php/Comparison |archiv-datum=2015-12-23 |offline=yes |archiv-bot=2019-05-08 00:04:06 InternetArchiveBot }}</ref><ref name="portableapps" />

Auch das Umplatzieren (Relocation) von Anwendungsprogrammen zwischen verschiedenen Verzeichnissen ist in Linux nicht vorgesehen, Pfade werden typischerweise zur [[Compilezeit]] in der Anwendung hart-codiert.<ref>{{Internetquelle|archiv-url=https://web.archive.org/web/20090125113506/http://autopackage.org/docs/binreloc/|url=http://autopackage.org/docs/binreloc/|archiv-datum=2009-01-25 |abruf=2012-01-26| autor=Mike Hearn |sprache=englisch|hrsg=autopackage.org|zitat=''However, most applications are not relocatable. The paths where in they search for data files are usually hardd at compile time. On Win32, applications and libraries are easily relocatable because applications and DLLs can use GetModuleFilename() to obtain their full path.''|titel=Guide to Making Relocatable Applications (BinReloc 2.0)}}</ref> Die zum [[Autopackage]] gehörende Bibliothek ''binreloc'' bietet eine Funktionalität vergleichbar der Win32-API-Funktion <code>GetModuleFilename()</code>, wodurch Verzeichnis-relokierbare Anwendungen und Bibliotheken möglich werden.

Auch können die Unterschiede der Linux-Distributionen untereinander, also die Variationen in [[Filesystem Hierarchy Standard|Verzeichnisbaumstruktur]] und den mitgelieferten Bibliotheken, ein problemfreies, portables Ausführen einer binären Programmdatei verhindern.<ref name="troy" /> Der Entwicklungsansatz, distributionsübergreifende und portable Anwendungen über ein vollständiges [[Statisches Binden#Statisches Linken|statisches Linken]] der Bibliotheksabhängigkeiten zu erzeugen, ist technisch schwierig zu realisieren<ref name="jones" /><ref name="baus">{{Internetquelle|url=http://www.baus.net/statically-linking-libstdc++|archiv-url=https://web.archive.org/web/20100210063024/http://www.baus.net/statically-linking-libstdc++|archiv-datum=2010-02-10|datum=2005-05-31 |titel=Yet another Unix nightmare: statically linking libstdc++ |autor=Christoph Baus|sprache=englisch| abruf=2012-01-15}}</ref>, kann auch durch Lizenzkonflikte verhindert werden und wird u. a. aufgrund des Unterlaufens von Distributorinfrastruktur und -updates in der Linux-Community nicht gerne gesehen.<ref name="drepper">{{Internetquelle|url=http://people.redhat.com/drepper/no_static_linking.html|archiv-url=https://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html|archiv-datum=2010-05-27 |titel=Static Linking Considered Harmful |autor=[[Ulrich Drepper]] |zitat=''There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]''|hrsg=[[Red Hat Linux|redhat.com]]|sprache=englisch |abruf=2012-01-13}}</ref>

Programmiertechnisch lassen sich portablere Programme auch mit ''privaten Bibliotheken''<ref name="endofdllhell" /> über einen relativen Bibliothekspfad mit der [[Linker (Computerprogramm)|Linker]]-Option ''<code>$ORIGIN</code>'' erzeugen.<ref name="lgp">{{Internetquelle|url=http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/|titel=Our new way to meet the LGPL|datum=2009-02-08|abruf=2011-03-09 |autor=Eskild Hustvedt |zitat=''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!'' |sprache=englisch |archiv-url=https://web.archive.org/web/20140413195014/http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/ |archiv-datum=2014-04-13}}</ref> Vorteile dieses Ansatzes sind, dass keine Benutzeranpassungen der Bibliothekspfade oder andere Skripte nötig sind (im Gegensatz zu <code>LD_LIBRARY_PATH</code>-Ansätzen<ref name="lgp" />) und gleichzeitig die meisten Nachteile des statischen Linkens vermieden werden.

Es existieren einige Ansätze für Installationssysteme, die portablere und distributionsunabhängige Applikationen erlauben, wie [[AppImage]] (Klik-Nachfolger), [[Flatpak]], [[Autopackage]], RUNZ, [[Zero Install]] und CDE<ref name="CDE">{{Internetquelle|url=http://linux.slashdot.org/story/10/11/13/0029203/cde-making-linux-portability-easy |titel=CDE — Making Linux Portability Easy |datum=2010-11-12|autor=timothy|zitat=''A Stanford researcher, Philip Guo, has developed a tool called CDE to automatically package up a Linux program and all its dependencies (including system-level libraries, fonts, etc!) so that it can be run out of the box on another Linux machine without a lot of complicated work setting up libraries and program versions or dealing with dependency version hell.'' |hrsg=[[Slashdot]] |abruf=2012-01-21|sprache=englisch}}</ref>. Jedoch folgt jedes dieser Systeme einem anderen Ansatz und deckt damit einen anderen Teilaspekt der Portabilität ab<ref name="zero">{{Internetquelle |titel=Zero Install: Comparison with other systems |url=http://0install.net/matrix.html |hrsg=0install.net/ |datum=2010-01-01 |abruf=2010-03-26 |sprache=englisch |autor=Thomas Leonard}}</ref>. Außerdem finden diese Lösungen bis jetzt nur begrenzte Verbreitung und Unterstützung in der Linux-Community, u. a. wegen verbreiteter Bedenken gegen Nicht-Paketmanagement-basierte Lösungen.<ref name="glg">{{Internetquelle|url=http://www.gaslampgames.com/blog/2010/11/13/dear-linux-community-we-need-to-talk/ |hrsg=Gaslamp Games |titel=Dear Linux Community: We Need To Talk. |datum=2010-10-13 |autor=Nicholas Vining |sprache=englisch |abruf=2011-01-30|zitat=''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">{{Internetquelle|archiv-url=https://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124 |url=http://www.linux.com/articles/60124|titel=Autopackage struggling to gain acceptance |autor=Bruce Byfield|datum=2007-02-12 |abruf=2012-01-21|hrsg=linux.com |archiv-datum=2008-03-31|sprache=englisch|zitat=''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>{{Internetquelle|url=http://www.licquia.org/archives/2005/03/27/autopackage-considered-harmful/|titel=Autopackage Considered Harmful| autor=Jeff Licquia|datum=2005-03-27 |hrsg=licquia.org|abruf=2012-10-21}}</ref>

==== Portable Betriebssysteme ====
Eine Spezialfall ist Portable Software, die in ein eigenes Betriebssystem eingebettet ist und damit zur portablen Verwendung einen Neustart und Booten des Wirtsrechners erfordert. Besonders bei Linux-Software, bei der die Erzeugung portabler und distributionsübergreifender Programme schwierig ist<ref name="jones">{{Internetquelle|url=http://www.evanjones.ca/portable-linux-binaries.html|titel=Portable Linux Binaries |datum=2008-02-13 |abruf=2012-01-10|sprache=englisch |autor=Evan Jones|zitat=''Linux is not well known for its binary portability. Libraries vary from system to system, and the kernel interfaces have a tendency to change. […] Recently, I needed to build a binary on one system, and run it on another. It only used standard C library functions, so I expected it to be easy. It was not. […]''}}</ref><ref name="portableapps">{{Internetquelle |url=http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |format=PDF; 38 kB |hrsg=PortableLinuxApps.org |sprache=englisch |autor=Simon Peter |datum=2010 |abruf=2011-07-29 |titel=AppImageKit Documentation 1.0 |seiten=2–3 |zitat=''Not easy to move an app from one machine to another: If you've used an app on one machine and decide that you would like to use the same app either under a different base operating system (say, you want to use OpenOffice on Fedora after having used it on Ubuntu) or if you would simply take the app from one machine to another (say from the desktop computer to the netbook), you have to download and install the app again (if you did not keep around the installation files and if the two operating systems don't share the exact same package format – both of which is rather unlikely).'' |archiv-url=https://web.archive.org/web/20101129031656/http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archiv-datum=2010-11-29 }}</ref><ref name="troy">{{Internetquelle|archiv-url=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp |titel=Linux Game Development Part 2 – Distributable Binaries| autor=Troy Hepfner |datum=2007-10-01 |abruf=2011-12-19 |archiv-datum=2007-10-13 |sprache=englisch |zitat=''Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]''|hrsg=gamedev.net}}</ref>, existieren viele Lösungen für Anwendungssoftware mit portablen, Linux-basierenden Betriebssystemen. Zahlreiche Linux-Derivate bieten sogenannte [[Live-System|Live-CDs]], wie z. B. [[Knoppix]], die den Betrieb von einem [[Wechseldatenträger]] erlauben, ohne Spuren auf dem Wirtsrechner zu hinterlassen.

[[Microsoft Windows]] müsste zwar entsprechend den [[Endbenutzer-Lizenzvertrag|EULA]] immer auf einer (festinstallierten) Festplatte installiert werden und dürfte damit offiziell nicht portabel verwendet werden. Allerdings sind Endbenutzer-Lizenzverträge, die nicht bereits ''vor'' dem Kauf vereinbart wurden (d. h. denen ein Käufer zum Beispiel erst ''nach'' dem Kauf bei der Installation zustimmt), nach deutschem und österreichischem Recht unwirksam.

Mit [[Microsoft Windows PE]] existiert allerdings eine abgespeckte Windows-Variante, die unter anderem auch für eine Installation auf Wechselmedien konzipiert ist. Zusätzlich gibt es auch Lösungen von Drittanbietern wie zum Beispiel [[Bart’s Preinstalled Environment]].<ref>{{Webarchiv |url=http://pcwelt-wiki.de/wiki/Bart_PE_PCW_Edition_2 |wayback=20110117072838 |text=''Bart PE'' }} – Artikel auf [[PC-Welt|pcwelt.de]]</ref>

== Siehe auch ==
* [[PortableApps]]

== Weblinks ==
* [http://portableapps.com/ PortableApps.com], Portable Applikationen für Windows
* [http://www.lupopensuite.com/de/ LupoPenSuite.com/de/], Lupo PenSuite für Windows
* [http://portablelinuxapps.org/ PortableLinuxApps.org], Portable Applikationen für Linux
* [http://www.portablefreeware.com/ PortableFreeware.com], Portable Applikationen für Windows
* [http://pendriveapps.com PendriveApps.com], Portable Applikationen für Windows

== Einzelnachweise ==
<references>
<ref name="sharedlibpolicy">
{{Internetquelle
| url=http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
| titel=Using static and shared libraries across platforms; Row 9: Library Path
| datum=2007-06-15
| archiv-url=https://web.archive.org/web/20080601183608/http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
| archiv-datum=2008-06-01
| autor=Arnaud Desitter
| hrsg=ArnaudRecipes
| abruf=2010-07-07
| sprache = englisch
|zitat=''Win32: . and then PATH''}}
</ref>
<ref name="tonymobilyinstallation">
{{Internetquelle
| autor = Tony Mobily
| titel = 2009: software installation in GNU/Linux still broken and a path to fixing it
| hrsg = www.freesoftwaremagazine.com
| datum = 2009-06-23
| url = http://www.freesoftwaremagazine.com/columns/2009_software_installation_linux_broken_and_path_fixing_it
| abruf = 2010-03-23
| sprache = englisch
| zitat = ''Every GNU/Linux distribution at the moment (including Ubuntu) confuses system software with end user software, whereas they are two very different beasts which should be treated very, very differently.''
| archiv-url = https://web.archive.org/web/20090626060615/http://www.freesoftwaremagazine.com/columns/2009_software_installation_linux_broken_and_path_fixing_it
| archiv-datum = 2009-06-26
}}
</ref>
</references>

[[Kategorie:Software (Thema)]]

Portable Software - Versionsgeschichte

imported>Trustable: Kleinigkeiten verbessert