VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
Oktober 2001
[Inhaltsverzeichnis]
|
| Von Herwig Bauernfeind © Oktober 2001 |
In Abänderung des im 1. Teil angekündigten Inhaltsverzeichnisses für die Serie über »Händische Installation von Win32-Programmen unter Odin« möchte ich aus aktuellem Anlaß ein Thema anschneiden, weil es auch gerade in der odinusers-Liste ein Thema war, welches vielleicht wichtiger ist, als das "richtige" händische Auspacken und an den richtigen Ort Verfrachten (das kommt dann beim nächsten Mal).
Exkurs: Selbstentpackende Installationspakete auf InstallShield Basis und Probleme, die dabei auftreten und wie man sie (meistens) lösen kann.
Viele dieser Pakete (z.B. Adobe Acrobat Reader 4.0 und 5.0, InstallRite 2.5) liegen als einzelne 32-bittige .EXE-Datei vor, die sich mit Odin tadellos starten lassen, dann aber mit einer Fehlermeldung, wie der folgenden
oder Odins Could not execute ..., not a valid Win32 file, perhaps 16bit? oder Failed to start W16 session oder irgendetwas Ähnlichem stehen bleiben und sich dann ohne weitere Meldung beenden (aber keinen Ausnahmefehler auslösen). Diese Programme können in aller Regel tadellos installiert werden, man muß nur wissen, was diese Pakete tun und warum sie scheitern.
Dazu folgendes zur Erläuterung: Diese Pakete sind doppelt gepackt, zuerst als äußerste "Schicht" ein 32-bit Entpacker, der nichts anderes tut, als das eigentliche Installationspaket in ein Verzeichnis unterhalb des temporären Verzeichnisses (jenes Verzeichnis, auf das die Umgebungsvariable TEMP oder TMP zeigt, im folgenden einfach TEMP-Verzeichnis genannt) zu entpacken.
Das Problem ist nun, daß nach erfolgreichem Entpacken, in diesem Verzeichnis ein weiteres Programm (in allen mir bekannten Fällen) namens SETUP.EXE aufgerufen wird. Der Haken daran: Dieses Programm ist nun ein 16-bit Windowsprogramm, welches Odin nicht ausführen kann, es kommt die oben beschriebene (oder eine ähnliche) Fehlermeldung. Bestätigt man diese, löscht der "äußere" 32-bit Entpacker des ganze soeben erzeugte Verzeichnis samt Inhalt wieder weg.
Nun, wie einigermaßen bekannt sein dürfte, gibt es ein Paket, welches einen Satz 32bit Versionen jener Programme enthält, die jedem Installshield-Installationspaket beiliegen. Es sind dies: SETUP.EXE, SETUP.DLL und _ISDEL.EXE. Im Dateibereich der odinusers-Liste bei YahooGroups liegt ein Paket mit neueren Versionen dieser Dateien und meiner Meinung nach ist die Erfolgsrate mit den Programmen aus diesem Paket deutlich höher als mit den älteren. Die saubere Lösung wäre nun, diese 32bit Versionen in das Installationspaket hineinzubekommen. Das ist für den durchschnittlichen Benutzer (wie mich) aber nicht möglich.
Der Trick, um das Ganze aber doch hinzubekommen ist folgender: Der Ansatzpunkt ist die Fehlermeldung. In dem Moment, in dem sie erscheint, liegt das ganze Paket wunderschön ausgepackt im oben beschriebenen Unterverzeichnis des TEMP-Verzeichnis. Man muß die Fehlermeldung nun erst einmal stehenlassen und darf sie keineswegs bestätigen. In dem Moment, in dem man sie bestätigt, wird alles wieder in Windeseile gelöscht (und man kann von vorne beginnen). Die Namen dieser erzeugten Verzeichnisse (z.B. pgf001~tmp) sind sehr kryptisch und aus dem Namen lassen sich keine Rückschlüsse auf den Inhalt ziehen. Normalerweise bekommt man sie auch nie zu Gesicht, da sie nach der Installation - egal ob erfolgreich oder nicht - sofort wieder samt Inhalt gelöscht werden.
Man kommt also nicht umhin, das TEMP-Verzeichnis bzw. dessen Unterverzeichnisse händisch zu durchsuchen, bis man das ausgepackte Installationspaket findet. Das erinnert mich immer irgendwie an das Durchsuchen einer Abstellkammer: Wenn sie nicht immer brav zusammengeräumt wird, schauts drin so richtig grauslich aus. Das ist beim TEMP-Verzeichnis nicht anders. Es empfiehlt sich, auf Uhrzeit und Datum des (der?) Verzeichnisse(s) zu sehen - das, was gerade erzeugt wurde, ist ziemlich sicher das Richtige!
Als nächstes notiert man sich den Namen des Verzeichnisses und kopiert den gesamten Inhalt (mit allem Drum und Dran inklusive eventueller Unterverzeichnisse) an einen sicheren Ort. Alle Dateien mit einem read-only Attribut zu versehen funktioniert nicht, weil einige Dateien zu diesem Zeitpunkt offen sind und ich zumindest ein Paket hatte, welches auch den Rest trotz read-only Attribut ratzeputz gelöscht hat.
Hat man das ausgepackte Paket kopiert, kann man die Fehlermeldung bestätigen und alles wird gelöscht. Nun kann man den Inhalt vom sicheren Ort genau wieder dorthin zurückkopieren, wo er eben noch war.
Als nächstes ersetzt man SETUP.EXE, SETUP.DLL und ISDEL.EXE durch deren 32bit Varianten und ruft SETUP.EXE auf. Bingo! Einige Installationen laufen nun tadellos durch und das Ergebnis ist ein mustergültig unter OS/2 installiertes Win32-Programm. Leider sagt die Lauffähigkeit des Installationsprozesses nichts über die Lauffähigkeit des Programmes selbst aus.
Manchmal treten bei diesen Installationspaketen noch ein paar andere Probleme auf: Eine Unsitte aus der Windows-Welt ist, daß viele läppische Installationspakete sich einbilden, Teile des Betriebssystemes austauschen zu müssen, womöglich ohne jede Versionskontrolle, einfach so und meistens unnötig. Insbesondere Teile des OLE-Subsystems sind bekannte Kandidaten. Leider tun das diese Pakete auch unter OS/2 und Odin und sind so eine absolute Garantie dafür, ein schön sauber installiertes Odin komplett unbenutzbar zu machen, weil Odins System-DLLs durch (womöglich veraltete) Windows-Versionen ersetzt werden.
Man sollte also nach einer Programminstallation unbedingt dafür sorgen, daß Odin auch wirklich noch seine eigenen Dateien hat, in dem man den letzten Odin-Build nochmals drüber installiert. Dazu kommt noch, daß einige Installationspakete schon während sie laufen, die ausgetauschten Teile benutzen möchten, was natürlich sofort einen Ausnahmefehler bewirkt (und Odin ist dann auch kaputt!).
Ich habe versucht, die ausgetauschten DLLs noch während das Installationsprogramm läuft wieder durch ihre Odin-Pendants zu ersetzen, aber da braucht man wirklich flinke Finger und jedenfalls bereits eine geöffnete Kommandozeile im Vordergrund. Ich hatte damit auch schon Erfolg, aber das ist wirklich Stress und meist habe ich 2 oder 3 Anläufe gebraucht, um es hinzubekommen. Auch das read-only Attribut bringt in diesem Fall nichts, da sich die Installationsprogramme entweder nicht darum kümmern und die Dateien trotzdem überschreiben oder wenn sie sich darum kümmern, mit einer Fehlermeldung abbrechen.
Dazu kommt noch, daß die Chancen, daß Programme, die Teile des Betriebssystems selber mitbringen, sich bei den benutzten Funktionen meist nicht auf das beschränken, was Odin bietet und das ist gerade im Bereich OLE noch nicht gar so viel.
Soviel zu diesem Thema für diesmal. Der versprochene Teil über das händische Verfrachten der Dateien an den richtigen Platz erscheint im nächsten Monat.
Quellenverzeichnis:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org