Vom Borderlands- zum OGS-Patchinstaller?

Hallo Leute,

ich möchte an dieser Stelle mal eine Gesprächsrunde eröffnen bezüglich Patchinstaller bzw. die möglichen Softwarepackete zur Erstellung dessen. Bevor ich damit aber anfange, möchte ich mich hier für die die mich noch nicht "kennen" kurz vorstellen...wenn auch eher Zaghaft. Ich hab schon etwas Kontakt mit Jack und marco gehabt, das Ergebnis ist dass ich jetzt auch hier in diesem Bereich Zugang bekommen habe.

Ich habe zu OGS gefunden auf der Suche nach einem UCP für Borderlands und seitdem zocke ich entweder Boderlands (uncut) oder ich spamme hier was rum :p Nein, also ich habe schon Interesse daran mich hier konstruktiv einzubringen, denn es geschah so: das Borderlands UCP funktionierte für mich nicht auf Anhieb, etwas rumprobieren und die manuelle Installation brachten mich ans Ziel. Ein paar Hilfestellungen diesbezüglich im Forum waren Erfolgreich und so fing ich an mit Jack zu reden über die Option einen neuen Installer zu bauen. Nebenbei hab ich mit marco auch schonmal darüber gefachsimpelt wie man eventuell in Zukunft die OGS-Angebote (Patches usw.) "sichern" könnte und/oder dazu beitragen könnte das User ihre Accounts etwas ernster nehmen...dazu aber ein andermal mehr.

Ich untersuche also z.Z. die Optionen das Borderlands Patch neu aufzulegen in einem All-in-one-Patch. Der Installer soll erkennen welche Borderladsversion installiert ist und die passenden Inhalte selber auswählen und installieren. Ich habe mich hierzu schonmal etwas umgesehen und mir überlegt mit welchen Mitteln und auf welche Weise ich dieses hinbekommen könnte. Für mich kommen da zwei Tools in Frage: Wix und NSIS. Mit dem Wix-Toolset habe ich mich jetzt schon etwas näher beschäftigt und auch schon ein paar Tests gemacht. NSIS ist mir Heute über den Weg gelaufen und auch ein würdiger Kandidat denke ich...auch wenn ich so ein paar Bedenken habe.

Beide Tools stellen also die Möglichkeiten mit Ihren Vor- und Nachteile für die bevorstehende Aufgabe. Auch wenn ich das Projeckt erstmal "für sich" erledigen möchte, halte ich aber doch schonmal im Hinterkopf das es vielleicht Bedarf gibt nach einem "allgemeinen OGS-Installer" oder zumindest eine Anleitung wie man robuste Installer baut. Die Aufgabe ist kein Ding der Ünmöglichkeit, aber es wird doch eine respektabele Zeit dabei vorübergehen: kennenlernen, einarbeiten, erstellen, debuggen, usw... Deshalb stelle ich eben die erste Frage hier: gibt es Bedarf nach einer robusten Methode, einem "allgemeinen Installer" oder zumindest eine globale Anleitung dahin? Ich denke zwar das ich Jack richtig verstanden habe und auch Berserkr schrieb was ähnliches im ersten Beitrag vom Vorschlägethread hier...frage aber trotzdem nochmal explizit nach.

Sofern es also gewünscht wird, werde ich dann als nächstes mal die beiden Toolsets näher beschreiben und erklären mit ihren Vor- und Nachteilen für die vorgesehene Anwendung. So kann ich dann zusammen mit euch über die (nähere Auswahl der) Optionen sprechen, um zu vermeiden dass ich mich 2x in was neuem eingrabe. Nicht falsch verstehen: ich mache das gerne...aber um doch etwas ergebnisorientiert zu handeln usw. möchte ich meine Zeit halt gerne so einsetzen dass auch etwas dabei rumkommt...

Bis denne, Gruß!

Hey Jungs...schonmal danke für euer Feedback. Bin noch am schreiben an dem Vergleich den ich versprochen habe. Es scheint doch etwas ausführlicher zu werden als gedacht. Zudem versuche ich auch gleich auf ein paar angebrachte Punte einzugehen und lese dafür hier und da nochmal was nach. Denke morgen, oh, euhm...heute irgendwann werd ich hier mein klopper posten

Dabei nochmal zu aller Deutlichkeit: ich möchte hier niemandem auf die Füße treten mit meinem Vorschlag. Ich dachte mir einfach, wenn ich mir die "Arbeit" mache für ein eigenes Projekt (mit/für Jack), dann kann ich mit ein wenig extra Mühe auch dafür sorgen dass andere auch was davon haben. Lese hierbei "Arbeit" = "gerne investierte Zeit und Mühe" Um diesen Nutzen für Andere nun so groß wie möglich zu machen, dachte ich wir reden einfach mal im Vorfeld darüber. So versuche ich zu vermeiden, dass im Nachhinein vielleicht ein bestimmter Wunsch aufkommt der mit dem gewählten Tool nicht oder nur sehr schwierig möglich ist. Nicht dass dieses -Gespräch- jetzt eine Garantie ist dass das nicht passiert...aber ich denke es ist deutlich worauf ich hinaus möchte. Lange Rede kurzer Sinn: wenn am Ende einer meint er möchte lieber eine andere Methode nutzen, dann ist das eben so

Wie gesagt hatte ich mir schon 2 Tools bzw. Toolsets angeschaut und möchte sie nun hier etwas näher beschreiben. Ich hatte mir schon bevor ich den ersten Beitrag schrieb ein paar Gedanken gemacht über mögliche Kriterien die man zum Vergleich nutzen könnte. Dabei werde ich noch versuchen zusätzlich auf ein paar Punkte einzugehen die ihr hier schon angemerkt habt. Ich stelle die Tools hier also kurz vor, mittels ein paar allgemeine Informationen. Wenn von Robustheit die Rede ist, meine ich die Robustheit der fertigen Installer und dessen Nutzung. Diese Informationen entstammen teilweise aus persönlicher Erfahrungen und anosnten aus einer kleineren "Literaturstudie" die ich dürchführte. Ich habe ein paar Stunden in verschiedenen Foren verbracht und versucht mir ein so deutlich wie mögliches Bild zu verschaffen von den Punkten die mir noch unklar waren. Ich habe mit dem Wix-Toolset schon einiges ausprobiert sodass ich kann sagen wie es funktioniert und was dabei benötigt wird. Bei NSIS und ICP habe ich mich auf der "Herstellerseite" und in Foren erkundigt was die Bedienung/Verwendung angeht.

Wix Toolset
Das Wix -Windows Installer- Toolset ist eine Microsoft Open Source Produkt, wovon es mittlerweile doch schon "überraschend viel gibt" wie ich finde. Wie man schon ahnen kann, spielt das Toolset ein auf, bzw. ist es speziell für den Windows eigenen Installermechanismus gedacht. Das "besondere" hierbei: das Toolset benutzt ein sog. beschreibenden Ansatz. Also man beschreibt mittels einem xml-Schema wie die Struktur des installierten Produktes aussehen soll. Dieses Schema wird dann dürch die Tools in mind. 2 Schritten zu dem eigentlichen Installer aufgebaut. Ein Stück Installer-Beschreibung sieht z.B. so aus:

<Directory Id="dir_ID" Name="de">
  <Component Id="cmp_ID" Guid="{E1FC25EA-B43A-471E-881E-21A388CE9247}">
    <File Id="fil_ID" KeyPath="yes" Source="SourceDir\de\OTN1.txt" />
  </Component>
</Directory>

Als Ergebnis bekommt man entweder eine *.msi-Datei wo "alles drin ist", eine *.msi und eine oder mehr *.cab-Dateien oder eine *.msi-Datei und eine "Haufen loser Daten". Hierbei können die Daten in eventuellen *.cab's mit verschiedene Grade gepackt werden. Standard wird gepackt mit dem mszip format, die Grade "High" bis "none" sind hierbei frei wählbar. Für Windowsumgebungen geben die *.msi Installer die hiermit erzeugt werden wohl die robustesten Installer ab. Es wird dabei wie gesagt etwas "Hauseigenes" genutzt. Oft gemeldet, aber in unsere Verwendung nicht wirklich wichtig sind Spezialfälle für unüberwachte Installation, Netzwerkinstallationen usw. die mit Wix einfach unschlagbar sind. Für die Robustheit gillt das gesammte: Installer, Funktionalität und auch der automatisch generierter Uninstaller.

Um also Installer mit dem Wix Toolset zu bauen brauch man, ja, das Toolset. Es wird mittels einem ungewöhnlichen aber schönen Installer installiert, der nach einem Update schauen kann und dann mittels einem Knopfdruck alles installiert. Man kann soweit ich das erkennen konnte nichts einstellen und es wird alles in den standard "Programme"-Ordner installiert. Es handelt sich wie gesagt um einem Toolset, dementsprechend gibt es eine Sammlung von Tools wovon mind. 2 benötigt werden. Es gibt auch noch eine separate GUI für das Toolset, das WixEdit heißt. Ich habe es mal installiert aber noch nicht benutzt...ich bin irgendwie lieber mit Teksteditor und Kommandozeile unterwegs. Wie schon gesagt arbeitet man mind. in 2 Schritten: erstens entwirft man die Struktur des zu installierenden Programmens/Patches, ähnlich wie die Dateistruktur die man bekommt mit einem ausführlichen "DIR"-Befehl. Obiges Beispiel würde eben ein Ordner "de" installieren mit darin die Tekstdatei OTN1.txt. Nachdem man noch ein paar extra Elemente angibt zur Konfiguration, wird das xml-Schema übersetzt mittels einem ersten Befehl: "candle Beispiel.wxs" Diese Übersetzung erzeugt eine Zwaischendatei mit der *.wixobj Endung, welche dann wiederum "gelinked" zu einer Windows Installer Database (= die MSI) indem man einen zweiten Befehl ausführt: "licht Beispiel.wixobj" Nach diesem Schritt hat man den Installer. Der zweite Schritt scheint so etwas überflüssig, es bietet aber die Möglichkeit für komplexere Produkte indem man mehrere *.wixobj-Dateien vereinen kann in einem Installer.

Heftig wird es beim erstellen der Datenstruktur natürlich wenn man 1000+ Dateien und Ordner hat...da gibt es im Toolset aber ein nettes "Harvester"-Tool. Das erstellt eine Basis für das xml-Schema, welches schon alle Daten enthält wie im obigen Beispiel, sodass "nur" noch die Konfiguration nötig ist. Wie gesagt werden hiermit robuste, erwachsene Installer gebaut. Es ist alles möglich...von Verknüpfungen ins Startmenü bis hin zu Registry-Einträgen. Sehr interessant: es wird automatisch ein Unintaller gemacht und ein Eintrag in die "Programme"-Liste der Systemsteuerung. Man kann wählen aus ein paar standard Installer-Versionen: voll modifizierbar, minimal, einfache bzw. stille Installation usw. Vollständig wäre dann eben: Intro/Willkommensbild -> Lizenz -> Features/Installationsort -> Eigentliche Installation. Grafisch kann man an 2 Stellen ein Logo einbinden und 4 Icons austauschen. Ansonsten bleibt der standard Windows-Look erhalten. Es ist jedoch möglich auch eigene Dialoge zu erstellen, mehr Knöpfe, Eingabefelder usw...sei es eben mit eben demselben Look. Für extra Funkitonalität muss ggf. eine eigene DLL geschrieben werden (C-code zu DLL kompilieren) die an bestimmte Aktionen gekoppelt werden können. Auch sehr bequem ist die einfache Nutzung anderer Sprachen für die Installer. Man kann sehr einfach in die Konfiguration angeben welche Sprache der Installer haben soll. So kann man auch mehrere Sprachenversionen bauen, die über einen Boostrapper zusammengefügt werden. So kann der Benutzer selber wählen welche Sprache er/sie angezeigt haben möchte.

NSIS
Das Nullsoft Scriptable Install System, mit der Herkunft bei den Winamp-Machern wenn nicht alles täuscht, ist ebenfalls ein Open Source Produkt. Der Ansatzt hier ist wie der Name es schon sagt ein ganz anderer, nämlich eben eine Skriptsprache. Man beschriebt im Stil einer Programmiersprache oder Batch-Befehlen wie der Installer am Ende aussehen und funktionieren soll. Folgendes Beispiel (Wikipedia)

NSIS liefert eine *.exe ab, die in der Regel alle Daten enthält. Die Daten können auch trotzdem noch gepackt werden, für die Komprimierung nutzt man hier LMZA, die Technik die auch in 7zip angewendet wird und sehr gute Komrimierungsraten schafft. Ich habe auch was gelesen, dass es möglich ist Daten separat zu halten und zu "laden" für die Installation. Wenn diese aber gepackt/komprimiert werden, muss man ein Enpacker mit vorsehen, der als Zwischenschritt eingebunden wird glaube ich. Jetzt kommt der Haken meiner Meinung nach: es gibt jede Menge an extra Funktionalität für dieses Toolset, jedoch über Plugins. An sich ist das ok...aber etliche Forenberichte sagen dass das zu kompatibilitätsprobleme führt. Vielleicht weil nicht jedes Plugin gleich schnell weiterentwickelt wird o.Ä....es wird also davon abhängen welche Funktionalität man brauch oder wie stark man das Toolset modded.

Für NSIS gibt es auch einen Installer, euhm...ja...kaum zu glauben Habe es gerade auch mal installiert, es ist wie erwartet recht "straight-foreward". Wenn mich nicht alles täuscht ist der NSIS-Installer mit NSIS gemacht...man kann hier die Installation nach eigenen Wünschen gestalten, auch die Möglichkeit einen anderen Installationsordner zu wählen usw. Es werden gleich einige Plugins mitgeliefert, vor allem das "System"-Plugin muss ich nochmal näher betrachten. Es bietet die Möglichkeit die Win32-API zu nutzen oder externe DLL's einzubinden. Das ist sehr interessant, denn Wix bietet das standard und ich denke es ist sehr praktisch für extra Funktionalität die nicht "im Buch steht". Das Toolset bietet eine kleine GUI von wo aus Beispiele oder Dokumentationen geladen werden können. Zum Kompilieren gibt es hier eine GUI...also man erstellt die Skripte wie bei Wix in dem Beliebig-Editor und kann sie dann im Kompiler laden und sogar testen. Es gibt wohl auch hier Erweiterungen für z.B. Eclipse um das erstellen der Skripte selber auch etwas zu vereinfachen. Letzteres habe ich noch nicht ausprobiert. Vor allem die Sache mit dem "Harvesten" müsste man für dieses Tool mal näher betrachten, denn wenn ich mir manche Patches anschaue...da hat man echt keine Lust die ganzen Daten manuell aufzulisten.

In Prinzip sollte mit NSIS dasselber möglich sein als wie mit dem Wix Toolset. Meine Einschätzung hierbei ist, dass es leichter sein wird um einen "bunten" bzw. optisch benutzerdefinierten Installer zu gestalten. Alles wird mittels einer eigenen Skriptsprache definiert und zusammengestellt, sowohl das Optische als auch das Funktionelle. Wobei ich glaube das eigene Dialoge und dergleichen über *.ini ähnliche Dateien beschrieben und eingebunden werden. Für extra Logik ist die Skriptsprache recht begrentzt und ist man schnell gezwungen extra Plugins zu nutzen. Ein großer Unterschied zu Wix sind auch die Uninstaller. Hier muss man alles von Hand basteln, auch, oder vor allem bei den Uninstaller ist das doppelte Arbeit. Auch ist "Vorsicht" dabei geboten, dass auch das richtige entfernt wird...am besten auch vollständig.

Install Creator Pro
Weil Berserkr es angebracht hat, habe ich mir auf die Schnelle auch dieses Tool mal angeschaut. Wobei "angeschaut" da vielleicht etwas übertrieben ist. Also ich habe mir Screenshots und Beschreibungen zu Gemüte geführt und versucht so ein Bild davon zu bekommen. Es ist nicht sehr viel beschrieben über dieses Tool. Die ersten 2 - 3 Ergebnisseiten bei Google ergaben lediglich 2 Webseiten die dieses Tool beschrieben und mit einer kleinen Ausnahme Quasi-Produktwerbung darstellen. Das Tool selber scheint recht bequem zu sein: man hat standard eine grafische Benutzeroberfläche in der man alles regelt: von dem Entwurf bis zur Erstellung des Installers.

Soweit ich es erkennen konnte ist das Ergebniss auch eine *.exe. Vermutlich wird es ähnlich wie bei NSIS sein. Wie stark die komprimierung ist, oder ob es möglich ist den Installer von den Daten zu separieren ist mir nicht bekannt. Es gibt hier wie gesagt nicht wirklich viele Testberichte, die wenigen Beiträge berichten lediglich davon dass die eingebaute Funktionalität für das nutzen von Serialkeys + Codes nicht gut/brauchbar/vertrauenswürdig wäre. Da es sich hierbei um ein eher "klassisches" Programm mit einer GUI usw. handelt, denke ich dass es hier bei der Installation und der Nutzung die wenigsten Überraschunen geben wird. Gut, bis auf die Tatsache dass es das einzige der 3 Tools ist das nicht kostenlos angeboten wird. Das Programm bietet eine komplette GUI zum zusammentragen der nötigen Info's und Konfigurationen des Installers und ich denke die Erstellung selber wird dann auch nur noch ein Knopfdruck sein.

Zum Thema "Installmechanismus - Skripte verstecken":
Die Installer werden eben mit verschieden Methoden zu *.msi oder *.exe verwandelt. Da ist in Prinzip nichts zu erkennen. Aber klar, mit einem resource-Hacker o.Ä. ist auch das nur Bedingt ein Geheimnis. Das ist dann für etwaige Sicherheitsvorkehrungen das "Problem". An irgend einem Punkt muss die Software entschlüsselt und ausführbar sein...also es gibt irgendwie immer einen Weg, wenn man will und weiß wie. Normale Gebraucher werden aber nicht mehr mit der Nase draufgeführt...

Zum Thema "Abfrage von Dateien, Registry-Einträgen, ...":
Das ist mittels Wix recht einfach zu erledigen. Bei NSIS sollte das auch möglich sein, allerdings weiß ich hier nicht wie komplex das wird oder ob es dafür im Einzelnen vielleicht Plugins gibt.

Zum Thema "Lizenz - Nutzungsbedingungen":
Es gibt eben das Standardfenster mit der Lizenz die man akzeptieren muss. Den Tekst kann man natürlich so ändern dass es für unsere Zwecke abgestimmt wird. Wenn gewünscht kann man auch nochmal eine extra Abfrage reinmachen...da ja meist aus Reflex eh auf "Akzeptieren" geklickt wird. Ob und wie ist noch die Frage, aber sehe den Sinn ganz klar und die Möglichkeiten sind da. Ich denke dass das nciht verkehrt wäre wenn wir das am Ende in alle Installer drinhaben?

Verdammt...ich sollte Romane schreiben, hiermit habt ihr jetzt aber schonmal etwas Bettlektüre würde ich sagen :p Also das hier zur Info und weitere Diskussion. Wenn wir uns für einen Weg entschieden haben sollten, werde ich den Borderlandspatch neu auflegen und dann eine Anleitung schreiben für euch...

Kein Ding Hat nur etwas länger gedauert als ursprünglich gedacht...sollte aber klar sein wieso

Also ich bin gespannt wie die anderen Meinungen noch ausfallen werden. Man muss in Prinzip für beide Tools was dazulernen. Für Wix und ICP sollte man generell verstehen wie der ganze Mechanismus funktioniert. Bei NSIS kommt noch die neue Skriptsprache dazu. Die "learning-curve" ist steiler bei Wix glaube ich, da der beschreibender Ansatz in xml schonmal etwas merkwürdig anmutet. Ein Kommando "copy x nach z" ist leserlicher/verständlicher als die Beispiel xml-Tags die ich ganz zu Anfang gepostet hatte.

Wenn man mit Wix extra's einbinden möchte wie Serialkey o.Ä. wird das mittels DLL's geregelt. Das ist nochmal eine andere Sache, aber das macht das ganze schon robuster denke ich, weil es eben als eine Art C-Programm dazugenommen wird. Bei NSIS könnte das einfacher/verständlicher anmuten, sofern es gute/passende Plugins gibt? Es mutet aber "begrenzter" an finde ich, weil in einer Skriptsprache ist man eben abhängig davon welche Befehle umgesetzt wurden. Bei einem C-Programm/DLL hat man die absolute Freiheit, aber auch die Arbeit es selber zu implementieren.

Ich tendiere auf verschiedenen Gründen auch eher zu Wix, will aber NSIS nicht unnötig schlecht machen. Sollte es eine Mehrheit für NSIS geben werde ich sicher keine Rebellion anzetteln, oder doch? :p Nein, lediglich bei ICP bin ich etwas zurückhaltender weil es eben was kostet oder nicht grad rechtlich verantwortet wäre. Gerade wenn man wie wir öffentlich die Installer verbreitet, sollte man da vielleicht etwas aufpassen?

Zitat

Mit nem ResEditor hast du bei MSIS nicht wirklich gute Chancen was raus zu kitzeln. Also ich bin der Meinung, dasß es mit NSIS am sinnvollsten wäre.

Hast du denn schon eine "NSIS-File" für mich!?

So daß ich mich auch etwas einbringen kann. Hab jetzt noch ein wenig Zeit. Kann eh nicht viel machen wegen Rippenbruch.

Aaaaalso...hier mal 2 Testinstaller. Testfolder und bigtest sind resp. ein msi- und ein exe-Installer die jeweils gezipped wurden um hier hochgeladen zu werden. Also einfach entpacken...

Ich habe mal geschaut. Mit ResHacker holt man aus der msi nix raus...weil er sich weigert die Datei zu öffnen => "... is not a Win32 application" Mit 7zip kann man die msi einfach öffnen und reinschauen. Da wird jede Menge angezeigt, aber ich habe die einzelnen Daten -die vom Namen her zwar bekannt waren- vergeblich zu öffnen versucht. Also im Notepad++ z.B. wird nix brauchbares angezeigt. Lediglich die Icons konnte ich mittels Extraction und Umbenennung wieder angezeigt bekommen.

Bei der NSIS-exe war es aber was anders. Hier konnte man einfach mit ResHacker die gesammten grafischen Elemente durchsuchen. Mittels 7zip bekommt man mindestend die originale *.nsi-Datei wieder zu gesicht. Diese im Teksteditor öffnen gibt einfach das Originalskript preis. Ich habe mal gesucht, aber noch keine Möglichkeit gefunden um das zu verhindern. Werde aber noch weiterschauen ob es da vielleicht nicht doch einen Weg gibt.

Jah...das ist glaube ich zu Testzwecke anstelle einer Lizenzereinbarung. Ich vergaß übrigens: mittels Orca kann man eine MSI schon noch dekompilieren oder zumindest die Inhalte betrachten. Das Plugin schaue ich mir nachher mal an.