Wozu noch InstallShield, wo es doch Windows Installer gibt?

[axeljaeger]

Ich hab lange nicht mehr unter Windows entwickelt, aber als Windows 2000 frisch rauskam, hab ich mal ein Paket von Microsoft mit 4 CDs bekommen, da war unter anderem der Windows Installer mit dabei.

Jetzt frage ich mich: Warum sollte man noch InstallShield oder Wise kaufen, wenn es den WindowsInstaller für Lau gibt und mindestens InstallShield auf dem Windows Installer aufsetzt und der Windows Installer auch noch das neue goldene Kalb von MS ist?

[Boron]

[sinnloser Text]
Wirklich gute Frage!
[/sinnloser Text]

Warum gibt es nicht derartiges für Linux. Ich meine distributionsübergreifend (kommt jetzt bloß nicht mit rpm und apt-get usw.).
Rethorische Frage -> nicht antworten, weil nicht threadrelevant und nach linuxforen.de gehörend.

[peschmae]

Tja, wieso gibts noch Leute die InstallShield verwenden. Das frage ich mich schon ewig.

Alternativen gibts wirklich zuhauf - WindowsInstaller aber auch InnoSetup (davon gibts sogar den Quellcode und man kann es mit einer Scriptsprache erweitern) und den Nullsoft Installer.

MfG Peschmä

[anda_skoa]

Vielleicht gibts den Windowsinstaller nicht auf allen Windowsplattformen auf denen ein Hersteller sein Produkt anbieten möchte und InstallShield schon.

Oder die entsprechende Konfiguration (oder wie auch immer das läuft) lässt sich nicht automatisch konvertieren, was Arbeit und damit Kosten verursachen würde ud für einen Hersteller der schon einen Installer lizensiert hat, vielleicht nicht gerade gut klingt.

Btw, hab mal die Update Funktion von Xp in Aktion gesehen. Ich schätze die nächste Windows Version kommt dann schon auf die Möglichkeiten der Linux Paketmanager heran, wenn die Softwarehersteller halbwegs kooperativ sind.

Ciao,
_

[peschmae]

Den WindowsInstaller gibts zum nachinstallieren für die älteren Windowse. Von dem her kein Grund.

MfG Peschmä

[Lin728]

Wäre eine gute projekt-idee ;-)

Eine Installer für Win/Lin/Mac/Unix, der die Spezialitäten jeder Platform kennt ;-)

lg

[axeljaeger]

Es gibt bereits Java-basierte lösungen. Aber ich wüsste auch nicht, wo so etwas sinn machen sollte, außer bei Java-Anwendungen.

[Hans-Georg Normann]

Original geschrieben von Boron
Warum gibt es nicht derartiges für Linux. Ich meine distributionsübergreifendProbier doch mal Checkinstall. Einfacher gehts nimmer.

Hans

[peschmae]

oder epm

MfG Peschmä

[axeljaeger]

Es gibt doch ettliche Projekte, die versuchen, RPM oer deb mit einem grafischen Installer zu ersetzen. Ich hatte mal eine Qt-Lösung: Shellscript mit tbz anhang, das sich in /tmp entpackt und dann einen mitgebrachten Installer entpackt. War aber nur eine Technologiestudie und konnte außer dem Sichauspacken und Installer anzeigen noch nicht viel.

[Hans-Georg Normann]

Original geschrieben von axeljaeger
Es gibt doch ettliche Projekte, die versuchen, RPM oer deb mit einem grafischen Installer zu ersetzen. Ich hatte mal eine Qt-Lösung: Shellscript mit tbz anhang, das sich in /tmp entpackt und dann einen mitgebrachten Installer entpackt. War aber nur eine Technologiestudie und konnte außer dem Sichauspacken und Installer anzeigen noch nicht viel. Hehehe

so kenn ich den Axeljaeger garnicht. Erst ansehen, denn zerreissen! :mad: Ich weiß nicht wer dir geflüstert hat, dass checkinstall ein grafisches Frontend ist. Das kannste ganz fix mit de Finger bedienen.

Hans

[axeljaeger]

??? Ich weis nicht, was der Mann von von mir will: Die Qt-Lösung stammt aus meinem eigenen Hause. Checkinstall kenne ich nicht, das hat aber mit dem Nullsoftinstaller oder MSI mit Sicherheit nicht viel zu tun.

[Hans-Georg Normann]

Original geschrieben von axeljaeger
??? Ich weis nicht, was der Mann von von mir willHi axeljaeger

Ist doch ganz einfach. Dein Spruch im vorletztem Posting erweckt den Eindruck, als wenn dir nur grafische Frontends angeboten wurden und die alle nichts taugen. Deine Aussage war ein "Rund-um-schlag". Da war keine Eingrenzung auf bestimmte Postings oder so.

Im letzten Posting gibst du selbst zu, dass du checkinstall nicht kennst. Das war mir eigentlich klar, denn sonst wäre das vorletzte Posting sicher anders ausgefallen.

Ich wollte das nur geraderücken. Ich komme mit checkinstall jedenfalls bestens zurecht.

Hans

[peschmae]

Original geschrieben von Hans-Georg Normann
Ist doch ganz einfach. Dein Spruch im vorletztem Posting erweckt den Eindruck, als wenn dir nur grafische Frontends angeboten wurden und die alle nichts taugen. Deine Aussage war ein "Rund-um-schlag". Da war keine Eingrenzung auf bestimmte Postings oder so.


Das habe ich aber nicht ganz so verstanden.

Er hat ja gar nix gegen dein geliebtes checkinstall gesagt, also kein Grund das gleich so verbissen (?) zu verteidigen. :D

MfG Peschmä

[axeljaeger]

Das Wort Frontend hab ich gar nicht verwendet. Ich meine nur, es gibt bereits Projekte, die einen solchen Installer entwickeln wollen, deswegen brauchen wir nicht noch eine konkurierende Communitylösung zu entwickeln.

Edit: Ach ja: Ich bin sehr FÜR grafische Installer. Aber am besten finde ich die Appfolder von OSX.

Edit2: Und wenn es die Ultimative Lösung gäbe, hätte ich davon schon gehört. Auch wenn das Checkinstall alle meine Wünsche erfüllen würde. Aber meines Wissens ist das doch eher ein Aufsatz auf Make install, so dass man das Programm hinterher wieder sauber deinstallieren kann, oder irre ich? Gibt es vielleicht Screenshots von Checkinstall?

[peschmae]

es ist nicht ein Aufsatz für Make install - aber der Rest stimmt.

So ultimativ finde ich das aber auch nicht - die Abhängigkeiten fehlen manchmal ganz schön.

MfG Peschmä

[axeljaeger]

Es ist aber wohl auch ein problem in der OpenSource-Szene, das jeder Klickerkram in eine Shares lib gepackt werden muss. So libs, die nur 50kb groß sind, würde ich einfach immer static machen, dann hat der kunde nicht den ärger.

[anda_skoa]

Eine Shared Lib macht eigentlich nur Sinn, wenn es Teil einer API ist oder wenn komplexerer Code drinnen ist, denn man getrennt bugfixen können will.

Oder natürlich wenn es dlopen mäßig geladen werden soll (Plugins)

Ciao,
_

[axeljaeger]

Volle Zustimmung! Man schaue sich mal Programme wie Audacity an(oder war es ein anderes OpenSource Soundprogramm?): Da wird libsamplerate benötigt: Das ist eine winzige lib, die von einer Abtastfrequenz auf eine andere umrechnet. Nicht nur, dass es unwahrscheinlich ist, das man viele Programme hat, die das benötigen und so sharen könnten, es ist auch unwahrscheinlich, dass da mal ein Update unabhängig vom Hauptprogramm gemacht werden.

Edit: Bei dlopen kann das Programm wenigstens eine Fehlermeldung ausgeben, dass eine Lib nicht gefunden wurde, wobei das auch übertrieben wird, siehe Noatun. Macht es eigentlich in der Geschwindigkeit etwas aus, ob man ein Programm zur Compilezeit gegen eine Lib linkt oder erst zur Laufzeit öffnet?

[anda_skoa]

Original geschrieben von axeljaeger
Macht es eigentlich in der Geschwindigkeit etwas aus, ob man ein Programm zur Compilezeit gegen eine Lib linkt oder erst zur Laufzeit öffnet?

Im Normalfall wahrscheinlich eher nicht, aber feste Abhängigkeiten könnten eventuell gecached werden, bzw. muss die Lib vielleicht nicht mehr geladen werden, wenn sie schon von einem anderen Programm benutzt wird.

Ansonsten wird sich nur der Zeitpunkt der Relocation verschieben, man kann damit also Lazy-Relocation machen, also erst Laden und Auflösen, wenn man sie braucht, oder besondere Features erst nach dem Starten der Coreapplikation nachladen und damit schneller beim Starten wirken.

Ciao,
_