Portable Software

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Portable App)
Zur Navigation springen Zur Suche springen

Portable Software (über französisch portable[1] aus lateinisch portare ‚[mit sich] tragen‘), auch Standalone-Software oder (USB-)Stick­-Ware genannt, ist Software, typischerweise Anwendungssoftware, die ohne weitere Anpassungen oder Einrichtung (Installationen) auf verschiedenen 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

[Bearbeiten | Quelltext bearbeiten]

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-Rechte oder auch keine Schreibrechte auf einem System-Datenträger hat.

Definition und Abgrenzung

[Bearbeiten | Quelltext bearbeiten]

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 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 Systemvirtualisierung können zwar ebenfalls portable Eigenschaften erzielt werden, jedoch mit zusätzlichem Aufwand und weiteren Nachteilen (Dateigröße, Leistungsfähigkeit, schlechtere UX/GUI Integration).

Eigenschaften

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

Typischerweise braucht Portable Software keine Installation und kann direkt vom 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 Archiv verbreitet, welches nur in ein Verzeichnis entpackt werden muss, ohne dass systemspezifische Installationsprogramme 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.[2][3]

Keine Spuren auf dem Wirtssystem

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

Auf dem Wirtssystem hat man häufig keine 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

[Bearbeiten | Quelltext bearbeiten]

Oft sind portable Programme angepasste Versionen von konventionellen installationsbedürftigen Programmen. Um sie von diesen zu unterscheiden, wird oft das 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-Software, die nur von einem mit der proprietären U3-Software verträglichen USB-Stick ausgeführt werden kann.

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

Grenzen portabler Programme

[Bearbeiten | Quelltext bearbeiten]

Hardwareplattform-Abhängigkeit

[Bearbeiten | Quelltext bearbeiten]

Anwendungen, welche in einem Binärformat (z. B. ELF oder PE) vorliegen, wurden von einem Compiler für eine spezifische Hardwareplattform generiert (z. B. IA-32). Verschiedene CPU-Architekturen variieren in Befehlssatz, Datenwortgröße (z. B. 32-Bit oder 64-Bit) oder Byte-order. Das beschränkt den portablen Einsatz auf Plattformen der gleichen Hardware. Ein portabler Ansatz zur Umgehung dieser Problematik sind sogenannte 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.[4]

Systemnahe Software

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

Neben den technischen Aspekten spielen beim Einsatz als portable Software auch die 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 GPL-Lizenz manchmal das 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.[5]

Sicherheit im Unternehmen

[Bearbeiten | Quelltext bearbeiten]

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, 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

[Bearbeiten | Quelltext bearbeiten]

Windows-Software

[Bearbeiten | Quelltext bearbeiten]

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[6], bei denen sich Standardorte durchgesetzt haben. Die der Portabilität dienliche Ausführbarkeit von Programmen aus beliebigen (Installations)verzeichnissen heraus (siehe[7] Zeile 9) mit eigenen lokalen Bibliotheken (Private DLLs[8]) ist etwas, das Windows seinem MS-DOS-Ursprung verdankt; die meisten DOS-Programme sind portabel, und nur wenige benötigen spezielle TSR-Programme, welche beim Systemstart geladen werden müssen.

Auch kommt dem Erstellen portabler Software für Windows zugute, dass Abwärtskompatibilität für diese 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.[9]

Jedoch ist die empfohlene Verwendung der zentralen Registrierungsdatenbank seit Windows 95 anstelle lokaler INI-Dateien ein Hindernis für Portabilität unter Windows.[10] 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 Registrierungsdateien nutzen könnte. Eine verstreute Speicherung von Programmdaten in mehreren Systemverzeichnissen (Profil, Persönliche Einstellungen, Persönliche Lesezeichen etc.) im Rahmen der 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 von %APPDATA% (Anwendungsdaten) oder 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 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 %APPDATA% oder als Dateien im Installationsverzeichnis. Mit letzterer Option wird das Programm zu portabler Software.

Linux-Software

[Bearbeiten | Quelltext bearbeiten]

Unter Linux werden Programme typischerweise tief ins Betriebssystem integriert, d. h. mit diesem zusammen kompiliert und ausgeliefert (Linux-Distribution). Diese schwache Differenzierung[11][12] zwischen Anwendungen und Betriebssystem und damit nur schwach ausgeprägtes binäres und stabiles Plattformkonzept[13][14][15][16][17], erschwert die Erstellung portabler Anwendungen deutlich.[18] Dazu gehört die im Allgemeinen strikte, systemweite[11] Verwaltung von Anwendungen und Programmbibliotheken per Paketverwaltung, die Portabilität erschweren. Nach einer Analyse des klik-Projekts über die verschiedenen Paketverwaltungssysteme unter Linux fehlen den am häufigsten genutzten Systemen RPM und 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').[2][18]

Auch das Umplatzieren (Relocation) von Anwendungsprogrammen zwischen verschiedenen Verzeichnissen ist in Linux nicht vorgesehen, Pfade werden typischerweise zur Compilezeit in der Anwendung hart-codiert.[19] Die zum Autopackage gehörende Bibliothek binreloc bietet eine Funktionalität vergleichbar der Win32-API-Funktion GetModuleFilename(), wodurch Verzeichnis-relokierbare Anwendungen und Bibliotheken möglich werden.

Auch können die Unterschiede der Linux-Distributionen untereinander, also die Variationen in Verzeichnisbaumstruktur und den mitgelieferten Bibliotheken, ein problemfreies, portables Ausführen einer binären Programmdatei verhindern.[20] Der Entwicklungsansatz, distributionsübergreifende und portable Anwendungen über ein vollständiges statisches Linken der Bibliotheksabhängigkeiten zu erzeugen, ist technisch schwierig zu realisieren[16][21], kann auch durch Lizenzkonflikte verhindert werden und wird u. a. aufgrund des Unterlaufens von Distributorinfrastruktur und -updates in der Linux-Community nicht gerne gesehen.[22]

Programmiertechnisch lassen sich portablere Programme auch mit privaten Bibliotheken[8] über einen relativen Bibliothekspfad mit der Linker-Option $ORIGIN erzeugen.[5] Vorteile dieses Ansatzes sind, dass keine Benutzeranpassungen der Bibliothekspfade oder andere Skripte nötig sind (im Gegensatz zu LD_LIBRARY_PATH-Ansätzen[5]) 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 Autopackage, RUNZ, PortableLinuxApps[18] (Klik-Nachfolger), Zero Install und CDE[23]. Jedoch folgt jedes dieser Systeme einem anderen Ansatz und deckt damit einen anderen Teilaspekt der Portabilität ab[3]. 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.[24][25][26]

Portable Betriebssysteme

[Bearbeiten | Quelltext bearbeiten]

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[16][18][20], existieren viele Lösungen für Anwendungssoftware mit portablen, Linux-basierenden Betriebssystemen. Zahlreiche Linux-Derivate bieten sogenannte 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 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.[27]

Siehe auch

[Bearbeiten | Quelltext bearbeiten]
[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ portabel – Duden, Bibliographisches Institut; 2016
  2. ↑ a b Simon Peter: Comparison table. klik.atekon.de, 29. Januar 2009, archiviert vom Original (nicht mehr online verfügbar) am 23. Dezember 2015; abgerufen am 26. März 2010 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/klik.atekon.de
  3. ↑ a b Thomas Leonard: Zero Install: Comparison with other systems. 0install.net/, 1. Januar 2010, abgerufen am 26. März 2010 (englisch).
  4. ↑ Apple Computer: "Universal Binaries and 32-bit/64-bit PowerPC Binaries" in der Mac OS X ABI Mach-O File Format Referenz. 8. März 2006, abgerufen am 13. Juli 2006.
  5. ↑ a b c Eskild Hustvedt: Our new way to meet the LGPL. 8. Februar 2009, archiviert vom Original am 13. April 2014; abgerufen am 9. März 2011 (englisch): „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!“
  6. ↑ Hisham Muhammad: The Unix tree rethought: an introduction to GoboLinux. www.kuro5hin.org, 9. Mai 2003, abgerufen am 19. Dezember 2011: „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).“
  7. ↑ Arnaud Desitter: Using static and shared libraries across platforms; Row 9: Library Path. ArnaudRecipes, 15. Juni 2007, archiviert vom Original am 1. Juni 2008; abgerufen am 7. Juli 2010 (englisch): „Win32: . and then PATH“
  8. ↑ a b Rick Anderson: The End of DLL Hell. microsoft.com, 11. Januar 2000, archiviert vom Original am 5. Juni 2001; abgerufen am 15. Januar 2012: „Private DLLs are DLLs that are installed with a specific application and used only by that application.“
  9. ↑ Ian Murdock: On the importance of backward compatibility. 17. Januar 2007, archiviert vom Original am 14. Januar 2012; abgerufen am 4. Januar 2012 (englisch).
  10. ↑ http://support.microsoft.com/kb/256986 Beschreibung der Microsoft-Windows-Registrierung (3. Dezember 2007)
  11. ↑ a b Tony Mobily: 2009: software installation in GNU/Linux still broken and a path to fixing it. www.freesoftwaremagazine.com, 23. Juni 2009, archiviert vom Original am 26. Juni 2009; abgerufen am 23. März 2010 (englisch): „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.“
  12. ↑ Benjamin Smedberg: Is Ubuntu an Operating System? 4. Oktober 2006, abgerufen am 20. Januar 2012 (englisch): „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.“
  13. ↑ Michael Simms: Handling misbehaving libraries in binary products. Linux Game Publishing, 18. August 2009, archiviert vom Original am 22. Februar 2014; abgerufen am 15. Januar 2012 (englisch): „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.“
  14. ↑ Peter Keller: The Road to Hell Is Paved with Good Intentions. 24. Mai 2005, archiviert vom Original am 23. November 2008; abgerufen am 12. Januar 2012 (englisch): „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.“
  15. ↑ David Douthitt: Why doesn’t my /bin/sh script run under Ubuntu? administratosphere.wordpress.com, 20. Juli 2011, abgerufen am 10. Januar 2012 (englisch): „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.“
  16. ↑ a b c Evan Jones: Portable Linux Binaries. 13. Februar 2008, abgerufen am 10. Januar 2012 (englisch): „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. […]“
  17. ↑ Eric Brown: LSB 4.0 certifications aim to heal Linux fragmentation. linuxfordevices.com, 8. Dezember 2010, archiviert vom Original am 24. Dezember 2013; abgerufen am 16. November 2011 (englisch): „[…] 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."[…]“
  18. ↑ a b c d Simon Peter: AppImageKit Documentation 1.0. (PDF; 38 kB) PortableLinuxApps.org, 2010, S. 2–3, archiviert vom Original am 29. November 2010; abgerufen am 29. Juli 2011 (englisch): „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).“
  19. ↑ Mike Hearn: Guide to Making Relocatable Applications (BinReloc 2.0). autopackage.org, archiviert vom Original am 25. Januar 2009; abgerufen am 26. Januar 2012 (englisch): „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.“
  20. ↑ a b Troy Hepfner: Linux Game Development Part 2 – Distributable Binaries. gamedev.net, 1. Oktober 2007, archiviert vom Original am 13. Oktober 2007; abgerufen am 19. Dezember 2011 (englisch): „Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]“
  21. ↑ Christoph Baus: Yet another Unix nightmare: statically linking libstdc++. 31. Mai 2005, archiviert vom Original am 10. Februar 2010; abgerufen am 15. Januar 2012 (englisch).
  22. ↑ Ulrich Drepper: Static Linking Considered Harmful. redhat.com, archiviert vom Original am 27. Mai 2010; abgerufen am 13. Januar 2012 (englisch): „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. […]“
  23. ↑ timothy: CDE — Making Linux Portability Easy. Slashdot, 12. November 2010, abgerufen am 21. Januar 2012 (englisch): „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.“
  24. ↑ Nicholas Vining: Dear Linux Community: We Need To Talk. Gaslamp Games, 13. Oktober 2010, abgerufen am 30. Januar 2011 (englisch): „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.“
  25. ↑ Bruce Byfield: Autopackage struggling to gain acceptance. linux.com, 12. Februar 2007, archiviert vom Original am 31. März 2008; abgerufen am 21. Januar 2012 (englisch): „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.“
  26. ↑ Jeff Licquia: Autopackage Considered Harmful. licquia.org, 27. März 2005, abgerufen am 21. Oktober 2012.
  27. ↑ Bart PE (Memento vom 17. Januar 2011 im Internet Archive) – Artikel auf pcwelt.de
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Portable_Software&oldid=241778087“