Autostart

Autostart ist die unter Windows übliche Bezeichnung für das automatische Starten von Programmen beim Booten des Systems oder beim Anmelden. Ein solches Programm muss also nicht von einem Benutzer gestartet werden, sondern startet automatisch ohne dessen Zutun. Autorun ist dagegen die Funktion von Betriebssystemen, beim Einlegen oder Einstecken von auswechselbaren Datenträgern eine bestimmte Aktion zu starten.

Das Kofferwort setzt sich aus den Wörtern Automatisch und Starten zusammen.

Beim Systemstart (oder genauer: nach der Benutzeranmeldung) werden alle Dateien, die sich im Startmenü-Ordner Autostart befinden, automatisch ausgeführt. Bei den echten Mehrbenutzersystemen Windows NT, Windows 2000, Windows XP und den neueren Windows-Versionen gibt es diese Autostart-Ordner mindestens zweimal: einmal für jeden Benutzer, den dieser selbst verwalten kann, und einmal für alle Benutzer (All Users), den in der Regel nur Administratoren des Systems oder das System selbst (z. B. innerhalb einer Programminstallation) verwalten können. In der Regel befinden sich in diesem Ordner nur Verknüpfungen, es können jedoch auch alle anderen Dateien ausgeführt bzw. geöffnet werden. Daneben gibt es Stellen, die tief im Betriebssystem verwurzelt sind und die auch die Funktion des Autostarts besitzen. Ein Beispiel hierfür sind bestimmte Positionen der Registry, wie unter anderem die Schlüssel RUN oder RUNONCE.

Es werden alle Programme geladen, die sich in den folgenden Registry-Schlüsseln befinden:

• HKLM(HKEY_LOCAL_MACHINE)\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce (nur einmal, danach wird der Schlüssel gelöscht)
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices (als Systemdienst, nur mit Windowssystemen, die auf NT basieren, möglich)
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce (nur einmal)

Die Befehle in den Pfaden dieser Schlüssel werden für alle Benutzer gestartet. Eine Ausnahme bildet der abgesicherte Modus, normalerweise werden hier keine dieser Schlüssel beachtet.

• HKCU(HKEY_CURRENT_USER)\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce (nur einmal, danach wird der Schlüssel gelöscht)
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices (als Systemdienst, nur mit Windowssystemen, die auf NT basieren, möglich)
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce (nur einmal)

Die Befehle in den Pfaden dieser Schlüssel werden nur für den aktuellen Benutzer gestartet. Eine Ausnahme bildet der abgesicherte Modus.

Des Weiteren ist es möglich, dass sich Prozesse als Dienst (HKLM\SYSTEM\CurrentControlSet\Services\) installieren und ebenfalls bei jedem Systemstart im Hintergrund starten, dem Benutzer allerdings meist verborgen bleiben. Fast alle Viren- und Schadprogramme schreiben sich selbsttätig in die Registry in einen dieser Schlüssel oder installieren sich als Dienst, um sicherzustellen, dass sie bei jedem Systemstart ausgeführt werden.

Das automatische Starten von Programmen beim Booten kann unter Microsoft Windows durch Halten der Umschalttaste während des Bootvorgangs verhindert werden. Bei älteren Windows-Versionen ist der Autostart auch in der WIN.INI-Datei durch die Einträge load= oder run= möglich.

Spezielle Software zum Bearbeiten von Autostart-Einträgen bietet meist eine automatische Sicherung an. Es gibt auf dem Markt eine ganze Reihe an kostenloser und kostenpflichtiger Software, die diese Arbeit beherrschen. Ab Windows 8 könnte für einige Nutzer eine solche zusätzliche Software unnötig werden. Das Betriebssystem bietet selbst eine neue und benutzerfreundlichere Möglichkeit zur Verwaltung der Autostart-Einträge.^[1]

Autostart-Einträge lassen sich mit dem Programm msconfig bearbeiten, einem Systemtool von Microsoft Windows. Auch das kostenlose Programm Autoruns von Windows Sysinternals kann die Programme, die sich (meist automatisch) in den Autostart eingetragen haben, deaktivieren und das Booten dadurch beschleunigen. Autoruns bietet im Vergleich zu msconfig umfangreichere Konfigurationsmöglichkeiten.

Unter PC DOS und MS-DOS erfüllt die Stapelverarbeitungsdatei AUTOEXEC.BAT diesen Zweck. Alle Kommandos, die darin eingetragen sind, werden beim Systemstart automatisch ausgeführt. In den meisten kompatiblen DOS-Varianten wird zur Wahrung der Kompatibilität derselbe Autostart-Dateiname verwendet, obwohl es teilweise auch zusätzliche alternative Startdateien, meist mit angelehntem Dateinamen, gibt.

Unter Unix und unixartigen Betriebssystemen werden traditionell Shellskripte für diverse init-Systeme genutzt. Moderne SysVinit-Alternativen hingegen verwenden meist eigene Konfigurationsdateien, beispielsweise systemd unter Linux. Die Nutzung von „Startskripten“ ist damit in großem Maße von der verwendeten Distribution und den Vorlieben des Administrators abhängig.

Shell	Benutzer-Konfigurationsdatei (Autostart-Shellskript)[2]
	login	interaktiv
Bourne-Shell, sh	.profile
Bourne-Again-Shell, bash	.bash_profile, .bash_login oder .profile	.bashrc
C-Shell, csh	.login	.cshrc
TENEX-C-Shell, tcsh	.login	.tcshrc
Kornshell, ksh	.login
Z shell, zsh	.zlogin oder .zprofile	.zshrc

Die systemweiten Startskripte von SysVinit-kompatiblen init-Systemen finden sich meist in gesonderten Verzeichnissen innerhalb von /etc. Der Start von Shellskripten wird dabei über Runlevels gesteuert, damit gestartete Dienste bzw. Daemons somit je nach gefordertem Runlevel ausgeführt oder beendet. Durch solche Rekursionen ist es möglich, ein System vollautomatisch in einen gewünschten Zustand zu versetzen, ohne zur Laufzeit Befehle eingeben zu müssen.

Zusätzlich werden bei Unix-Systemen üblicherweise benutzerspezifische Autostart-Skripte von der Login-Shell oder vom Fenstermanager gestartet. Die klassischen Unix-Shells, die per Befehlszeile bedient werden, kennen jeweils einen bestimmten Dateinamen im Benutzerverzeichnis, der von der Shell automatisch ausgeführt wird. Bei der Bourne-Shell von UNIX V7 von 1977/1978 war dies .profile. Jede Unix-Shell nutzt eigene Dateinamen und unterscheidet dabei meist, ob der Start als Login-Shell oder als interaktive Shell erfolgt ist.^[2]

Unter macOS wurden bis Version 10.3 sogenannte StartUp Items verwendet, um den Zweck eines Autostarts zu erfüllen. Ab Version 10.4. sind die Launch Services hierfür zuständig.

Unter AmigaDOS wird beim Bootvorgang die Batchskript-Datei startup-sequence ausgeführt. Die Datei muss sich im Verzeichnis s des Bootmediums befinden. Daneben gibt es noch die user-startup für Programme ohne Piktogramm.

Durch die Amiga Workbench werden alle Programme im Ordner WBStartup ausgeführt. Der Tooltype STARTPRI legt dabei die Reihenfolge fest.

Bei CP/M 2.2 gibt es einen default command buffer, eine einzelne Kommandozeile, die beim Systemstart ausgeführt wird. Sollen mehrere Befehle ausgeführt werden, so kann das mittels SUBMIT-Befehl bewerkstelligt werden, z. B. SUBMIT.COM AUTOEXEC.SUB, wobei der Name der Autostart-Datei im Rahmen der CP/M-Dateinamenkonventionen frei wählbar ist.

Bei CP/M 3 bzw. CP/M Plus gibt es eine der autoexec.bat entsprechende Datei namens PROFILE.SUB, die beim Systemstart ausgeführt wird.^[3]

Unter ProDOS wird die BASIC-Datei STARTUP BAS beim Systemstart ausgeführt.

Unter OpenVMS wird SYS$MANAGER:SYLOGIN.COM ausgeführt.

Unter Multics wird start_up.ec ausgeführt.

• AutoRuns von SysInternals/Microsoft – ermöglicht das Bearbeiten und Löschen von Autostart-Einträgen
• Using Startup Items in Mac OS X (Memento vom 3. Januar 2011 im Internet Archive) – How-To für Mac OS X StartUp Items (englisch)

1. ↑ Autostart unter Windows 8 videonerd.de
2. ↑ ^{a b} Keith Bradnam, Ian Korf: Unix and Perl to the Rescue! – A field guide for the life sciences (and other data-rich pursuits). Cambridge University Press, 2012, ISBN 978-1-107-00068-1, 3.25 Creating a configuration file, S. 86, What is the configuration file called? (englisch, eingeschränkte Vorschau in der Google-Buchsuche): “Different shells tend to use differently named files to store your configuration settings…” 
3. ↑ CP/M Plus Operating System Command Summary. (PDF) Digital Research, März 1984, S. 60 (PDF Seite 64), abgerufen am 11. März 2016 (englisch).