Hallo TCM Freunde,
ich habe den Total Commander 7.50a jetzt mal als MSI Installationsprogramm erstellt.
Das Paket kann hier herunter geladen werden:
>> svsdownloads . de << im Download-Bereich => Tools & Utilities.
Sowohl die Registrierung als auch der Download sind kostenfrei!
Da das Setup kein offizielles Setup von C. Ghisler ist macht es wohl wenig Sinn entsprechende Fragen an ihn zu posten.
Bei Problemen, Fragen oder Hinweisen bitte entweder auf dieses Thema hier posten oder das Kontaktformular bei svsdownloads.de benutzen.
Im Download ist auch eine kleine Doku dabei, wie man den TCM silent installieren kann.
Selbstverständlich handelt es sich um eine unlizensierte Version des TCM!
Anregungen nehme ich gerne entgegen.
vg,
Hans
TCM 7.50a als MSI Installations-Programm
Moderators: Hacker, Stefan2, white
-
sqa_wizard
- Power Member
- Posts: 3893
- Joined: 2003-02-06, 11:41 UTC
- Location: Germany
Es gibt eine Reihe von Vorteilen einer .MSI Installation im Vergleich zu einer .EXE Installation.
Um nur mal ein paar zu nennen:
* Selbst Reparatur
Wenn Dateien einer Anwendung aus welchen Gründen auch immer mal gelöscht wurden (oder die eine Version einer Datei durch eine ältere überschrieben wurde), so startet beim nächsten Start der Anwendung der MSI Self-Repair Mechanismus und korrigiert entsprechende Probleme.
* Roll back
Bricht eine Installation mitten drin oder gar ganz am Ende aus welchen Gründen auch immer ab, so wird ein roll-back durchgeführt, es wird also wieder derjenige Systemzustand hergestellt, der vor Installationbeginn vorhanden war.
* Anpassungen des Installationsverhaltens sind einfach umsetzbar
Viele Kunden in größeren Systemumgebungen wollen nicht, dass Anwendungen ShortCuts auf dem Desktop installieren. Z.B. mit Orca (ein freies Tool von Microsoft) kann man relativ einfach ein sogenanntes TRANSFORM erzeugen, mit dessen Hilfe man fast alle notwendigen Anapssungen an einem MSI Setup durchführen kann.
Es gibt viele Vorteile eines .MSI Setups im Vergleich zu den traditionellen .EXE Setups, einfach mal googeln.
Fast alle Firmen, die eine Anwendung zum Teil auf tausende von PCs installieren müssen, verwenden MSI Installationsroutinen.
Wenn der Hersteller bereits ein .MSI Setup ausliefert, prima, das muss man dann "nur noch" anpassen (per TRASNFORM). Liefert der Hersteller eine .EXE Installation, so wird dieses i.d.R. zu einem .MSI Setup "repaketiert".
Ich habe das in vielen Unternehmen so erlebt.
Tatsächlich ist es so, dass man bei einer manuellen Einzelplatz-Installation sehr gut mit einem .EXE Setup leben kann. Der Unterschied wird hauptsächlich bei Massen-Rollouts sichtbar. Viele Installation müssen benutzerlos (silent) aber angepaßt, UND vor allen Dingen ZUVERLÄSSIG durchgeführt werden. In diesen Disziplinen ist eine .MSI Installation i.d.R. im Vorteil. Aber es gibt bekanntlich keine Regel ohne Ausnahme. Es gibt wirklich schlechte MSI Setups (siehe WinZip - hier wird MSI nur als Hülle verwendet, die Vorteile der MSI Technologie fallen damit hinten runter, wichtige Anpassungen sind eigentlich nicht mehr per MSI Techniken machbar). Es gibt aber auch sehr gute .EXE Installation!
Meine Idee mit dem MSI Setup ist es einfach nur ein entsprechendes MSI Setup zur Verfügung zu stellen.
Meine Entwicklung stelle ich gerne und kostenfrei zur verfügung. Wer möchte kann ja gerne weitere Anpassungen vornehmen und vielleicht wird es in Zukunft ja auch mal ein offizielles MSI Setup geben?! Meine Sourcen und bisherigen Entwicklungen stelle ich gerne zur verfügung.
Das MSI Setup wurde übrigens mit Tools von Wise (heute Symantec) entwickelt.
@lefteous
Man kann per Group-Policies Anwendungen auf meherer Rechner verteilen. Vorraussetzung ist dabei, dass das Setup im .MSI Format vorliegt.
@sqa_wizard
Ich schätze Du kennst Dich nicht sehr gut mit der MSI Technologie aus, andernfalls würdest Du sicherlich nicht von "Schrott" sprechen
. Was Du vermutlich meinst sind die MSI internen Registry Keys. Warum Du dabei von Schrott sprichts kann ich zumindest nicht nachvollziehen. Es sind gerade dieses Keys/Mechanismen, die die MSI Technologie so erfolgreich macht, und die erst die entsprechenden Vorteile, von denen ich nur ein paar wenige erwähnt habe, möglich machen. Woher kommt wohl der Begriff DLL-Hell??? Wenn man MSI versteht und richtig einsetzt hat man in dieser Hinsicht tatsächlich ein paar Probleme weniger. Also ganz so einfach ist das mit dem Schrott nicht .
VG,
Hans
Um nur mal ein paar zu nennen:
* Selbst Reparatur
Wenn Dateien einer Anwendung aus welchen Gründen auch immer mal gelöscht wurden (oder die eine Version einer Datei durch eine ältere überschrieben wurde), so startet beim nächsten Start der Anwendung der MSI Self-Repair Mechanismus und korrigiert entsprechende Probleme.
* Roll back
Bricht eine Installation mitten drin oder gar ganz am Ende aus welchen Gründen auch immer ab, so wird ein roll-back durchgeführt, es wird also wieder derjenige Systemzustand hergestellt, der vor Installationbeginn vorhanden war.
* Anpassungen des Installationsverhaltens sind einfach umsetzbar
Viele Kunden in größeren Systemumgebungen wollen nicht, dass Anwendungen ShortCuts auf dem Desktop installieren. Z.B. mit Orca (ein freies Tool von Microsoft) kann man relativ einfach ein sogenanntes TRANSFORM erzeugen, mit dessen Hilfe man fast alle notwendigen Anapssungen an einem MSI Setup durchführen kann.
Es gibt viele Vorteile eines .MSI Setups im Vergleich zu den traditionellen .EXE Setups, einfach mal googeln.
Fast alle Firmen, die eine Anwendung zum Teil auf tausende von PCs installieren müssen, verwenden MSI Installationsroutinen.
Wenn der Hersteller bereits ein .MSI Setup ausliefert, prima, das muss man dann "nur noch" anpassen (per TRASNFORM). Liefert der Hersteller eine .EXE Installation, so wird dieses i.d.R. zu einem .MSI Setup "repaketiert".
Ich habe das in vielen Unternehmen so erlebt.
Tatsächlich ist es so, dass man bei einer manuellen Einzelplatz-Installation sehr gut mit einem .EXE Setup leben kann. Der Unterschied wird hauptsächlich bei Massen-Rollouts sichtbar. Viele Installation müssen benutzerlos (silent) aber angepaßt, UND vor allen Dingen ZUVERLÄSSIG durchgeführt werden. In diesen Disziplinen ist eine .MSI Installation i.d.R. im Vorteil. Aber es gibt bekanntlich keine Regel ohne Ausnahme. Es gibt wirklich schlechte MSI Setups (siehe WinZip - hier wird MSI nur als Hülle verwendet, die Vorteile der MSI Technologie fallen damit hinten runter, wichtige Anpassungen sind eigentlich nicht mehr per MSI Techniken machbar). Es gibt aber auch sehr gute .EXE Installation!
Meine Idee mit dem MSI Setup ist es einfach nur ein entsprechendes MSI Setup zur Verfügung zu stellen.
Meine Entwicklung stelle ich gerne und kostenfrei zur verfügung. Wer möchte kann ja gerne weitere Anpassungen vornehmen und vielleicht wird es in Zukunft ja auch mal ein offizielles MSI Setup geben?! Meine Sourcen und bisherigen Entwicklungen stelle ich gerne zur verfügung.
Das MSI Setup wurde übrigens mit Tools von Wise (heute Symantec) entwickelt.
@lefteous
Man kann per Group-Policies Anwendungen auf meherer Rechner verteilen. Vorraussetzung ist dabei, dass das Setup im .MSI Format vorliegt.
@sqa_wizard
Ich schätze Du kennst Dich nicht sehr gut mit der MSI Technologie aus, andernfalls würdest Du sicherlich nicht von "Schrott" sprechen
. Was Du vermutlich meinst sind die MSI internen Registry Keys. Warum Du dabei von Schrott sprichts kann ich zumindest nicht nachvollziehen. Es sind gerade dieses Keys/Mechanismen, die die MSI Technologie so erfolgreich macht, und die erst die entsprechenden Vorteile, von denen ich nur ein paar wenige erwähnt habe, möglich machen. Woher kommt wohl der Begriff DLL-Hell??? Wenn man MSI versteht und richtig einsetzt hat man in dieser Hinsicht tatsächlich ein paar Probleme weniger. Also ganz so einfach ist das mit dem Schrott nicht .VG,
Hans
Hans
jetzt musst du das Thema nahezu identisch zweisprachig führen ....
http://ghisler.ch/board/viewtopic.php?t=24969
Aber, so halb off-topic:
Wir haben Programm A mit MSI installiert, eine neuere Version des Programms B (kleiner Bruder von A) mit einem Setup von CD. B hat einige mit A gemeinsame Dateien aufgefrischt, und das MSI von A spielt jetzt bei jedem Start die alten gemeinsamen Daten zurück. Gibt es eine einfache Lösung (ausser Umbau der MSI von A)?
Peter
jetzt musst du das Thema nahezu identisch zweisprachig führen ....
http://ghisler.ch/board/viewtopic.php?t=24969
Aber, so halb off-topic:
Wir haben Programm A mit MSI installiert, eine neuere Version des Programms B (kleiner Bruder von A) mit einem Setup von CD. B hat einige mit A gemeinsame Dateien aufgefrischt, und das MSI von A spielt jetzt bei jedem Start die alten gemeinsamen Daten zurück. Gibt es eine einfache Lösung (ausser Umbau der MSI von A)?
Peter
TC 10.xx / #266191
Win 10 x64
Win 10 x64
Ja ... das mit den zwei Sprachen ist so eine Sache.
Mal schauen wie ich aus der Nummer wieder rauskomme
Im Eventlog bekommt man angezeigt, warum ein MSI Repair getriggert wurde. Das könnte schon mal genauere Hinweise liefern über das "warum".
Wenn eine Anwendung schon installiert ist und man keine Möglichkeit mehr hat auf die Installation selbst Einfluß zu nehmen, dann sollte es zumindest möglich sein die installierten originalen MSI ShortCuts (die vermutlich bzw. offensichtlich als sogenannte "advertised ShortCuts ausgeführt sind) durch selbst erstellte .LNK zu ersetzen. "Advertised ShortCuts starten nicht die Anwendung direkt sondern sind sogenannte "entry points", d.h. der Anwendungsstart nimmt einen "Umweg" über die MSI Technologie und überprüft die "korrekte" Installation der Anwendung vor deren Start. Ersetzt man also diese ShortCuts durch "normale" ShortCuts" passiert dies nicht mehr.
Warum allerdings ein MSI Repair durchgeführt wird, wo doch eine ältere Programm Version durch eine neuere ersetzt wurde ist im ersten Moment nicht einsichtig. Aber neue Programm Version muß im Einzelfall nicht unbedingt neuere Dateien bedeuten (leider, darum gibt es ja die DLL-Hell), das müsste man im Detail analysieren.
vg,
Hans
Mal schauen wie ich aus der Nummer wieder rauskomme
Im Eventlog bekommt man angezeigt, warum ein MSI Repair getriggert wurde. Das könnte schon mal genauere Hinweise liefern über das "warum".
Wenn eine Anwendung schon installiert ist und man keine Möglichkeit mehr hat auf die Installation selbst Einfluß zu nehmen, dann sollte es zumindest möglich sein die installierten originalen MSI ShortCuts (die vermutlich bzw. offensichtlich als sogenannte "advertised ShortCuts ausgeführt sind) durch selbst erstellte .LNK zu ersetzen. "Advertised ShortCuts starten nicht die Anwendung direkt sondern sind sogenannte "entry points", d.h. der Anwendungsstart nimmt einen "Umweg" über die MSI Technologie und überprüft die "korrekte" Installation der Anwendung vor deren Start. Ersetzt man also diese ShortCuts durch "normale" ShortCuts" passiert dies nicht mehr.
Warum allerdings ein MSI Repair durchgeführt wird, wo doch eine ältere Programm Version durch eine neuere ersetzt wurde ist im ersten Moment nicht einsichtig. Aber neue Programm Version muß im Einzelfall nicht unbedingt neuere Dateien bedeuten (leider, darum gibt es ja die DLL-Hell), das müsste man im Detail analysieren.
vg,
Hans
Das ist mir vermutlich zu hoch, aber ich weiss, dass die Startlinks die original EXE von Programm A aufrufen. Was dann MSI so treibt weiss ich nicht, aber wenn ich das Eventlog finde - wo sollte das sein? - weiss ich vielleicht mehr (aber erst nach den Ferien ...)habi wrote:...Wenn eine Anwendung schon installiert ist und man keine Möglichkeit mehr hat auf die Installation selbst Einfluß zu nehmen, dann sollte es zumindest möglich sein die installierten originalen MSI ShortCuts (die vermutlich bzw. offensichtlich als sogenannte "advertised ShortCuts ausgeführt sind) durch selbst erstellte .LNK zu ersetzen. "Advertised ShortCuts starten nicht die Anwendung direkt sondern sind sogenannte "entry points", d.h. der Anwendungsstart nimmt einen "Umweg" über die MSI Technologie und überprüft die "korrekte" Installation der Anwendung vor deren Start. Ersetzt man also diese ShortCuts durch "normale" ShortCuts" passiert dies nicht mehr....
Peter
TC 10.xx / #266191
Win 10 x64
Win 10 x64
-
sqa_wizard
- Power Member
- Posts: 3893
- Joined: 2003-02-06, 11:41 UTC
- Location: Germany
Zugegeben, das Wort "Schrott" ist sehr verallgemeinert.@sqa_wizard
Ich schätze Du kennst Dich nicht sehr gut mit der MSI Technologie aus, andernfalls würdest Du sicherlich nicht von "Schrott" sprechen
Das was ich an vorhandenen MSI-Installationen bisher gesehen habe:
- bringt häufig viele fremde (nicht programmspezifische) Registry Einträge mit
- belegt ein vielfaches mehr an Speicherplatz als das originale Programm
- verhindert ein manuelles Update einzelner Dateien des Paketes
- hebelt den internen Update Modus aus (z.B. TC: wincmd.ini, default.bar werden überschrieben)
- hinterläßt nach einer Deinstallation noch Reste in Registry und Dateisystem
Das sind meine persönlichen Erfahrungen damit.
Es mag in einem streng kontrollierten Firmennetzwerk sogar erwünscht oder akzeptabel sein, für mich ist es nur abschreckend.
#5767 Personal license
@Peter
Auf einem deutschen Client heißt das Eventlog "Ereignisanzeige.
Eine Möglichkeit die Ereignisanzeige aufzurufen ist z.B. über Start => Ausführen => eventvwr.exe. Dort bei "Anwendung" nachsehen. Wenn ein MSI Repair passiert werden dort immer zwei aufeinander folgende gelbe (= Warnung) Einträge erstellt. Dann mal einen Doppelklick auf einen der Einträge machen und man bekommt weitere Details. Insbesondere der erste (=untere) der beiden Einträge ist recht aufschlußreich.
@sqa_wizard
bringt häufig viele fremde (nicht programmspezifische) Registry Einträge mit
Stimmt. Das macht halt die MSI Technologie aus. Aber auch ein Nicht-MSI Setup erstellt oder ändert vielleicht Registry-Keys, die man auf den ersten Blick nicht sieht.
Z.B. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
Wenn eine Anwendung Dateien in Ordner kopiert, die auch von anderen Anwendungen benutzt werden, so sollte (!) diese Anwendung diesen Key "bedienen", also entsprechend seiner Bestimmung nutzen.
belegt ein vielfaches mehr an Speicherplatz als das originale Programm
Hmmm ... vielleicht ein bisschen mehr (siehe z.B. C:\Windows\Installer - dort werden "verkleinerte" MSIs zwischengespeichert), aber ein Vielfaches?? Aber da gibt es natürlich auch Office, und da kann man bei der Installation einstellen, ob auch die Installationsdateien lokal vorgehalten werden sollen. Das kann nützlich sein, wenn Office bestimmte Features (z.B. die Rechtschreibung) zu einem späteren Zeitpunkt nachinstallieren will/muß. Dumm wäre nämlich, wenn man bei einer solchen Nachinstallation (nennt sich "install on demand") gerade die CD/DVD nicht zur Hand hätte ....
verhindert ein manuelles Update einzelner Dateien des Paketes
Nicht grundsätzlich. Es ist kein Problem, ältere Dateien durch neuere zu ersetzen. Anders herum schon, aber so soll das auch sein.
Es kommt letztendlich immer darauf an, was man erreichen möchte oder muss, dementsprechend entwickelt der Entwickler das entsprechende MSI (hoffentlich).
hebelt den internen Update Modus aus (z.B. TC: wincmd.ini, default.bar werden überschrieben)
?? Gerade unversionierte Dateien (also z.B. default.bar) werden nicht einfach so durch ein neues MSI Paket überschrieben. Bei einer Programm-Deinstallation z.B. werden keine Dateien gelöscht, die sich seit der Erst-Installation geändert haben (Create-Date und Change-Date der Datei sind nicht mehr identisch). Existiert bei einer Neuinstallation einer Anwendung per MSI bereits eine (unversionierte) Datei in einem Verzeichnis, so wird diese dann nicht überschrieben, wenn Change-Date und Create-Date unterschiedlich sind (d.h. die Datei hat sich in der Vergangenheit mal geändert - das könnte ja wichtig sein - also überschreibt das MSI solche Dateien nicht einfach, selbst wenn die Datei in dem neuen MSI Paket neuer ist (!)).
Und bei INI Dateien ist das noch etwas ganz besonderes. INI Dateien werden immer (sofern man das "richtig" gemacht hat) EDITIERT, nicht überschrieben.
hinterläßt nach einer Deinstallation noch Reste in Registry und Dateisystem
Im Prinzip nicht (oder zumindest nichts kritisches), aber im Einzelfall schon, und dann muß das so sein. Abgesehen davon, dass das .EXE Installationen durchaus auch machen und diesbezüglich vielleicht sogar ein bisschen "großzügiger" sind
Also, wie man vielleicht hier schon erkennen kann - trivial ist die Entwicklung eines guten MSI Setups nicht, aber das gilt grundsätzlich auch für ein gutes .EXE Setup.
Aber ein Teufelszeug, das man verdammen muß ist es nun auch wieder nicht
vg,
Hans
Auf einem deutschen Client heißt das Eventlog "Ereignisanzeige.
Eine Möglichkeit die Ereignisanzeige aufzurufen ist z.B. über Start => Ausführen => eventvwr.exe. Dort bei "Anwendung" nachsehen. Wenn ein MSI Repair passiert werden dort immer zwei aufeinander folgende gelbe (= Warnung) Einträge erstellt. Dann mal einen Doppelklick auf einen der Einträge machen und man bekommt weitere Details. Insbesondere der erste (=untere) der beiden Einträge ist recht aufschlußreich.
@sqa_wizard
bringt häufig viele fremde (nicht programmspezifische) Registry Einträge mit
Stimmt. Das macht halt die MSI Technologie aus. Aber auch ein Nicht-MSI Setup erstellt oder ändert vielleicht Registry-Keys, die man auf den ersten Blick nicht sieht.
Z.B. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
Wenn eine Anwendung Dateien in Ordner kopiert, die auch von anderen Anwendungen benutzt werden, so sollte (!) diese Anwendung diesen Key "bedienen", also entsprechend seiner Bestimmung nutzen.
belegt ein vielfaches mehr an Speicherplatz als das originale Programm
Hmmm ... vielleicht ein bisschen mehr (siehe z.B. C:\Windows\Installer - dort werden "verkleinerte" MSIs zwischengespeichert), aber ein Vielfaches?? Aber da gibt es natürlich auch Office, und da kann man bei der Installation einstellen, ob auch die Installationsdateien lokal vorgehalten werden sollen. Das kann nützlich sein, wenn Office bestimmte Features (z.B. die Rechtschreibung) zu einem späteren Zeitpunkt nachinstallieren will/muß. Dumm wäre nämlich, wenn man bei einer solchen Nachinstallation (nennt sich "install on demand") gerade die CD/DVD nicht zur Hand hätte ...
. verhindert ein manuelles Update einzelner Dateien des Paketes
Nicht grundsätzlich. Es ist kein Problem, ältere Dateien durch neuere zu ersetzen. Anders herum schon, aber so soll das auch sein.
Es kommt letztendlich immer darauf an, was man erreichen möchte oder muss, dementsprechend entwickelt der Entwickler das entsprechende MSI (hoffentlich).
hebelt den internen Update Modus aus (z.B. TC: wincmd.ini, default.bar werden überschrieben)
?? Gerade unversionierte Dateien (also z.B. default.bar) werden nicht einfach so durch ein neues MSI Paket überschrieben. Bei einer Programm-Deinstallation z.B. werden keine Dateien gelöscht, die sich seit der Erst-Installation geändert haben (Create-Date und Change-Date der Datei sind nicht mehr identisch). Existiert bei einer Neuinstallation einer Anwendung per MSI bereits eine (unversionierte) Datei in einem Verzeichnis, so wird diese dann nicht überschrieben, wenn Change-Date und Create-Date unterschiedlich sind (d.h. die Datei hat sich in der Vergangenheit mal geändert - das könnte ja wichtig sein - also überschreibt das MSI solche Dateien nicht einfach, selbst wenn die Datei in dem neuen MSI Paket neuer ist (!)).
Und bei INI Dateien ist das noch etwas ganz besonderes. INI Dateien werden immer (sofern man das "richtig" gemacht hat) EDITIERT, nicht überschrieben.
hinterläßt nach einer Deinstallation noch Reste in Registry und Dateisystem
Im Prinzip nicht (oder zumindest nichts kritisches), aber im Einzelfall schon, und dann muß das so sein. Abgesehen davon, dass das .EXE Installationen durchaus auch machen und diesbezüglich vielleicht sogar ein bisschen "großzügiger" sind
Also, wie man vielleicht hier schon erkennen kann - trivial ist die Entwicklung eines guten MSI Setups nicht, aber das gilt grundsätzlich auch für ein gutes .EXE Setup.
Aber ein Teufelszeug, das man verdammen muß ist es nun auch wieder nicht
vg,
Hans
Ich würde sogar noch weiter gehen und das Verhalten von MSI-Installationen in die Nähe von malware-artigen, böswilligen Schad_Routinen rücken.habi wrote:@sqa_wizard
Ich schätze Du kennst Dich nicht sehr gut mit der MSI Technologie aus, andernfalls würdest Du sicherlich nicht von "Schrott" sprechen
Wieder einmal wird dabei von vor Selbstherrlichkeit überschäumenden "Besserwissern" versucht, die Kontrolle des autorisierten PC-Benutzers (Administrators) auszuhebeln und ohne dessen Wissen und vorherige ausdrückliche Zustimmung Änderungen an seinem Sytem, sei es nun beim Neustart oder gar laufend im Hintergrund, vorzunehmen. Natürlich erfolgt dieses ungebetene und unautorisierte "Dreinpfuschen" wie stets nur "zum besseren Wohle des unmündigen Benutzers".
Mir kommt da ein Vergleich aus dem Science-Fiction-Genre in den Sinn: Im Borg-Imperium aus der star-trek-saga nannte man so etwas "autonomous regeneration sequenzers - meant to counteract resistance"!
mfg
algol
Richtig.algol wrote:....die Kontrolle des autorisierten PC-Benutzers (Administrators) auszuhebeln und ohne dessen Wissen und vorherige ausdrückliche Zustimmung Änderungen an seinem Sytem...
Natürlich erfolgt dieses ungebetene und unautorisierte "Dreinpfuschen"...
Auch richtig.algol wrote:....wie stets nur "zum besseren Wohle des unmündigen Benutzers".
Ich gehe davon aus, dass sich hier im Forum eher die freiheitsliebenden "Admins" treffen, aber man darf die Anzahl und die Intensität der Unmündigkeit von "Benutzern" nicht unterschätzen. Und hier machen diese vollautomatischen Dinger schon Sinn - wenn ich an die Fotoapparate mit Lächelerkennung, die üblichen GPS-Navi-Gruselgeschichten und ähnlich vollautomatisches Zeug denke, dann wählen genug Leute diese Systeme freiwillig.
Aber zurück zur Grundfrage: Wenn Habi die Sache mit Ghisler abstimmt und er zustimmt, dann ist es gut - wer will, der kann, wer nicht will, braucht nicht. Und das TC-Original wird wahrscheinlich nicht auf MSI umgestellt werden - also können alle zufrieden sein.
Peter
TC 10.xx / #266191
Win 10 x64
Win 10 x64
Dem kann ich natürlich zustimmen.Peter wrote:Wenn Habi die Sache mit Ghisler abstimmt und er zustimmt, dann ist es gut - wer will, der kann, wer nicht will, braucht nicht.
Nicht zustimmen konnte ich lediglich der für mich entstandenen Optik, dass hier ein Träger imho mehr als berechtigter Bedenken gleichsam als einsamer, uninformierter "Modernisierungsverweigerer" übrig bleibt.
mfg
algol
Mir scheint ich bin hier jemand auf die Zehen getreten 
Sorry dafür, das war nicht meine Absicht.
Und um es auch klar zu sagen: Mir persönlich ist es völlig egal, ob jemand sein Programm in ein .MSI Setup kleidet oder in ein .EXE Setup, ich bin da wirklich leidenschaftslos.
Wenn man jetzt mal emotionale und in diesem Sinne durchaus nachvollziehbare Unbehaglichkeiten hinten anstellt (wir haben ja schließlich alle so unsere Erfahrungen gemacht) und sich auf eher technische Aspekte konzentriert, dann will ich gerne einfach nur noch mal ein paar eher technische Aspekte klarstellen oder zumindest zur Diskussion stellen.
Mein Eindruck ist, dass bei der Diskussion zwei Dinge nicht sauber getrennt werden:
(1) Die Anwendung, die installiert wird
(2) Die Methode, wie die entsprechend notwendigen Systemänderungen auf den Rechner kommen
Oder um ein Analogie zu bemühen:
* Das eine ist der Inhalt eines Briefes (die Anwendung)
* Das andere die Verpackung (die Installations-Technologie)
Die MSI-Installations-Technologie in die Nähe von Male-Ware zu rücken scheint mir absurd. MSI ist nicht der Inhalt sondern die Verpackung!
Es gibt noch einen ganz wesentlichen Unterschied zwischen der .EXE Installation-Technologie und der MSI Technologie:
==> Transparenz!
Eine .EXE Installation ist eine komplette Black-Box, man weiß überhaupt nicht, was da drin ist. Insofern könnte und sollte man gerade bei dieser Installations-Technologie kritisch sein!
Im Unterschied dazu steht die MSI Technologie. Eine .MSI Datei ist nichts anderes als eine Datenbank. Das msiexec.exe liest den Inhalt der .MSI Datei aus und installiert nach definierten (und offenen) Regeln entsprechende Dateien und Registry Keys.
Es gibt genug Werkzeuge um diese .MSI Dateien zu öffnen und um nachsehen zu können, was da passiert.
Um die Analogie zu bemühen: Eine MSI Verpackung ist so etwas wie eine Klarsichthülle. Im Gegensatz dazu ist eine EXE Verpackung ein nicht zu öffnender Tresor. Was da drin ist weiß man erst wenn es zu spät ist, ein vorher öffnen und nachschauen geht nicht.
Warum ausgerechnet die MSI Technologie so verteufelt wird kann ich deshalb nicht nachvollziehen.
Dass man auch MSI Setups intransparent machen kann ist unbestritten, siehe WinZip MSI Installation. Achtet mal darauf, an welcher Stelle die eigentlichen Konfigurationsdialoge erscheinen. Erst ganz am Ende, nachdem schon alle Dateien und alle Regkeys per MSI Technologie installiert wurden erscheinen die bekannten Konfigurationsdialoge. Die haben mit MSI nichts zu tun, das ist eine "black-box" Hersteller-DLL die aufgerufen wird.
Was ich auch - und zwar insbesondere aus technischer Sicht - nicht nachvollziehen kann ist diese Sache mit der "ungebetenen und unautorisierte "Dreinpfuschen". Wenn das so wäre, könnte man selbiges nicht ebenso einer .EXE Installation vorwerfen? Und was hat das mit mündigem oder unmündigem User zu tun???
Wie gesagt: MSI ist eine Installationstechnologie, kein Inhalt. Es ist dokumentiert und transparent, was man i.d.R. von den wenigsten .EXE Installationstechnologien sagen kann.
Ich habe eine TCM (bzg. Windows Commander) Lizenznummer aus dem 4tausender Bereich, die müsste so aus dem Jahre 1994/95 stammen.
Der TCM ist für mich wohl eins der besten und effektivsten Programme überhaupt und eine sehr gut gelungene Weiterentwicklung des guten alten Norton Commander (wer sich noch an die alten DOS Zeiten erinnert). Es freut mich sehr, dass der TCM auch in großen Unternehmen zum Einsatz kommt, das sichert Einnahmen für H. Ghisler und damit eine Weiterentwicklung des TCM, die uns wohl alle freut. Ich habe es schon erlebt, dass Programme aus Unternehmen nur deshalb rausgeflogen sind, weil es gleichartige Programme von anderen Herstellern gab, die weniger Installations-Streß gemacht haben. Da geht es nicht zwangsläufig um MSI oder EXE, oft sind es unzumutbare Lizensierungsprobleme o.a..
Dennoch: Aus dieser Sicht heraus sollte man das Thema MSI oder EXE nicht unterschätzen.
Vg,
Hans
Sorry dafür, das war nicht meine Absicht.
Und um es auch klar zu sagen: Mir persönlich ist es völlig egal, ob jemand sein Programm in ein .MSI Setup kleidet oder in ein .EXE Setup, ich bin da wirklich leidenschaftslos.
Wenn man jetzt mal emotionale und in diesem Sinne durchaus nachvollziehbare Unbehaglichkeiten hinten anstellt (wir haben ja schließlich alle so unsere Erfahrungen gemacht) und sich auf eher technische Aspekte konzentriert, dann will ich gerne einfach nur noch mal ein paar eher technische Aspekte klarstellen oder zumindest zur Diskussion stellen.
Mein Eindruck ist, dass bei der Diskussion zwei Dinge nicht sauber getrennt werden:
(1) Die Anwendung, die installiert wird
(2) Die Methode, wie die entsprechend notwendigen Systemänderungen auf den Rechner kommen
Oder um ein Analogie zu bemühen:
* Das eine ist der Inhalt eines Briefes (die Anwendung)
* Das andere die Verpackung (die Installations-Technologie)
Die MSI-Installations-Technologie in die Nähe von Male-Ware zu rücken scheint mir absurd. MSI ist nicht der Inhalt sondern die Verpackung!
Es gibt noch einen ganz wesentlichen Unterschied zwischen der .EXE Installation-Technologie und der MSI Technologie:
==> Transparenz!
Eine .EXE Installation ist eine komplette Black-Box, man weiß überhaupt nicht, was da drin ist. Insofern könnte und sollte man gerade bei dieser Installations-Technologie kritisch sein!
Im Unterschied dazu steht die MSI Technologie. Eine .MSI Datei ist nichts anderes als eine Datenbank. Das msiexec.exe liest den Inhalt der .MSI Datei aus und installiert nach definierten (und offenen) Regeln entsprechende Dateien und Registry Keys.
Es gibt genug Werkzeuge um diese .MSI Dateien zu öffnen und um nachsehen zu können, was da passiert.
Um die Analogie zu bemühen: Eine MSI Verpackung ist so etwas wie eine Klarsichthülle. Im Gegensatz dazu ist eine EXE Verpackung ein nicht zu öffnender Tresor. Was da drin ist weiß man erst wenn es zu spät ist, ein vorher öffnen und nachschauen geht nicht.
Warum ausgerechnet die MSI Technologie so verteufelt wird kann ich deshalb nicht nachvollziehen.
Dass man auch MSI Setups intransparent machen kann ist unbestritten, siehe WinZip MSI Installation. Achtet mal darauf, an welcher Stelle die eigentlichen Konfigurationsdialoge erscheinen. Erst ganz am Ende, nachdem schon alle Dateien und alle Regkeys per MSI Technologie installiert wurden erscheinen die bekannten Konfigurationsdialoge. Die haben mit MSI nichts zu tun, das ist eine "black-box" Hersteller-DLL die aufgerufen wird.
Was ich auch - und zwar insbesondere aus technischer Sicht - nicht nachvollziehen kann ist diese Sache mit der "ungebetenen und unautorisierte "Dreinpfuschen". Wenn das so wäre, könnte man selbiges nicht ebenso einer .EXE Installation vorwerfen? Und was hat das mit mündigem oder unmündigem User zu tun???
Wie gesagt: MSI ist eine Installationstechnologie, kein Inhalt. Es ist dokumentiert und transparent, was man i.d.R. von den wenigsten .EXE Installationstechnologien sagen kann.
Ich habe eine TCM (bzg. Windows Commander) Lizenznummer aus dem 4tausender Bereich, die müsste so aus dem Jahre 1994/95 stammen.
Der TCM ist für mich wohl eins der besten und effektivsten Programme überhaupt und eine sehr gut gelungene Weiterentwicklung des guten alten Norton Commander (wer sich noch an die alten DOS Zeiten erinnert
). Es freut mich sehr, dass der TCM auch in großen Unternehmen zum Einsatz kommt, das sichert Einnahmen für H. Ghisler und damit eine Weiterentwicklung des TCM, die uns wohl alle freut. Ich habe es schon erlebt, dass Programme aus Unternehmen nur deshalb rausgeflogen sind, weil es gleichartige Programme von anderen Herstellern gab, die weniger Installations-Streß gemacht haben. Da geht es nicht zwangsläufig um MSI oder EXE, oft sind es unzumutbare Lizensierungsprobleme o.a..Dennoch: Aus dieser Sicht heraus sollte man das Thema MSI oder EXE nicht unterschätzen.
Vg,
Hans
Hallo, Hans.
Das Setup Programm des Total Commanders dürfte unter dem Gesichtspunkt Transparenz gerade kein gutes Beispiel für Intransparenz sein.
MSI Installationspakete haben möglicherweise aus mehreren Gründen bei manchen(?)/vielen(?) Anwendern ein Akzeptanzproblem:
+ MSI stammt von Microsoft
+ manche Bloatware kommt als MSI Paket daher
+ MSI Pakete kann man mit den gängigen Packprogrammen nicht inspizieren, sind also für die meisten eben nicht transparent
Administratoren, die Software-Verteilung per Microsoft SCCM durchführen (müssen), benötigen Installationspakete im MSI-Format.
(Die freuen sich immer, wenn wir mit unseren Oracle Universal Installer Paketen kommen. Die sperren sich nämlich gut gegen eine Übersetzung ins MSI Format. - Andere Baustelle.)
Kurz und gut. Ob nun sachlich gerechtfertigt oder nicht, für viele Anwender bedeutet Total Commander schlankes Programm mit schlankem Installer und praktisch keine Registry-Eintragungen. MSI hingegen wird gleichgesetzt mit entbehrlichem Overhead und undurchsichtigen Eintragungen auch in der Registry.
Für Heim-Rechner denke ich auch, dass ich gut ohne MSI-Installation auskomme. Für meine portable Installation gänzlich ohne Installer. Wie gesagt, im SCCM-Bereich sieht das dann ganz anders aus.
Vielleicht wäre es daher nicht unklug gewesen, zunächst einmal dem Programmautor das MSI Installationspaket mit dem Hinweis auf automatische Softwareverteilung in Firmennetzen schmackhaft zu machen, bevor du dich damit unter die Wölfe der autarken Heimadministratoren begibst.
Grüße,
Karl
Das Setup Programm des Total Commanders dürfte unter dem Gesichtspunkt Transparenz gerade kein gutes Beispiel für Intransparenz sein.
MSI Installationspakete haben möglicherweise aus mehreren Gründen bei manchen(?)/vielen(?) Anwendern ein Akzeptanzproblem:
+ MSI stammt von Microsoft
+ manche Bloatware kommt als MSI Paket daher
+ MSI Pakete kann man mit den gängigen Packprogrammen nicht inspizieren, sind also für die meisten eben nicht transparent
Administratoren, die Software-Verteilung per Microsoft SCCM durchführen (müssen), benötigen Installationspakete im MSI-Format.
(Die freuen sich immer, wenn wir mit unseren Oracle Universal Installer Paketen kommen. Die sperren sich nämlich gut gegen eine Übersetzung ins MSI Format. - Andere Baustelle.)
Kurz und gut. Ob nun sachlich gerechtfertigt oder nicht, für viele Anwender bedeutet Total Commander schlankes Programm mit schlankem Installer und praktisch keine Registry-Eintragungen. MSI hingegen wird gleichgesetzt mit entbehrlichem Overhead und undurchsichtigen Eintragungen auch in der Registry.
Für Heim-Rechner denke ich auch, dass ich gut ohne MSI-Installation auskomme. Für meine portable Installation gänzlich ohne Installer. Wie gesagt, im SCCM-Bereich sieht das dann ganz anders aus.
Vielleicht wäre es daher nicht unklug gewesen, zunächst einmal dem Programmautor das MSI Installationspaket mit dem Hinweis auf automatische Softwareverteilung in Firmennetzen schmackhaft zu machen, bevor du dich damit unter die Wölfe der autarken Heimadministratoren begibst.
Grüße,
Karl