Prüfmethoden für Updates

[Sir Rufo]

• Updater als geplanter Task
  Das diese Möglichkeit nicht genutzt wird liegt daran, dass der Updater mit Admin-Rechten laufen muss. Ein geplanter Task kann das, aber wenn das Kennwort für den Account geändert wurde, dann lief der Task nicht mehr. Neuere Versionen von Windows (ab Vista? auf jeden Fall ab Win7) haben das Problem nicht mehr.
  
  Mal sehen, ob sich da etwas ändert, wenn XP so langsam verschwindet (verschwindet es wirklich?). Bis dahin ist das also keine empfehlenswerte Option.
• Updater als Dauerdienst
  Ist wohl ein Märchen, dass ein Dienst dauernd laufen muss, aber ein vernünftig geschriebener verbraucht eigentlich so gut wie keine nennenswerte Ressourcen.
• Genereller Updater
  Hier wäre MS eigentlich der richtige Initiator. Aber die haben doch dafür schon lange was im Säckel:
  MSI-Pakete und die Gruppenrichtlinien in Verbindung mit einer Domäne. Ok, das ist eher im gewerblichen Umfeld anzutreffen und die Kontrolle hat der Domänenverwalter (was auch gut ist).
  
  Die neueren Versionen (>Win8) haben ja jetzt auch einen AppStore und da sind Updates auch kein Problem mehr.

Ich frage mich gerade, warum hier überhaupt von einzelnen Dateien gesprochen wird und nicht von einem Setup-Paket. Nur so kann man doch gewährleisten, dass alle zusammengehörigen Teile zuverlässig ausgeliefert werden, sich an der richtigen Stelle befinden und auch alte obsolete Dateien von der Platte verschwinden. Wer Angst vor zu großen Setup-Dateien hat kann ja auch spezielle Update-Pakete schnüren (würde ich trotzdem nicht empfehlen, da idR Pflege-Aufwand und Nutzen in keinem angemessenen Verhältnis stehen). Zusätzliche Treiber, Bibliotheken, etc. können vom Setup auch noch bei Bedarf nachgeladen und installiert werden.

In dem Fall kann dann auch der Updater selber strunz-doof sein (Auf neue Version prüfen, Setup laden, Setup ausführen) und der wird auch das wildeste Update hinbekommen - weil diese Aufgabe das Setup übernimmt.