Warum sind nicht alle Anwendungen tragbar?

Diese Frage nervt jeden, der sich in tragbare Apps verliebt hat: Warum sind Anwendungen nicht tragbar?

Die Frage

SuperUser-Leser Tom liebt die saubere Organisation, die tragbare Apps bieten, und möchte wissen, warum nicht alles tragbar ist:

Ich habe kürzlich versucht, Dinge viel weniger auf meinem Windows-Computer zu «installieren» (ich hasse Installer – ich muss wissen, wo Programme Dinge ablegen …) und stattdessen tragbare oder eigenständige Versionen von Anwendungen verwendet.

Ich habe sie alle in einem Programmverzeichnis auf einem Laufwerk abgelegt, das von meiner Windows-Partition getrennt ist. Wenn ich sie also neu installiere, stehen mir alle meine Anwendungen mit minimalem Aufwand zur Verfügung.

Für Anwendungen wie Office und Creative Suite muss ich immer noch einen schrecklich langen Installationsprozess durchlaufen, bei dem tausend zufällige Bibliotheken und Tools über mein System geworfen werden.

Warum müssen Windows-Apps noch installiert werden? Warum können wir Photoshop nicht einfach in einen Ordner à la OSX ziehen und es einfach funktionieren lassen? Konzentriert sich sonst noch jemand auf tragbare Apps oder bin ich nur OCD in Bezug auf das Ganze?

Wir sind sicherlich Fans von tragbaren Apps und möchten auch den Dingen auf den Grund gehen.

Die Antwort

Der SuperUser-Mitarbeiter David Whitney bietet einen Einblick, warum viele Apps nicht portabel sind und wie Windows eine Art Anti-Portabilitäts-Vereinbarung erzwingt:

Installateure sind das Ergebnis jahrelanger Entwicklung und ein wenig (vereinfachte) Geschichte hilft zu verstehen, warum sie das tun, was sie tun.

Das Windows 3.1-Modell schlug Konfigurationsdateien im config.ini-Stil pro Anwendung vor, wobei gemeinsam genutzte Bibliotheken in Systemordnern unterstützt werden, um Doppelarbeit und verschwendeten Speicherplatz zu vermeiden.

Windows 95 führte die Registrierung ein, die einen zentralen Speicher für die Anwendungskonfiguration ermöglicht und viele Konfigurationsdateien ersetzt. Noch wichtiger ist, dass die Windows-Konfiguration am selben Ort gespeichert wurde.

Die Registrierung wurde aufgebläht, weil Anwendungen nicht nach sich selbst bereinigt wurden. Die Hölle der DLLs war das Ergebnis mehrerer Versionen derselben gemeinsam genutzten Bibliotheken, die sich gegenseitig überschrieben.

.NET führte das Konzept von app.config ein (fast ini-Dateien markieren 2, diesmal mit etwas mehr Struktur, die Entwicklern Zeit beim Schreiben manueller Parser verschwendet). Der GAC wurde in Versionen mit gemeinsam genutzten Assemblys eingeführt, um die DLL-Hölle zu verhindern.

Unter Windows XP und mehr unter Vista versuchte Microsoft, den Benutzerbereich als Speicherort für Benutzerdaten und Konfigurationsdateien an einem einzigen Standardspeicherort zu definieren, um Roaming-Profile und eine einfache Migration (kopieren Sie einfach Ihr Profil) mit den in Programmdateien installierten Anwendungen zu ermöglichen .

Der Grund dafür ist also, dass „Anwendungen in Windows so konzipiert sind, dass sie an einem Ort leben, ihre gemeinsamen Abhängigkeiten an einem anderen und die benutzerspezifischen Daten an einem anderen“, was dem Konzept des Kopierens eines einzelnen Speicherorts ziemlich widerspricht.

.. und das ist, bevor Sie Benutzerkonten konfigurieren, Sicherheitsberechtigungen einrichten und sicherstellen, Updates herunterladen und Windows-Dienste installieren müssen…

xcopy ist der „einfache Fall“ und sicherlich nicht für alles geeignet.

Unglücklicherweise für Fans aller tragbaren Dinge bleiben viele Apps – insbesondere große Apps wie Office – fest auf dem Betriebssystem verankert.

Haben Sie der Erklärung etwas hinzuzufügen? Ton aus in den Kommentaren. Möchten Sie weitere Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Den vollständigen Diskussionsthread finden Sie hier.