News Windows: Was ist besser? EXE- oder MSI-Installer

Wenn ich das richtig verstanden habe bisher, dann wird über die MSI immer eine uninstall routine erstellt, während das bei der exe eben nicht passieren muss.

.msi ist, wie beschrieben, ein Script für ein ohnehin bestehendes Tool. Das kann besagtes Tool auch rückwärts ablaufen lassen und so installieren, aber es gibt keine eigenständige Deinstallationsroutine oder überhaupt irgendwas eigenständiges. Was man spätestens dann merkt, wenn mal wieder was auf anderem Wege gelöscht wurde und der Verweis auf das Script aus der Windows-Anwendungen-Liste ins Leere führt oder wenn diverse nicht direkt installierte, sondern erst später während der Laufzeit generierte Inhalte zurückbleiben.

Ich persönlich bin weiterhin für "gar nicht installieren". Einfach hinkopieren und komplett innerhalb des eigenen Ordner ausführen, fertig. Speicherplatz ist längst so billig, dass man sich die paar durch gemeinsam genutzte, zentrale Ressourcen vermiedenen Megabyte einfach schenken kann, zumal Änderungen daran für viele Probleme verantwortlich sind. Und die Abtrennung zwischen Benutzerkonten ist 90 Prozent der Anwender und Anwendungen auch egal respektive für weitere 5 Prozent zu löchrig.
 
Ich persönlich bin weiterhin für "gar nicht installieren".
Das geht nicht, wenn man einen Service oder Treiber braucht. Und, ja, die haben ihren Sinn.

Ein sauberes Uninstall sollte auch 'Arbeitsdaten' (also gecachte Daten, precompiled usw.) die nach ProgramData gehören, mit entsorgen. Und das geht nur mit uninstaller.

Und, nein, diese Daten gehören *nicht* ins Programmverzeichnis.
 
Zuletzt bearbeitet:
Die Zahl der nicht-Betriebssystem-Funktionen, deren Implementation als Treiber oder systemweiter Service sinnvoll oder gar nötig ist, kann man bei Endanwender-Software an einer Hand abzählen. Und da ist sowas wie .net dann schon dabei, wo ich bis heute verstehe, wieso das nicht seit jeher Teil von Windows ist. 99 Prozent der Installationen, die der durchschnittliche Spieler auf seinem System vornimmt, dienen nur ihrer selbst oder maximal noch der Öffnung eines bestimmten Dateiformats. Ausgerechnet die Registry-Verknüpfungen für letzteres sind meist nicht Bestandteil der regulären Installation, sondern werden erst nach Start der Anwendung durchgeführt. Selbige könnte man also genauso gut ohne Installation in Ordnern laufen lassen. Ironischerweise wird das ausgerechnet bei Browsern, also den Programmen, auf die am häufigsten von Dritten abgestellt wird, sogar durch die Bank möglich und vergleichsweise weit verbreitet

Die Unsitte, viele Gigabyte in \Roaming\ zu parken, begrüße ich übrigens auch nicht. Fix benötigte Daten gehören in das Programmverzeichnis, wenn man Multi-User-Standards implementiert (s.o.: mich stören sie nur) vielleicht auch in den jeweiligen Dokumente-Ordner; temporäre Dateien gehören nach \temp\, wo sie für Anwender und Datenträgerbereinigung als solche erkennbar sind. Windows ist nicht Android oder ChromeOS, wo der Anwender aus dem Dateisystem verbannt ist – und wo Software nur kuratiert und geprüft aus zentraler Quelle bereitgestellt wird, die verhindert, dass irgend ein Dümmster Anzunehemender Entwickler den Massenspeicher mit 12 GiB Crash-Logs in einem weder für User noch Datenträgerbereinigung sichtbaren Ordner zumüllt.
 
Ok, Torsten, wenn Du es besser weißt als MS, die die Richtlinien vorgeben und dafür auch ihre Gründe haben (z.B. warum es ein ProgramData gibt), dann will ich Dir diese Gewissheit nicht nehmen. Dass Dir vlt. nicht alle Fakten bekannt sind, muss Dich dabei nicht stören.

In /Roaming gehört gar nichts, außer Daten, die der User auf jedem Rechner immer verfügbar haben muss (es ist eben für das Roaming Profile gedacht, dass nach dem Logout mit dem Server synchronisiert wird). ProgramData ist das Temp Verzeichnis für nicht-flüchtige Daten, die aber nicht zu einem konkreten User gehören. Das ins Temp zu bringen wäre oft fatal. Es sind einfach zwei verschiedene Dinge.

Im Unix Speak wäre /var/tmp das Temp-Verzeichnis und alles andere unter /var entspricht dem ProgramData unter Windows.

Dass Dateiverknüpfungen von der Applikation gemacht werden, ist eine Unsitte einiger weniger Programme (7zip). Browser machen das vermutlich, weil sie damit den Anwender permanent nerven können. Von "meist" würde ich da nicht sprechen. Zumal man im Allg. Admin-Rechte braucht, um die Verknüpfungen zu ändern (es sei denn, man hat einen Service im Hintergrund, den man dafür missbrauchen kann).

Im Programm-Verzeichnis selbst sollten generell keine dynamischen Daten stehen. Das Programmverzeichnis ist für den User normal zum Schreiben gesperrt und das ist in einem Multi-User System auch sehr gut so. Ich hoffe, ich muss Dir nicht erklären, warum.
 
Nö, musst du nicht. Auch für andere Diskussionsteilnehmer wäre es aber vielleicht interessant, wieso du Richtlinien für Multi-User- und Server-basierte-Umgebungen als Argument gegen eine Meinung erachtest, die mit Verweis auf die Single-User-Praxis ausdrücklich deren Kosten-Nutzenverhältnis in Frage stellt? Zumal es, wie du ja selbst sagst, Alternativen für alternative Nutzungsszenarien gibt.
 
Nö, musst du nicht. Auch für andere Diskussionsteilnehmer wäre es aber vielleicht interessant, wieso du Richtlinien für Multi-User- und Server-basierte-Umgebungen als Argument gegen eine Meinung erachtest, die mit Verweis auf die Single-User-Praxis ausdrücklich deren Kosten-Nutzenverhältnis in Frage stellt? Zumal es, wie du ja selbst sagst, Alternativen für alternative Nutzungsszenarien gibt.
Nun ja, Windows ist nun mal ein Multi-User System und die Richtlinien sind daraus entstanden.

Jeder kann natürlich auf seinem System machen was er will und das ist ja auch das schöne an einem offenen System. Meinetwegen installiert man alles in ein Verzeichnis, das globale Schreibrechte hat.

Nur: Wenn man kritisiert warum bestimmte Dinge sind so wie sie sind, sollte man schon auch immer mit berücksichtigen, was die Motivation hinter den Richtlinien ist - nur dann kann eine Kritik auch wirklich Sinn machen. So sehe ich das jedenfalls.
 
MS hält sich doch selber nicht an ihre Vorgaben. Wofür haben sie den Savegames-Ordner eingeführt? Nicht nur, das beinahe jeder Entwickler die Savegames überall in AppData verstreut, nein, MS macht das mit seinen X-Box-Spielen genauso. Das nervt echt, weil es die Sicherung von Saves extrem erschwert. Und da man AppData nicht einfach so verschieben kann, müllt es im Laufe der Zeit c: zu.
 
AppData ist sowieso ein Mysterium. Daten, die zum User-Profil gehören, aber vom Betriebssystem versteckt werden.

Auf so was kann nur MS kommen.

Und es gibt ja nicht nur ein Savegame Ordner. Es gibt mindestens drei verschiedene Konventionen. Leider kenne ich die Historie nicht, wie das entstanden ist.

Wie so vieles wachsen bestimmte Dinge und es hält sich sowieso keiner an Standards. Was das größte Problem ist, wenn man hinterher als Hersteller mal was korrigieren will....
 
Zurück