Zum Artikel
V.O.I.C.E Virtual OS/2 International Consumer Education
Oktober 2007
A A A
Artikel

- Christian Hennecke: Und nun einmal zu etwas ganz anderem
- Cheng-Yang Tan: Kopf an Kopf - Thinkpad T30 mit eComStation 1.2 versus Macbook Pro mit MacOSX Tiger 10.4
- Alex Taylor: Feature Install entdecken - Teil 1: Objekt-basierte Installation
- Sjoerd Visser: Virtueller Speicher
- Bart Bremmers: Karaoke-CDs unter OS/2 und eComStation erstellen
- Tips
- Leserbriefe, Addenda, Errata

Aktives GUI-Element

Statisches GUI-Element

Quelltext

WPS-Objekt

Datei/Pfad

Befehlszeile

Inhalt Eingabefeld

`[Tastenkombination]`

mehr

# Feature Install entdecken
Teil 1: Objekt-basierte Installation

von Alex Taylor, © Oktober 2007

Anmerkung des Übersetzers: Ein Teil der Bilder hätte ich auf meinem deutschen System nachbilden können, jedoch nicht die Bilder, die im Zusammenhang mit dem IBM C/C++-Compiler erstellt wurden. Daher habe ich mich entschlossen, alle Abbildungen im Original zu belassen. Dadurch sind jedoch einige Stellen im Text, zum Beispiel "Antwortdatei > Lesen", nicht in Übereinstimmung mit den Bildern, da diese in englischer Sprache gehalten sind - die entsprechenden Einträge im gezeigten Bild lauten dann: "Response file > Read". Inhaltlich besteht jedoch kein Unterschied. An einigen Stellen ist auch Feature-Install selber nicht oder nicht durchgängig übersetzt.

Erwähnen Sie Feature Install, und die meisten OS/2 -Anwender denken sofort an die lästige Webbrowser-Anwendung, die ihnen viele IBM-Produkte (wie Java oder TCP/IP) während der Installation aufgezwungen haben. Aber das ist wirklich eine unangemessene Wahrnehmung: Feature Install hat absolut nichts mit Webbrowsern zu tun.

OS/2 Feature Install ist ein sehr flexibles Installationswerkzeug, das selber in die WPS integriert ist. Es wurde entworfen, um eine Installations-Engine für gebrauchsfertige Softwareprodukte zu liefern, aber den Produktentwicklern die Freiheit zu lassen, ihre eigene Installations-Benutzerschnittstelle für den Installationsprozeß zur Verfügung zu stellen. Mit anderen Worten, Feature Install ist ein allgemeines Installations-"Back-End", und es steht den Entwicklern frei, ein ihnen gefälliges "Front-End" zu liefern.

Offensichtlich mag IBM HTML-basierte Benutzerschnittstellen, also wählten sie den Netscape als Front-End zur Installation ihrer Produkte. Dies wurde mit dem Webbrowser-Plugin realisiert, der mit der Feature-Install-Engine kommunizierte. Aber weder das Plugin noch der Webbrowser sollten als Bestandteil von Feature-Install angesehen werden. Es ist problemlos möglich, ein völlig anderes Front-End einzusetzen.

Nichtsdestoweniger haben wir öfter mit verschiedenen IBM-Produkten zu tun, die zur Installation den Netscape benötigen. Dies ist besonders ärgerlich, weil das Browser-Plugin den Netscape 2.02 oder 4.x erfordert; Mozilla unterstützt das Plugin nicht und wird es auch zukünftig nicht tun). Berücksichtigt man wie veraltet der Netscape heute ist, ärgern sich viele Anwender darüber, daß sie solch alte Software auf ihrem System installieren müssen. Dazu kommt, daß die Browserschnittstelle notorisch langsam, verschnörkelt ist und manchmal zu mysteriösen Hängern und Abstürzen neigt. Wäre es nicht klasse, wenn wir alle darauf verzichten könnten?

Wie es der Zufall will, wir können!

## In einer Netscape freien Welt

Es gibt 2 Möglichkeiten, um IBMs Feature-Install-basierte Produkte zu installieren ohne den Netscape zu beanspruchen.

### Nicht überwachter Modus (CLIFI)

Der zunächst offensichtliche Weg ist die Verwendung des nicht überwachten Modus (auch CID Modus genannt), der von den meisten dieser Produkte unterstützt wird. Ich werde diesen Prozeß wohl in einem späteren Artikel detaillierter be-, aber hier nur kurz umschreiben.

Für die Produkte, die dies unterstützen, sind üblicherweise Anweisungen für die nicht überwachte Installation irgendwo in der README-Dokumentation verborgen. In den meisten Fällen wird CLIFI.EXE, eingesetzt, das die Befehlszeilenschnittstelle von Feature-Install darstellt. Typischerweise muß man dazu ein ASCII-Skript, Antwortdatei genannt, erstellen, das man dann an CLIFI.EXE übergibt, um die Installation von der OS/2-Befehlszeile aus in Gang zu setzen..

Diese Methode kann sehr nützlich sein, zumindest für erfahrene Systemadministratoren oder für Entwickler, die ihre eigenen zugeschnittenen Front-Ends schreiben wollen. Jedoch erfordert dies ein gewisses Maß an technischen Fähigkeiten. Das frisieren der Antwortdateien kann sehr komplex werden und bedarf häufiger eines ermüdenden Grabens durch die Dokumentationen. Die Syntax der CLIFI.EXE-Befehle ist ebenfalls ziemlich geheimnisvoll. Und dann sind da noch ein oder zwei Produkte (wie etwa VisualAge C++ 4.0), die überhaupt keine dokumentierte Unterstützung für diese Methode mitbringen.

All das scheint ein bißchen viel für den gelegentlichen Anwender, der nur schnell das verdammte Produkt installieren will und dann einfach weiterleben möchte.

### Verwendung von Arbeitsoberflächen-Objekten

Aber da gibt es doch einen einfacheren Weg. Vorhin erwähnte ich, daß Feature-Install in die Arbeitsoberfläche integriert ist. Dies bedeutet, daß alle Installationsdaten für jedes Feature-Install-installierbare Produkt in einer speziellen Art von Arbeitsoberflächen-Objekt (Install Object genannt) gespeichert sind. Normalerweise erstellt und verwaltet das Webbrowser-Plugin (oder CLIFI) diese Objekte hinter den Kulissen. Aber es ist tatsächlich für Sie, den Anwender, möglich, diese Arbeitsoberflächen-Objekte direkt zu verwenden und den Installationsprozeß zu verwalten. Kein Webbrowser, keine CID-Befehle… nur Auswählen, Anklicken und Installieren!

Ok, vielleicht ist es nicht ganz so einfach. Aber es ist auf der anderen Seite auch nicht so schwer, vorausgesetzt man hat die Technik verstanden..

## Das Install-Object

Wenn Sie jemals ein Feature-Install-Produkt installiert haben (Warp 4 und neuere Versionen installiert mehrerer solcher Produkte als Bestandteil des Betriebssystems) können Sie über die Arbeitsoberfläche den Ordner \OS2\INSTALL\Installed Features öffnen und einen Blick auf den Inhalt werfen.

Hier ist ein Beispiel, was möglicherweise enthalten ist (von einem eCS 1.2-System):

Bild 1. Standard-Inhalt des Ordners \OS2\INSTALL\Installed features

Jedes der Objekte in diesem Ordner ist ein Install-Object der (WPS Klasse WPInstall), welches ein Produkt repräsentiert das bereits installiert ist. Wenn man nun eines doppelklickt sieht man den Baum der verschiedenen Komponenten, die als Teile des Produktes installiert wurden.

Bild 2. Standard-Inhalt des Feature-Install-Base-Install-Objekts

Wenn man die Objekteinstellungen über das Kontextmenü öffnet, kann man durch die verschiedenen Einstellungen schauen, die dieses Produkt festlegen (wie Verzeichnisname, Änderungen der Konfigurationsdateien, kopierte Dateien und so weiter).

Jedoch werden Install-Objekte nicht nur zur Repräsentation installierter Produkte eingesetzt. Der tatsächliche Installationsprozeß verwendet ebenfalls Install-Objekte, obwohl sie üblicherweise von Netscape vor Ihnen versteckt werden. Tatsächlich ist alles, was Netscape mit seinem Plugin (oder CLIFI, sofern verwendet) macht, eigentlich nur, daß ein Install-Object angelegt wird mit Daten, spezifisch für das zu installierende Produkt versorgt wird, und ihm dann mitgeteilt wird, sich selbst zu installieren.

An dieser Stelle muß ich ein paar Worte über das Basiskonzept verlieren. Jedes Feature-Install-Produkt und jede auswählbare Komponente des Produktes nennt man Feature. Das Produkt als Ganzes kann man als Top-Level-Feature ansehen, und jede wählbare Komponente als Kind-Feature. Jedoch können die Kind-Features in einer (offensichtlich) nahezu unbegrenzten Anzahlebenen verschachtelt sein. Also kann jede Komponente eines Produktes ihre eigenen Unterkomponenten haben; mit anderen Worten, Kind-Features haben ihre eigenen Kinder, und diese haben selber wieder Kinder und so weiter.

Jedes Feature, sei es Top-Level oder Kind, ist durch ein Install-Object dargestellt. Dies bedeutet, daß Install-Objekte hierarisch sind, ähnlich Verzeichnissen. Schaut man sich den Komponentenbaum in obigem Beispiel an, zeigt sich, daß jeder der Äste selber ein Install-Object in das Eltern-Objekt eingebettet ist, in gleicher Weise wie ein WPS-Ordner. (Tatsächlich, für diejenigen, die es interessiert, die Install-Objektklasse ist eine Unterklasse der Standard-WPS-Ordnerklasse.) Diese Charakteristik der Install-Objekte ist nicht sonderlich wichtig, hier und jetzt aber kann es für einen späteren Artikel sein.

Für unseren derzeitigen Zweck werden wir fast ausschließlich mit den Top-Level-Install-Objekten arbeiten, obwohl wir uns der Kind-Features bewußt sein sollten, wenn es an der Zeit ist, die Komponente zur Installation auszuwählen.

## Installieren mit Objekten

Nun wissen wir was Install-Objekte sind. Aber wie installiert man damit ein Produkt?

Der Prozeß besteht, grob unterteilt, aus 5 Schritten:

1. Anlegen eines leeren Install-Objektes.
2. Laden der Produktdefinitionsdaten in das Objekt.
3. Setzen der benötigten Produktvariablen.
4. Auswahl der zu installierenden Produktkomponenten.
5. Starten der Installation.

### Anlegen eines Install-Objektes

Der erste Schritt verlangt von uns, ein allgemeines, leeres Install-Object anzulegen. Soll heißen, ein Arbeitsoberflächen-Objekt der WPInstall-Klasse zu erzeugen. Jeder, der sich mit OS/2-REXX auskennt, sollte in der Lage sein, dies mit 2 Zeilen REXX zu erledigen. Aber das ist nicht notwendig, da Feature-Install einen einfachen Befehl bereitstellt, der dies für uns erledigt; er ist Teil des CLIFI-Programms. Obwohl wir CLIFI für die aktuelle Installation nicht einsetzen, können wir seine einfachste Aufrufsyntax nutzen, um für uns ein leeres Install-Object anzulegen (so daß wir uns nicht mit REXX herumschlagen müssen).

Der Befehl lautet:

    CLIFI /A:T

genauso wie gedruckt. Falls Sie sich fragen, der /A Schalter heißt “Aktion” (sagt CLIFI, welche Funktion es ausführen soll), und T ist die Abkürzung für “template” (es gibt hier keine Verbindung zu den Arbeitsoberflächenschablonen; in diesem Zusammenhang bedeutet es nur, daß CLIFI ein allgemeines Install-Object auf der Arbeitsoberfläche anlegen soll).

Sie sollten zum Abschluß dieser Aktion ein Install-Object auf der Arbeitsoberfläche haben (sieht aus wie ein kleines blaues Paket), das absolut ausreichend als Install-Object benannt ist.

Bild 3. Eine neu angelegte Install-Object-Vorlage

### Lesen der Produktdefinitionen

Nun müssen wir die Produktdefinitionen laden von dem, was auch immer wir installieren wollen.

Eins der netten Einstellungen des Feature-Install ist, daß die vollständige Definition jedes Produktes, die alle Daten, die zur Installation und Konfiguration enthält, vollständig in einer ASCII-Textdatei enthalten ist. Ich werde diese Datei im weiteren Produktdefinitionsantwortdatei nennen. An anderen Stellen werden Sie dafür die Begriffe Primäre Antwortdatei oder Feature-Install-Antwortdatei finden.

Im allgemeinen werden Sie selber herausfinden müssen, wo diese Datei liegt und wie sie heißt. Die Datei hat immer die Endung .RSP, ist stets groß (typisch über 100 KB, und oft ein vielfaches davon) und ist ebenso typisch entweder im Top-Level-Produktverzeichnis (zusammen mit der README und den vielen HTML-Dateien, die Netscape verwendet) oder in einem direktem Unterverzeichnis. Enthält das Produkt verschiedene Sprachversionen, könnte es in dem Unterverzeichnis der entsprechenden Sprache, die installiert werden soll, abgelegt sein.

Einige Beispiele:

- Für Java 1.3.1 ist es die Datei xx\JAVA131.RSP, wobei xx der Code der gewünschten Sprache ist (z.B. EN für Englisch, DE für Deutsch, etc.); der Pfad ist relativ zum Ort an dem die von Softwarechoice heruntergeladenen Java-Dateien entzippt wurden.
- Für TCP/IP 4.3.2 ist es die Datei TCPIP\INSTALL\TCPINST.RSP, wo immer hin Sie die Dateien von Softwarechoice entzippt haben.
- Für den IBM C/C++ Compiler 3.6.5 ist es die Datei COMPILER\PORTAPAK.RSP, relativ zum Wurzelverzeichnis der Installations-CD.
- Für IBM VisualAge C++ 4.0 ist es die Datei VACPP\VACPP.RSP, relativ zum Wurzelverzeichnis der Installations-CD.

(Wenn das Produkt CID-Installationsanweisungen mitbringt, sollten diese aufzeigen, wo die Datei zu finden ist; es ist die gleiche Datei, die Sie für den Parameter/R: angeben müßten, wenn Sie mit CLIFI installieren würden.)

Haben Sie erstmal die richtige Datei gefunden, müssen Sie diese in das Install-Object laden. Führen Sie dies durch, indem Sie auf das Objekt rechts klicken, Antwortdatei aus dem Kontextmenü wählen und dann Lesen. Dann benutzen Sie den Dateidialog, der eingeblendet wird, um die Antwortdatei festzulegen.

Bild 4. Install-Object-Kontextmenü

In den folgenden Beispielen werde ich den IBM C/C++-Compiler 3.6.5 installieren (dieser wird mit dem VisualAge C++ 4.0-Paket ausgeliefert).

Die Produktdefinitionsantwortdatei heißt \COMPILER\PORTAPAK.RSP auf der Installations-CD-ROM. Also, nachdem ich ein leeres Install-Object erstellt habe, wähle ich nach einem Rechtsklick darauf die einzulesende Antwortdatei aus (wie oben beschrieben). In dem Dateiauswahldialog wechsel ich auf mein CDROM-Laufwerk und lokalisiere die Datei:

Bild 5. Auswahl der Antwortdatei zum Einlesen

Klicke ich auf Lesen, erscheint folgende Meldung:

Bild 6. Statusmeldung beim Einlesen der Antwortdatei

Nachdem das Install-Object das Einlesen der Antwortdatei beendet hat, ändert sich dessen Titel zu dem, was auch immer in der Produktantwortdatei festgelegt ist. (Im Falle des C/C++-Compilers ist es der ziemlich kryptische Name PPAK_FI. Nun ja, wie auch immer.)

Nun, wenn ich auf das Install-Object doppelt klicke, erhalte ich die verschiedenen Produktkomponenten gelistet mit Auswahlkästchen, mit deren Hilfe ich jedes einzelne hinzu- oder abwählen kann. Ich werde dies gleich machen, aber vorher gibt es noch etwas anderes, wichtiges zu erledigen.

### Identifizierung der Produktvariablen

Jedes zu installierende Produkt bringt viele Optionen mit sich. Feature-Install unterscheidet diese nach 2 Typen: wählbare Komponenten (auch Kind-Funktionen genannt) und andere Variablen.

Die wählbaren Komponenten werde ich gleich behandeln. Die anderen Variablen umfassen typischerweise das Laufwerk und Verzeichnis, in welchem das Produkt installiert werden soll, den Ort, an dem die Produktabbilddateien liegen - und auch sonst sind viele andere Dinge enthalten, die spezifisch für das Produkt sind. Bevor wir ein Produkt installieren können, müssen wir feststellen, ob wir einige davon bearbeiten müssen oder nicht.

Zunächst müssen wir nun herausfinden, welche Variablen schon definiert sind. Wir erreichen dies, indem wir auf das Install-Object rechts klicken und Einstellungen auswählen. Alle Variablen, die für das Produkt festgelegt sind, sind auf der zweiten Seite des Einstellungsnotizbuches gelistet, dieVariablen genannt wird:

Bild 7. Install-Object-Einstellungennotizbuch mit definierten Produktvariablen

Lassen Sie sich von der Vielzahl der Variablen nicht beeindrucken. Um die meisten werden Sie sich nicht kümmern müssen.

Um zu sehen, was ich meine, doppelklicken Sie auf ein paar Variablen oder nehmen Sie den Anzeigen-Knopf. Dann erscheint ein Dialogfenster, daß die einzelnen Variablen mit etwas mehr Details beschreibt:

Bild 8. Detaillierte Ansicht einer Install-Object-Variablen

In diesem Beispiel schaue ich mir die Variable InstDir1 des IBM C/C++ Compilers an. Diese Variable setzt das Hauptzielverzeichnis für die Installation; der Vorgabewert ist IBMCXXO. Der Laufwerksbuchstabe ist hier nicht angegeben, da er in einer anderen Variablen gesetzt wird (Sie erkennen dies, wenn Sie die Variablenliste nochmal durchschauen), die InstDrv1 genannt wird..

Nun schaue ich mir noch die Variable InstallPath1 an:

Bild 9. Detaillierte Ansicht der InstallPath1-Variablen

Wie Sie erkennen können, ist diese Variable durch das Verketten der beiden Variablen InstDrv1 und InstDir1 bestimmt, mit einem Backslash dazwischen. (Sie können eine Variablenreferenz daran erkennen, daß sie zwischen geschwungene Klammern {} gesetzt wird.) Anders ausgedrückt, sie ist vollständig durch den Inhalt anderer Variablen bestimmt.

Sie werden feststellen, daß im allgemeinen nur eine Handvoll Variablen unabhängige Werte haben. Die meisten anderen gelisteten Variablen enthalten letztlich ihren Wert durch diese kleine Gruppe, und man kann sie daher fast ignorieren.

Zusätzlich gibt es dann noch eine Vielzahl an Variablen, die Sie ohnehin nicht ändern sollten. Dies sind im allgemeinen Installationsprozeßeigene Variablen (zum Beispiel hat der IBM C++ Compiler eine Variable, die den Namen der Produkteigenen INI-Datei CXX36.INI festlegt). Mir will kein Grund einfallen, weshalb man dies ändern sollte.

Feature-Install selber setzt auch ein paar universelle Variablen; die gewöhnlichste, die Sie sicherlich entdecken werden, ist {BootDrive}, die immer auf das Systemstartlaufwerk zeigt.

Nebenbei bemerkt, Ihnen ist sicher aufgefallen, daß die Dialoge keine Möglichkeiten zum Ändern der Variablenwerte bieten. Das ist soweit ok; alles, was wir im Moment machen, ist Informationsbeschaffung. Ich werde gleich beschreiben, wie die Variablen modifiziert werden. Wir halten jetzt fest, welche wir modifizieren wollen, wenn die Zeit reif ist.

Herauszufinden, welche Variablen Sie modifizieren wollen, ist wahrscheinlich die größte Herausforderung der Installation von Feature-Install-Produkten über diesen Weg. Je häufiger Sie dies machen, um so mehr bekommen Sie ein Gefühl dafür, welche Variablen typischerweise modifiziert werden müssen und welche nicht. Im allgemeinen, und speziell wenn Sie gerade damit anfangen, sind die einzigen, die Sie ändern wollen die, die das Installationsverzeichnis bestimmen.

#### Die Mediapfad-Variable (wahlfrei)

Nun, wo ich das gesagt habe, es gibt da noch eine Variable, die Sie vielleicht modifizieren werden; diejenige, die angibt, wo die Produktinstallationsdateien lokalisiert sind. Bedenken Sie, das Installationsprogramm läuft als Objekt auf Ihrer Arbeitsoberfläche und hat daher keinen realen physischen Ort. Also weiß es gar nicht, wo die eigentlichen Produktdateien liegen, bis Sie es ihm erzählt haben.

Ich sagte 'vielleicht' im vorhergehenden Abschnitt, weil Feature-Install Sie nach dem richtigen Ort fragen wird, wenn es die Dateien selber nicht finden kann. Also ist dieser Schritt streng genommen wahlfrei.

Um herauszufinden, welche Variablen Sie ändern müssen, wechseln Sie zu dem Reiter, der Datenträgergruppen betitelt ist. Es sollte dann etwa so aussehen:

Bild 10. Install-Object-Einstellungen, Reiter: Datenträgergruppen

Diese Seite zeigt alle Installationsmedien, die für das Produkt definiert sind. Üblicherweise ist dies nur eines; in diesem Beispiel ist es die Installations-CD.

Ein Doppelklick darauf oder durch Drücken des Anzeigen-Knopfs bekommen Sie einen Dialog mit dem Media-Details angezeigt, einschließlich einer Listbox - die Media Definitions. Diese enthält Details zu jedem Eintrag in den Datenträgergruppen, was in diesem Fall alleine ein CDROM-Laufwerk ist. (Produkte, deren Datentägergruppe aus mehreren Disketten oder CDs besteht, werden hier wahrscheinlich mehrere Einträge aufweisen. Allerdings habe ich das in der Praxis noch nicht gesehen.) Ein Doppelklick auf die Media-Definitionen bringt einen neuen Dialog:

Detaillierte Ansicht der Media-Definition

Der Media Path-Wert ist der, der uns interessiert. Dieser sollte den Namen der Variablen enthalten, die wir ändern müssen (in diesem Beispiel ImageMediaPath).

Wenn Sie auf die Variablen-Seite zurückgehen, sollten Sie diese Variable irgendwo in der Liste sehen. Ihr Standardwert wird wahrscheinlich ziemlich lang und kryptisch sein (in meinem Beispiel ist es H:\portapak\PortaPak-solution\media). Der Grund für diesen merkwürdigen Vorgabewert liegt darin, daß IBM die gleiche Variable benutzt, wenn sie das endgültige Installationspaket auf ihren Systemen erstellt, und der alte Wert bleibt dann schon mal in der veröffentlichten Antwortdatei übrig. Wenn Sie CLIFI oder den Netscape einsetzen, wird der Wert automatisch überschrieben. Nur wenn man das Install-Object einsetzt, gibt es einen Grund, die Änderung selber durchzuführen

Das Verhalten der Variablen ist ein bißchen ungewöhnlich. Wenn der Media Type im Media-Definitionen-Dialog als CD spezifiziert ist (wie oben abgebildet), dann wird während der Installation jeder Laufwerksbuchstabe, der im Pfadwert angegeben ist, automatisch herausgefiltert und durch den Laufwerksbuchstaben des ersten CDROM-Laufwerks Ihres Systems ersetzt. (Es ist anzunehmen, daß es ähnlich aussieht, wenn derMedia Type auf Diskette lautet.)

Also, in meinem Beispiel, belasse ich mal die ImageMediaPath-Variable auf dem Vorgabewert H:\portapak\PortaPak-solution\media. Starte ich den Installationsprozeß, wird Feature-Install den Wert automatisch auf S:\portapak\PortaPak-solution\media ändern (weil S: mein CDROM-Laufwerksbuchstabe ist), und sucht dort die Produktdateien. Findet es dort nichts, wird es Sie nach dem richtigen Pfad fragen.

Bedenken Sie, daß Feature-Install wohl immer nach den Produktdateien auf dem ersten CDROM-Laufwerk in Ihrem System nachschauen wird. Haben Sie mehr als eines, und die Installations-CD ist nicht im ersten (gemäß Laufwerkbuchstaben), werden Sie wahrscheinlich sowieso gefragt werden, ob Sie die Variable nun zu ändern versuchen oder nicht..

### Verändern der Variablen

So, nun wissen wir, welche Variablen wir ändern müssen, und wir wissen (vermutlich), was ihre neuen Werte sein sollen. Aber wie bewerkstelligen wir das?

Bedauerlicherweise kann man die Variablen nicht direkt im Install-Object bearbeiten. Das scheint eine ziemliche Beschränkung zu sein, aber keine Angst: Es gibt viele Möglichkeiten die Aufgabe zu erledigen.

#### Methode A: Anwendung von Setup Strings

Das Install-Object ist ein WPS-Objekt wie jedes andere. Und wie jedes WPS-Objekt hat es grundlegende Eigenschaften. Eine davon ist, daß es über WPS-Setup-Strings umkonfiguriert werden kann. Zufälligerweise kann jede Variable eines Install-Objektes über einen Setup-String-Schlüsselwert angesprochen werden.

Jeder, der sich mit der OS/2-REXX-Programmierung auskennt, weiß, wie man Setup-Strings mit der `SysSetObjectData()`-Funktion erstellt. Und natürlich könnte man dies auch hier tun, und es würde gut funktionieren. Aber nicht jeder hat die Zeit, Fähigkeit und Muße, um REXX-Skripte für jede kleine Aufgabe zu schreiben..

Jeder der XWorkplace installiert hat (oder eWorkplace als Bestandteil von eCS 1.1 und höher), hat Zugriff auf das, was Setup String-Objekt genannt wird. Ziehen Sie einfach eines aus dem Schablonenordner auf Ihre Arbeitsoberfläche, dann öffnen Sie es und geben die Variablen ein, die Sie ändern wollen, jeweils als ein Schlüsselwort-Wertepaar je Zeile (`Variable=Wert`).

Bild 11. Das Setup String-Objekt

Zum Beispiel, bevor der IBM C/C++-Compiler installiert werden soll, will ich die InstDrv1 auf D: und InstDir1 auf Programs\IBMCXXO ändern. Dazu ziehe ich ein Setup String-Objekt aus meinem Schablonenordner, öffne es und gebe die Daten ein:

Bild 12. Setup String-Objekteinstellungen mit den zu ändernden Variablen

Nun muß ich nur noch das PPAK_FI-Install-Object auf das Setup String-Objekt, das ich gerade erzeugt habe, ziehen und die Variablen, die ich gerade spezifiziert habe, werden sofort aktualisiert.

Figure 13. Ziehen des Install-Objekts auf das Setup String-Objekt

Gehen wir nun zurück zu den Install-Objekteinstellungen, sehen wir, daß sich die Werte der Variablen, und alle anderen, die auf diesen basieren, geändert wurden:

Bild 14. Install-Objekteinstellungen mit aktualisierten Variablenwerten

So, nun wird der IBM C/C++ Compiler auf D:\Programs\IBMCXXO installiert. Sie werden bemerkt haben, daß ich mich nicht darum geschert habe, die Instxxx2-Variablen zu ändern. Das liegt daran, daß diese zu dem OS/2-Toolkit gehören, und ich dieses ohnehin nicht installieren möchte.

Wenn Sie weder XWorkplace noch eWorkplace installiert haben, können Sie ein ähnliches Objekt verwenden, das von Feature-Install mitgeliefert wird und das in der Dokumentation Install Helper-Objekt genannt wird. Diese Objekte gehören zur WPObjData-Klasse, und sie funktionieren auf ähnliche Weise wie Setup String-Objekte. Der einzige Unterschied ist, daß die Install-Helperobjekte eine Textdatei zum Speichern der Setup String-Daten erzeugt, und Sie setzen einen Texteditor ein, um diese zu bearbeiten.

Zum Anlegen eines Install-Helperobjekts auf Ihrer Arbeitsoberfläche führen Sie folgenden REXX-Code aus:

    /* OBJDATA.CMD */
    CALL RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
    CALL SysLoadFuncs
    CALL SysRegisterObjectClass 'WPObjData', 'OBJDATA.DLL'
    CALL SysCreateObject 'WPObjData', 'Install Helper.TXT', '<WP_DESKTOP>'

Die können dann dieses Objekt mit dem Texteditor öffnen, die Setup String-Daten in gleicher Weise eingeben, wie Sie es bei dem Setup String-Objekt machen würden (ein `Variable=Wert`-Paar pro Zeile), dann die Datei speichern und das Install-Object auf das Install-Helperobjekt ziehen.

Mehr Informationen zur Verwendung der WPObjDatei-Klassen erhalten Sie im e-zine-Artikel von Rich Walsh Using that Hammer and Screwdriver.

#### Methode B: Verwendung einer partiellen Antwortdatei

Alternativ können Sie die modifizierten Variablen auch in eine Textdatei eingeben und von dort laden. Diese Textdatei, die Feature-Install als partielle Antwortdatei kennt, muß wieder das Format von einem `Variable=Wert`-Paar pro Zeile haben.

Die Variablen sind die gleichen, die wir in der Setup String-Methode eingesetzt haben, mit einer zusätzlichen Anforderung: Sie müssen den Variablennamen mit der Top-Level-Feature-ID des zu installierenden Produktes einleiten. (Die ist der symbolische Name des Produktpakets als Ganzes, wie intern von Feature-Install verwendet.) Diese ID läßt sich leicht herausfinden, indem man sich die erste Seite des Install-Object-Einstellungsnotizbuch anschaut. Die ID wird gelistet als Installation Feature ID. Im Falle des C/C++-Compilers ist die ID zufällig ROOT.

Also erzeuge ich in diesem Fall eine Textdatei namens CXXVARS.RSP (der Dateiname ist nicht wichtig, aber er muß auf .RSP enden) mit dem Inhalt::

    ROOT.InstDrv1=D:
    ROOT.InstDir1=Programs\IBMCXXO

Nun müssen wir nur noch die Datei in das Install-Object laden. Erinnern Sie sich noch wie das geht? Nur ein Rechtsklick auf das Objekt um das Kontextmenü aufzurufen, dann Antwortdatei > Lesen, und wählen dann die partielle Antwortdatei.

Bild 15. Auswahl der partiellen Antwortdatei

Die Install-Object-Variablen werden mit den Werten aus der Datei aktualisiert.

Bild 16. Install-Object-Einstellungen mit den aktualisierten Variablenwerten

### Auswahl der Komponenten zur Installation

Der Rest ist einfach. Wenn Sie das Install-Object durch Doppelklicken öffnen, wird die Liste der verfügbaren Komponenten (oder Kind-Funktionen) angezeigt.

Bild 17. Auswahldialog der zu installierenden Features

Das sieht doch fast so aus, wie der Inhalt eines Objekte eines schon installierten Produktes (wie ich es zu Beginn des Artikels vorgestellt hatte). Der einzige Unterschied ist, daß der Hauptaktionsknopf nun Install heißt (und nicht Uninstall).

Wählen Sie nun einfach die Komponenten, die installiert werden sollen, indem Sie die Ankreuzfelder verwenden.

### Installieren des Produktes

Nachdem alles zu Ihrer Zufriedenheit eingestellt ist, klicken Sie einfach auf den Installknopf. Sie sehen dann einen Bestätigungsdialog, der ungefähr so aussieht:

Bild 18. Installationsbestätigungsdialog

Dieser listet alle Komponenten auf, die Sie gewählt haben. (Sie werden bemerken, daß ich in diesem Beispiel die Samples, die Open Class Source, oder das OS/2-Toolkit nicht ausgewählt habe; die zwei ersteren benötige ich nicht für mein Vorhaben, und das Toolkit, das mit dem C/C++-Compiler ausgeliefert wird, ist veraltet, also werde ich eine neuere Version separat installieren.)

Das Ankreuzfeld ist sinnvoll, wenn Sie ein Produkt erneut über eine bestehende Kopie installieren. Wenn Sie in ein neues, leeres Verzeichnis installieren, können Sie dieses unmarkiert lassen.

Klicken Sie auf Install um die Installation fortzusetzen.

Nun, erinneren Sie sich an die Media Path-Variable, die ich vorhin erwähnte? Ich habe festgestellt und bestimmt, wie es sein sollte, aber als ich meine Variablen gesetzt habe, habe ich versäumt sie zu bearbeiten. Also zeigt sie immer noch auf den Standardwert (in meinem Fall also H:\portapak\PortaPak-solution\media). Wie ich erwähnte, wird der CDROM-Laufwerksbuchstabe durch meinen ersetzt (S: in meinem Fall), also sucht Feature-Install nun auf S:\portapak\PortaPak-solution\media die Produktdatei. Weil die Dateien dort nicht zu finden sind, fordert es mich nun auf, den richtigen Pfad einzugeben:

Bild 19. Dialog zum Quellen-media path

Was also muß ich dort eingeben? Nun, es sollte der vollqualifizierte Name des Verzeichnisses sein, in welchem die originale Produktdefinitionsantwortdatei abgelegt war. Im Falle des C/C++-Compilers ist dies \COMPILER auf der Installations-CD. Also gebe ich ein:

    S:\compiler

und dann ein Klick auf OK. Die Installation sollte dann normal weiterlaufen.

Während das Produkt installiert wird, werden Sie eine Fortschrittsanzeige sehen, in etwa wie diese hier:

Bild 20. Fortschrittsanzeige

Und der folgende Dialog (oder etwas Vergleichbares) wird auftauchen, wenn die Installation abgeschlossen wird:

Bild 21. Installationsabschlußdialog

Hat das Produkt auch einen Arbeitsoberflächenordner, sollte dieser jetzt angelegt sein

Bild 22. Produkt-Arbeitsoberflächenordner

So, nun sind wir fertig. Nur noch einen Neustart, falls erforderlich, und das Produkt sollte zur Verwendung bereit sein.

Nebenbei, Sie können nun das Install-Object (PPAK_FIin diesem Beispiel) löschen, weil wir es nicht mehr benötigen. Auch die Setup String-Objekte, die Sie erstellt haben, können Sie nun wieder löschen.

## Schlußbemerkung

Feature-Install ist ein bemerkenswert flexibles Werkzeug, und man kann damit eine Menge erreichen. Aber ich habe festgestellt, daß die meisten Leute davon nichts wissen.

Ich habe angefangen diesen Artikel zu schreiben, als ich von der Warpstock 2004, wo ich an einer Vorführung zu VisualAge C++ teilgenommen hatte, nach Hause kam. Viele Leute hatten Schwierigkeiten VisualAge 4.0 zu installieren, da sie keinen Netscape auf ihrem System hatten. Als ich ihnen zeigte, wie man es stattdessen mit dem Install-Object installiert, haben mich einige von ihnen gedrängt, über den Prozeß im allgemeinen einen Artikel für VOICE zu schreiben. Was ich hiermit getan habe.

Es gibt jedoch noch eine Menge zum Feature-Install zu sagen. Ich hoffe noch ein paar Artikel zu schreiben, die dann einige dieser Dinge beschreiben.

Wenn alles gut läuft werde ich in der nächsten Fortsetzung dieser Serie die nicht überwachte Installation (CID) mittels CLIFI etwas detaillierter beschreiben. Ich werde auch ein paar Fehlerbeseitigungstechniken beschreiben, falls Probleme auftauchen sollten.

Übersetzung: Jürgen Gaida
Korrektur: Karl-Heinz Markus

##### Daten und Quellen

Feature Install information at WarpUpdates International: http://www.warpupdates.mynetcologne.de/english/inst_featureinstaller.html
OS/2 eZine article Using that Hammer and Screwdriver, by Rich Walsh: http://www.os2ezine.com/v3n07/hammer.htm