Warum funktioniert Software nicht ohne Installation? Eine bildliche Einführung, wie Apps sich ins Betriebssystem einklinken

Wer einen PC oder ein Smartphone nutzt, ist sicher schon mehr als einmal über kleine Rätsel wie diese gestolpert.

• Slack und VS Code funktionieren erst, nachdem man sie installiert hat, aber Gmail und Google Docs laufen schon beim Aufruf einer URL ─ wo liegt der Unterschied?
• Überall begegnen einem „install“-Befehle ─ pip (Python), npm (Node.js), brew (Mac), apt (Linux), winget (Windows). Was tun die eigentlich alle?
• Warum muss man bei jeder Installation sein Administratorpasswort eintippen?
• Auf macOS zieht man eine .app meist einfach in einen Ordner und ist fertig, während Windows-.exe-Installer einen durch einen Dialog nach dem anderen führen. Woher kommt dieser Unterschied?

„Installation“ ist nur ein Wort, hinter dem sich viele verschiedene Eindrücke verbergen, weshalb sich das Thema schwer in einen Satz packen lässt. Verfolgt man jedes dieser Phänomene jedoch bis zu seinem Ursprung, landet man bei derselben Antwort.

Damit Software laufen kann, muss sie sich beim Betriebssystem (Windows, macOS, Linux usw.) offiziell vorstellen ─ „Hallo, eine neue App zieht ein“ ─ und ihm die Hand geben.

„Installation“ ist schlicht der Name, den wir diesem Begrüßungsritual geben. In diesem Artikel klären wir:

• Was eigentlich in einer ausführbaren Datei (.exe / .app / .deb) drinsteckt
• Warum Programme nicht aus eigener Kraft laufen können und immer auf die Hilfe des Betriebssystems angewiesen sind
• Was die Blackbox „Installation“ hinter den Kulissen konkret tut
• Warum es überhaupt „installationsfreie“ Welten (Webapps, Portable Apps, Container) geben kann

Schritt für Schritt, mit Diagrammen und ohne Vorwissen.

1. Was Programme wirklich sind ─ ausführbare Dateien als Anweisungen für Betriebssystem und CPU

Was steckt eigentlich in dem .exe-, .app– oder .deb-„Paket“, das du gerade heruntergeladen hast? Wenn wir es aufknacken, wird verständlich, warum Programme nicht von allein laufen können.

1-1. Eine ausführbare Datei ist nur eine Folge von Bytes ─ aber in einer ganz bestimmten Reihenfolge

Wirft man einen Blick in eine ausführbare Datei, sieht man nur einen langen Strom aus Nullen und Einsen (Binärdaten). In einem Texteditor wirkt das völlig unleserlich. Die Reihenfolge dieser Bytes folgt jedoch strikten Regeln, und sobald das Betriebssystem sie liest, entsteht Bedeutung: „Hier beginnt der eigentliche Programmcode“, „dieser Bereich ist für Daten“, „dieser Abschnitt listet externe Bibliotheken auf“ und so weiter.

Dieses für das Betriebssystem lesbare Layout nennt man ein ausführbares Dateiformat. Jedes wichtige Betriebssystem verwendet eines von drei Formaten ─ und damit auch jeder PC der Welt.

Wenn also eine Windows-.exe sich auf einem Mac weigert zu starten, dann nicht aus Bosheit ─ das Betriebssystem spricht schlicht nicht denselben Befehlsformat-Dialekt. Etwa so, als würde man einem französischen Leser einen japanischen Brief schicken: er sieht zwar die Zeichen, aber er kann der Bedeutung nicht folgen.

1-2. Die vier Hauptbestandteile in einer ausführbaren Datei

Die drei Formate unterscheiden sich im Detail, ihr grobes Gerüst ist aber ähnlich. Teilt man es in vier „Räume“ auf, kann man es sich deutlich leichter vorstellen.

┌─────────────────────────────────────┐
│ Header                              │ ← Deckblatt, das das Betriebssystem zuerst liest ("ELF v1.0", "64-bit", Ziel-OS)
├─────────────────────────────────────┤
│ Code (.text)                        │ ← die eigentlichen CPU-Anweisungen
├─────────────────────────────────────┤
│ Daten (.data / .rodata)             │ ← Zeichenketten, Konstanten, eingebettete Ressourcen
├─────────────────────────────────────┤
│ Symbole / Link-Infos                │ ← Liste der Form "welche externe Bibliothek und welche Funktion möchte ich aufrufen"
└─────────────────────────────────────┘

• Der Header ist das Deckblatt. Das Betriebssystem liest ihn zuerst und entscheidet: „Ist das überhaupt eine Datei, die ich ausführen kann?“
• Code enthält die eigentlichen CPU-Anweisungen ─ add, mov, jmp usw.
• Daten speichern die Rohmaterialien des Programms: Textstrings, numerische Standardwerte, Bildressourcen.
• Symbole / Link-Infos sind eine „Einkaufsliste der fehlenden Teile“ ─ „An dieser Stelle möchte ich printf aufrufen, verbinde es bitte für mich“, sagen sie dem Betriebssystem und dem Loader.

Sieht man das Bild? Eine ausführbare Datei ist kein fertiges Produkt. Sie ist ein Beutel mit Bauanleitung + Rohmaterialien + Einkaufsliste. Das Betriebssystem liest die Anweisungen, übergibt den Code an die CPU und verdrahtet die fehlenden Teile (gemeinsam genutzte Bibliotheken), damit das Ganze tatsächlich läuft.

2. Programme laufen nicht allein ─ der ständige Dialog mit dem Betriebssystem

Wie §1 gezeigt hat, trägt eine ausführbare Datei eine „Einkaufsliste“ mit sich. Wo wird eingekauft? Beim Betriebssystem und seinen Standardbibliotheken. Wann immer eine App ein Zeichen auf dem Bildschirm ausgibt, eine Datei öffnet oder mit dem Netzwerk spricht, erledigt sie das nicht selbst ─ sie bittet höflich das Betriebssystem darum.

2-1. Der vierschichtige Stack: App → Standardbibliothek → Kernel → Hardware

Grob skizziert sieht das Innere eines PCs schichtweise so aus.

┌─────────────────────────────┐   ← Slack, VS Code, die Apps, die du startest
│   Anwendung                  │
├─────────────────────────────┤
│   Standardbibliothek         │   ← C-Standardbibliothek, .NET, libc, Foundation usw.
│   (Sprach-Runtime)           │      Die Übersetzungsschicht zwischen App und Betriebssystem
├─────────────────────────────┤
│   OS-Kernel                  │   ← Windows-Kernel, Linux-Kernel, Darwin
│                              │      Herr über Bildschirm, Dateien, Netzwerk und Speicher
├─────────────────────────────┤
│   Hardware                   │   ← CPU, Speicher, SSD, GPU, Netzwerkkarte
└─────────────────────────────┘

Will eine App „‚Hello‘ auf dem Bildschirm anzeigen“, schickt sie nicht selbst Signale an den Monitor. Stattdessen läuft ein Staffellauf ab:

1. Die App ruft eine Funktion wie printf("Hello") auf
2. Die Standardbibliothek (libc bei C, BCL bei .NET) bereitet eine Anfrage an das Betriebssystem für die „Bildschirmausgabe“ vor
3. Sie übergibt diese Anfrage an den OS-Kernel ─ diese Übergabe nennt man einen Systemaufruf (ein offizieller „Arbeitsauftrag“ von der App an das Betriebssystem)
4. Der Kernel geht über den Grafiktreiber zur Hardware und sagt ihr, was sie zeichnen soll ─ und die Buchstaben erscheinen

Mit anderen Worten: Apps sind von Anfang an mit der Annahme geschrieben, dass das Betriebssystem ihnen hilft. Eine ausführbare Datei, die ohne Hilfe eines Betriebssystems läuft, gibt es schlicht nicht. Genau das ist der tiefere Grund, warum es überhaupt die Vorstellung gibt, „man installiert eine App für ein bestimmtes Betriebssystem“.

2-2. Systemaufrufe ─ die offiziellen „Bestellscheine“ an das Betriebssystem

Über einen Systemaufruf (der spezielle Schalter, an dem Apps dem Betriebssystem „bitte erledige das“ sagen) werden typischerweise Dinge wie diese angefragt:

Jede dieser Aufgaben kann die App selbst nicht erledigen oder darf es nicht ─ also bittet sie stattdessen das Betriebssystem. Ohne dessen Hilfe bekommt eine App nicht einmal ein einzelnes Zeichen auf den Bildschirm.

3. [Kern] Was „Installieren“ hinter den Kulissen wirklich tut

Wir wissen jetzt: „Eine App läuft ohne Hilfe des Betriebssystems nicht.“ Damit lässt sich Installation knapp zusammenfassen: Sie ist der Oberbegriff für die Vorarbeit, die eine Beziehung zwischen App und Betriebssystem herstellt. Praktisch jeder Installer der Welt (.msi, .pkg, .dmg, .deb, .rpm, das Ziehen einer .app unter macOS, der Installations-Button im Microsoft Store usw.) durchläuft die folgenden sechs Phasen.

3-1. Die sechs Phasen, die ein Installer durchläuft

Jede Phase dauert wenige hundert Millisekunden bis mehrere Sekunden, und in Summe ist genau das die „Wartezeit der Installation“, die du wahrnimmst.

1. 1SignaturprüfungPrüft, ob die Datei „wirklich von einem legitimen Autor stammt“ (stell es dir wie eine Stempelprüfung bzw. Echtheitssiegel-Prüfung vor). Unter Windows übernimmt das Authenticode, auf dem Mac Gatekeeper, unter Linux die GPG-Signatur der Pakete.
2. 2EntpackenPackt den einzelnen Beutel (den Installer) auseinander: die eigentliche Hauptbinärdatei, Hilfsbibliotheken, Konfigurationen, Dokumentation usw. Bis hierhin werden nur „die Materialien herausgenommen“.
3. 3PlatzierenVerschiebt die ausgepackten Dateien an die Standardorte des Betriebssystems. Unter Windows ist das C:\Program Files\, auf dem Mac /Applications/, unter Linux /usr/lib/ und /usr/bin/.
4. 4RegistrierenTrägt den Namen der App in das „Adressbuch“ des Betriebssystems ein. Windows schreibt in die Registrierung (der riesige Notizblock, auf dem das Betriebssystem seine Einstellungen vermerkt), der Mac legt plist-Dateien an, Linux platziert eine .desktop-Datei.
5. 5IntegrierenLegt Symbole im Startmenü / Launchpad / App-Menü an und verknüpft die App mit den passenden Dateiendungen (.txt, .psd, …).
6. 6NachbereitenRegistriert eventuelle Hintergrunddienste, baut Caches für den Erststart auf, passt PATH an, legt Verknüpfungen an und räumt zum Schluss temporäre Dateien weg.

Merksatz: prüfen → entpacken → platzieren → registrieren → integrieren → nachbereiten. Jeder Installer führt dich durch diese sechs Schritte, um von „heruntergeladen“ zu „einsatzbereit“ zu kommen.

3-2. Vorher / Nachher ─ das Dateisystem verändert sich sichtbar

Falls die „sechs Phasen“ noch zu abstrakt klingen: Vergleicht man die Festplatte vor und nach der Installation, wird es sofort greifbar.

~/Downloads/
└── SuperApp-1.2.3.exe   ← ein einzelner Beutel

C:\Program Files\SuperApp\
├── SuperApp.exe                ← Hauptbinärdatei
├── core.dll, render.dll, ...   ← Teile (gemeinsam genutzte Bibliotheken)
└── resources\                  ← Bilder, Übersetzungen

C:\Users\me\AppData\Roaming\SuperApp\
└── settings.json               ← Benutzereinstellungen

Registry HKLM\Software\SuperApp
├── InstallPath = "C:\Program Files\SuperApp"
└── Version = "1.2.3"

Startmenü → SuperApp (Verknüpfung)

Wie du siehst, ist Installation die kombinierte Handlung „eine einzelne .exe auf die richtigen Ordner verteilen + dem Betriebssystem davon erzählen“. Es ist nicht so, dass „der Doppelklick nichts ausführt“ ─ vielmehr finden in den Sekunden bis Minuten nach dem Doppelklick zahlreiche Einrichtungsschritte auf Betriebssystem-Ebene statt. Das ist das treffendere mentale Modell.

4. Abhängigkeiten ─ warum eine einzelne ausführbare Datei nicht für sich allein steht

„Es ist doch nur eine App, warum sind das Hunderte von Dateien?“ Die Antwort steht in diesem Abschnitt. Der Schlüssel ist das Konzept der gemeinsam genutzten Bibliotheken (Bauteilkisten, aus denen sich viele Apps bedienen).

4-1. Was eine gemeinsam genutzte Bibliothek ist

„Dieses Bild als JPEG speichern“ ist die Art Funktion, die irgendwann sowohl Photoshop als auch VS-Code-Erweiterungen oder Slack brauchen. Würde jede App ihre eigene Kopie mitbringen:

• bläht sich die Festplatte mit doppelten Bauteilen auf
• zwingt ein einziger Sicherheitsfix dazu, sämtliche Apps neu zu veröffentlichen

Um diesen Schmerz zu vermeiden, bietet das Betriebssystem einen Weg, gemeinsame Bauteile in einer Datei zu sammeln und sie an mehrere Apps „auszuleihen“. Das ist eine gemeinsam genutzte Bibliothek (Endung .dll unter Windows, .dylib auf dem Mac, .so unter Linux).

                 ┌──────────────────────────┐
                 │      deine Anwendung       │
                 └──────────────────────────┘
                       │   │   │
        ┌──────────────┘   │   └──────────────┐
        ▼                  ▼                  ▼
   libjpeg.dll        libssl.dll         libcurl.dll
   (JPEG-Bauteile)    (Krypto-Bauteile)  (HTTP-Bauteile)
        │                  │                  │
        └──────────────────┴──────────────────┘
                           ▼
                ┌──────────────────────┐
                │   OS-API (Kernel)    │
                └──────────────────────┘

Selbst wenn die App selbst nur wenige MB groß ist, hängt sie in der Praxis von einer Handvoll solcher „Bauteilkisten“ ab, und der Installer legt sie zusammen mit der Hauptbinärdatei auf der Festplatte ab. Genau deshalb können aus „einer App“ nach der Installation Hunderte MB werden.

4-2. DLL-Hölle ─ wenn gemeinsame Bauteile sich um Versionen streiten

Gemeinsam genutzte Bibliotheken sind praktisch, haben aber einen berühmten Fehlermodus: Stimmen die Versionen nicht zusammen, gerät alles auf einmal aus dem Tritt. Das ist die legendäre DLL-Hölle (das Chaos, wenn zwei Apps unterschiedliche Versionen derselben Bauteilkiste verlangen und sich am Ende gegenseitig kaputtmachen).

   App A  ─→ benötigt libfoo v1.0
   App B  ─→ benötigt libfoo v2.0
                    │
                    ▼
        Im Betriebssystem kann nur ein libfoo liegen
        →  eine der beiden bricht garantiert

Moderne Betriebssysteme entschärfen das auf unterschiedliche Weise:

• Windows: WinSxS (Side-by-Side) und Pakete im Stil von Microsoft.UI.Xaml lassen mehrere Versionen unter unterschiedlichen Dateinamen nebeneinander existieren
• macOS: regt jede .app dazu an, die benötigten .dylib-Dateien in eigener Kopie mitzubringen
• Linux: Paketmanager (siehe später) lösen den Abhängigkeitsgraphen für dich auf

Trotzdem ist die Fehlermeldung MSVCR100.dll not found, die man bei alter Software immer wieder zu sehen bekommt, der noch immer sichtbare Schatten genau dieses Problems.

5. Betriebssystem-Integration ─ Dateiverknüpfungen, Menüeinträge, Autostart

In den Phasen 4 und 5 von §3 (Registrieren und Integrieren) sorgt der Installer dafür, dass sich die App offiziell beim Betriebssystem anmeldet. Schaut man sich Betriebssystem für Betriebssystem genau an, „was wohin geschrieben wird“, werden die Unterschiede sofort deutlich.

5-1. Was eingetragen wird ─ je nach Betriebssystem

„Apps sehen an der Oberfläche zwar gleich aus, aber der Notizblock, in den sie tatsächlich schreiben, ist auf jedem Betriebssystem ein anderer.“ Wenn das erst einmal klick gemacht hat, wundert man sich nicht mehr darüber, „dass dieselbe Software unter Windows reibungslos lief und sich auf macOS wie ein ganz anderes Tier anfühlt“.

5-2. Warum es nicht reicht, „die ausführbare Datei einfach irgendwo abzulegen“

Du kannst eine notepad.exe einfach in Downloads liegen lassen und doppelklicken; technisch läuft sie auch so. Aber du bekommst dabei nicht:

• Schnellstart aus dem Startmenü
• Automatisches Öffnen von .txt-Dateien in dieser App per Doppelklick
• Deinstallation mit einem Klick über die Deinstallationsoberfläche des Betriebssystems
• Automatische Updates, die von selbst laufen
• Dasselbe Symbol, das auch nach einem Neustart noch da ist

All das ist die Frucht der Betriebssystem-Integration. Genau um dieses Erlebnis zu ermöglichen, wurde aus Installation die Kombination „Dateien platzieren + sie beim Betriebssystem registrieren“.

6. Berechtigungen und Sicherheit ─ warum nach dem Administratorpasswort gefragt wird

„Warum werde ich bei jeder einzelnen Installation nach meinem Passwort gefragt?“ Diese kleine Reibung ist in Wahrheit der Beweis, dass die Sicherheitsklinke des Betriebssystems funktioniert. Wer den Grund versteht, empfindet diese Frage nicht mehr als lästig.

6-1. Systembereich gegenüber Benutzerbereich

Das Dateisystem eines Betriebssystems teilt sich in Bereiche, in die nur mit Administratorrechten geschrieben werden darf, und in Bereiche, in denen das nicht nötig ist.

┌───────────────── Administratorrechte erforderlich ──────────┐
│  Windows : C:\Program Files\, C:\Windows\, HKLM\Registry    │
│  macOS   : /Applications/, /Library/, /usr/local/           │
│  Linux   : /usr/, /etc/, /opt/                              │
└──────────────────────────────────────────────────────────────┘
┌───────────────── Benutzerrechte reichen aus ────────────────┐
│  Windows : %USERPROFILE%\AppData, HKCU\Registry             │
│  macOS   : ~/Library/, ~/Applications/                       │
│  Linux   : ~/.local/, ~/.config/                            │
└──────────────────────────────────────────────────────────────┘

Will ein Installer in Phase 3 (Platzieren) von §3 die App in den Systembereich legen, wird er vom Betriebssystem mit der Frage „Bist du sicher, dass du das möchtest?“ gestoppt. Genau das ist:

• Der Windows-UAC-Dialog („Möchtest du zulassen, dass durch diese App Änderungen an deinem Gerät vorgenommen werden?“)
• Die Passwortabfrage von macOS
• Die sudo-Passwortabfrage unter Linux

Und der symmetrische Fall ─ „Ziehe eine Mac-.app in dein persönliches ~/Applications/, und es wird kein Passwort verlangt“ ─ folgt aus derselben Logik.

6-2. Signaturprüfung ─ die Echtheitssiegel-Prüfung

Zusätzlich zu den Berechtigungen prüft das Betriebssystem vorab auch: „Stammt dieser Installer wirklich von dem Autor, den er angibt?“ Das ist die Signaturprüfung (die „Stempel“- bzw. Echtheitssiegel-Prüfung, die bestätigt, dass der Installer tatsächlich von einem legitimen Autor stammt), und jedes Betriebssystem hat seine eigene Variante:

Warnungen wie „Diese App stammt von einem nicht verifizierten Entwickler“ oder „Diese App kann nicht geöffnet werden, weil sie nicht überprüft werden konnte“ sind genau das Ergebnis dieser Signaturprüfungen. Eine durchgefallene Prüfung bedeutet nicht automatisch Schadsoftware ─ kleine, unabhängige Entwickler verzichten oft auf das Code-Signing, weil Zertifikate teuer sind ─ aber „nichts ausführen, was die Prüfung nicht besteht“ ist die sichere Standardregel.

7. Die Welt „ohne Installation“

Bisher haben wir gesehen: „Installation = Handschlag mit dem Betriebssystem.“ Wenn etwas anderes diesen Handschlag stellvertretend für dich erledigt, musst du im Prinzip selbst nichts installieren. In der Praxis kennt das moderne Computing dafür mehrere Wege. Schauen wir uns kurz an, wie jeder von ihnen das hinkriegt.

7-1. Vier Ansätze im Überblick

7-2. Warum jeder Ansatz mit „keine Installation“ davonkommt

Hier jeweils einfach erklärt, mit einer einsteigerfreundlichen Analogie dazu.

• Webapp: Das eigentliche Programm liegt auf einem entfernten Server, nicht auf deinem PC. Dein PC führt nur einen Browser aus. Weil der Browser selbst bereits dem Betriebssystem die Hand gegeben hat, brauchen die Apps, die auf ihm laufen, keinen eigenen Handschlag (stell es dir wie einen Tisch vor, den du dir in einem Restaurant ausleihst).
• Portable App (stell sie dir wie eine ganze App vor, die auf einen USB-Stick gequetscht wurde): Sie trägt alle nötigen Bauteile mit sich und rührt weder Registry noch plist an ─ Entpacken reicht also aus. Der Kompromiss: größere Datei und keine Betriebssystem-Integration (keine Menüeinträge, keine Dateiverknüpfungen).
• Container (stell ihn dir wie eine versiegelte, tragbare kleine Kammer vor, in der die App zusammen mit den nötigen Teilen des Betriebssystems steckt): Nicht nur die App, sondern auch ihre Bibliotheken und Konfigurationen werden in die Kammer gepackt und laufen isoliert von deinem Host-Betriebssystem. Der Handschlag findet innerhalb der Kammer statt, sodass auf deinem eigentlichen PC nahezu nichts geschrieben wird. Genau diese Bequemlichkeit hat „die gesamte Laufzeitumgebung ausliefern, nicht nur den Code“ zum Standard der Cloud-Ära gemacht.
• Paketmanager (er automatisiert das „Installations“-Ritual, das du sonst von Hand machen würdest, im Namen des Betriebssystems): Sieht aus wie „keine Installation“, in Wahrheit führt er nur mit einem einzigen Befehl die sechs Phasen aus §3 für dich aus. Du solltest ihn dir besser als „Installation, aber sauber automatisiert“ vorstellen. In den wenigen Sekunden eines brew install nginx läuft hinter dem Vorhang der Tanz aus prüfen / entpacken / platzieren / registrieren ab.

Sobald man das durchschaut hat, schrumpft „muss ich installieren oder nicht?“ auf die Frage „wer übernimmt für mich den Handschlag mit dem Betriebssystem?“. Bei Webapps der Browser, bei Containern die Container-Engine, bei Paketmanagern ein Automatisierungsskript. Irgendwo gibt immer jemand die Hand.

8. In der Praxis sehen ─ Befehle, die zeigen, was sich durch die Installation tatsächlich verändert hat

Nachdem die Theorie klar ist, öffnen wir nun deinen eigenen PC und überprüfen: „Ja, bei einer Installation werden tatsächlich Dateien hinzugefügt.“ Jedes Betriebssystem hat dafür einen ein- bis zweizeiligen Befehl.

8-1. Installierte Apps / Pakete auflisten

Zunächst lassen wir uns pro Betriebssystem ausgeben, „was auf diesem PC gerade installiert ist“.

# Windows (PowerShell)
Get-Package | Select-Object Name, Version | Sort-Object Name

# macOS (per Homebrew installierte Apps)
brew list --versions

# Linux (Debian / Ubuntu)
dpkg -l | head -20

8-2. Untersuchen, welche Dateien eine einzelne App abgelegt hat

Du kannst dich auch tiefer in ein einzelnes Paket bohren und sehen, welche Dateien sein Installer im System verteilt hat.

# Linux (Debian / Ubuntu) ─ alle Dateien auflisten, die das Paket git platziert hat
dpkg -L git | head -20

# macOS ─ ein über den offiziellen .pkg-Weg installiertes Paket inspizieren
pkgutil --pkg-info com.apple.pkg.CLTools_Executables

# Windows ─ Installationen über die Uninstall-Schlüssel der Registry auflisten
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*' | Select-Object DisplayName, DisplayVersion

Du siehst Einträge wie /usr/bin/git, /usr/share/man/man1/git.1.gz, /etc/bash_completion.d/git ─ mit anderen Worten: eine einzige App verteilt sich an viele Stellen im Betriebssystem. Wenn man begreift, „dass sich diese eine heruntergeladene Datei tatsächlich so weit ins Betriebssystem hineinzieht“, fühlt sich Installation nicht mehr nach Magie an, sondern wird wirklich greifbar.

Fazit ─ vier Sätze, die alles zusammenfassen

Der Artikel ist lang, sein Kern passt aber in vier Stichpunkte.

• Eine App läuft nicht allein. Sie läuft nur, indem sie sich Betriebssystem und Hardware ausleiht ─ und genau deshalb ist ein Handschlagsprotokoll mit dem Betriebssystem unvermeidlich.
• Installation ist die Zeremonie, die diesen Handschlag vollzieht ─ prüfen, entpacken, platzieren, registrieren, integrieren, nachbereiten, sechs Phasen in dieser Reihenfolge.
• Das Administratorpasswort fragt „Bist du sicher, dass du in den Systembereich schreiben willst?“ Die Signaturprüfung fragt „Stammt das wirklich von einem legitimen Autor?“.
• Web, Portable, Container und Paketmanager sind allesamt „Stellvertreter“ für den Handschlag ─ „keine Installation“ funktioniert nur, weil irgendwo irgendjemand bereits die Hand gegeben hat.

Mit diesen vier Sätzen im Hinterkopf kannst du .exe, .app, .deb oder docker run mit derselben Brille lesen und verstehen, was sich vor deinen Augen abspielt.

Für die Grundlagen auf der Netzwerkseite siehe unseren früheren Artikel Was ist eine IP-Adresse?. Zusammen mit dem heutigen „Handschlag zwischen Betriebssystem und App“ hast du das vollständige Bild davon, wie Daten dein Gerät erreichen und wie die App darauf tatsächlich läuft. Wer noch tiefer einsteigen möchte: Den richtigen numerischen Typ in SQL wählen auf dieser Seite verfolgt denselben Faden vom Typ „Wie werden Daten in einem Programm dargestellt?“.

FAQ

Q1. Was ist der Unterschied zwischen einer Portable App und einer installierten App?

A. Die eigentliche Binärdatei im Inneren ist nahezu dieselbe; der Unterschied liegt darin, ob eine Betriebssystem-Integration stattfindet. Eine installierte Kopie durchläuft alle sechs Phasen aus §3 und „gibt dem Betriebssystem ausgiebig die Hand“ ─ damit bekommt man Einträge im Startmenü, Dateiverknüpfungen, automatische Updates und so weiter. Eine portable Kopie hält bei den Phasen 1–2 (prüfen, entpacken) plus dem Platzieren des Ordners an ─ sie verzichtet bewusst darauf, sich in das Adressbuch des Betriebssystems eintragen zu lassen.

Q2. Entfernt eine Deinstallation wirklich alles?

A. Das meiste verschwindet, aber Einstellungen und Benutzerdaten bleiben in der Regel zurück. Windows lässt Konfigurationen unter C:\Users\<du>\AppData\ liegen, der Mac unter ~/Library/Application Support/<App>/, Linux unter ~/.config/<app>/ ─ und das absichtlich, damit eine spätere Neuinstallation deine Einstellungen wieder aufgreifen kann. Wer den vollständigen Rundumschlag will, löscht diese Ordner von Hand oder greift zu einem Helfer wie AppCleaner (Mac) oder Bulk Crap Uninstaller (Windows).

Q3. Warum funktioniert Drag-and-Drop bei macOS-.app-Bundles?

A. Eine .app ist eigentlich keine „Datei“ ─ sie ist ein Ordner, vollgepackt mit allem, was die App braucht (wir nennen das ein Bundle). Die Hauptbinärdatei, die Bauteile (.dylib), die Ressourcen und Info.plist liegen alle darin, sodass kaum externe Bearbeitung im Stil der Registry nötig ist. Den Ordner nach /Applications/ zu ziehen reicht aus, damit das Betriebssystem ihn erkennt. Auch Windows-.exe-Binärdateien lassen sich eigenständig ausführen, aber die Windows-Konvention verstreut ihre Einstellungen in die Registry ─ ein einzelnes Ziehen reicht hier nicht für eine saubere Installation.

Q4. Zählt das Ausführen von Docker als „Installation“?

A. Stell es dir als zwei Schichten vor. Docker selbst (die Engine, die Container ausführt) braucht einmal eine native Installation auf deinem PC. Sobald die da ist, lebt jede einzelne App, die du darin betreibst, in einem Container („abgeschotteten Zimmer“) und wird nie in dein eigentliches Betriebssystem geschrieben. „Apps, die installationsfrei wirken“ sind genau deshalb installationsfrei, weil die Docker-Engine den Handschlag mit dem Betriebssystem stellvertretend für sie übernimmt.

Q5. Kann ich Software ohne Administratorrechte installieren?

A. Ja, solange du im Benutzerbereich bleibst. Unter Windows gibt es „User Installer“, die ihren Inhalt unter %LOCALAPPDATA% ablegen (etwa der „User Installer“ von VS Code), auf dem Mac kannst du eine .app in ~/Applications/ ziehen, und unter Linux kannst du Binärdateien nach ~/.local/bin/ kopieren oder pipx install --user benutzen. Alles, was hingegen das gesamte System betrifft (Treiberinstallation, dauerhafte Hintergrunddienste, Dateien unter /usr/local/ ablegen und so weiter), muss zwangsläufig in den Systembereich schreiben ─ damit werden Administratorrechte unumgänglich.