Die DesktopdateienErweitern von Windows PE

Wes Miller

Schon bevor wir Windows PE vor über fünf Jahren veröffentlichten, hatten uns eifrige Kunden um mehr Features gebeten. Leider war Windows PE, im Unterschied zu beispielsweise Windows XP Embedded, nicht für unkomplizierte Erweiterungen durch Hinzufügen neuer Betriebssystemschichten entworfen worden. Selbstverständlich musste Windows PE grundlegende

Unterstützung für Win32® bieten (damit die meisten Windows®-Anwendungen darunter funktionieren) und natürlich Netzwerk- und Massenspeicherfunktionen unterstützen, damit nicht nur über das Netzwerk kommuniziert, sondern auch Windows installiert werden konnte. Wir wollten die Shell von Anfang an einschränken: Durch den Einsatz von „cmd.exe“ statt der herkömmlichen Shell des Windows-Explorers begrenzten wir die Funktionalität der Windows PE-Umgebung, und was noch wichtiger war: Die Standardumgebung haben wir so gestaltet, dass sie für alle Automatisierungsaufgaben darin skriptfähig war.

Man kann Windows PE erweitern. Man muss nur stets bedenken, dass diesem Vorhaben Grenzen gesetzt sind. Sie können davon ausgehen, dass eine Anwendung nicht funktioniert oder nur fehlerhaft ausgeführt wird, wenn dafür eine der in Abbildung 1 aufgelisteten Anwendungen erforderlich ist. (Diese Aufzählung ist nicht vollständig.)

Figure 1 Fehlende Windows-APIs

.NET Framework (beliebige Version)
Active Directory® Service Interfaces (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (pre-.NET-Versionen eingeschlossen)
Jeder ausführbare Typ, für den ein Framework erforderlich ist, das nicht systemintern mit Windows installiert wird.
Windows-Explorer oder Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI (Windows-Sprachausgabe, E-Mail bzw. Telefonie-APIs)

Wenn Sie nicht wissen, wovon Ihre Anwendung abhängt, müssen Sie es herausfinden. Aber wie? Als wir versuchten, die ADO-, HTML Applications (HTA)- und Windows Script Host (WSH)-Komponenten unter Windows PE vor seiner Veröffentlichung zum Laufen zu bekommen, hatten wir dasselbe Problem. Wir möchten übrigens darauf hinweisen, dass dieser Artikel zwar Methoden enthält, wie man diese Abhängigkeiten aufspürt, dass das Hinzufügen von binärem Windows-Code zu ihrem Windows PE-Image, das über die Implikationen des MKIMG-Befehls hinausgeht, jedoch nicht vom Endbenutzer-Lizenzvertrag (End User License Agreement, EULA) abgedeckt wird. Sie benötigen eine Lizenzierungsergänzung von Microsoft, um entsprechende Änderungen in Ihrer Umgebung zu implementieren.

Erläuterung von Abhängigkeiten

Durch das Öffnen und gründliche Analysieren der .inf-Datei einer Anwendung in Editor können Sie viel lernen. Eigentlich bekommt man so oft am schnellsten heraus, was hinter einer Anwendung steckt und welche Abhängigkeiten sie hat. Das Wichtigste, was man über Windows PE wissen muss, ist, dass es normalerweise so eingeschränkt ist, dass man mehrere Ebenen von Abhängigkeiten zu debuggen hat – sowohl die direkten Abhängigkeiten der Anwendung als auch solche, die aus diesen Abhängigkeiten entstehen – um die Anwendung stabil ausführen zu können. Wenn man nicht aufpasst, kann dabei schnell eine wahre Kaskade aus Abhängigkeiten entstehen. Das zufällige (oder beabsichtigte) Hinzufügen einiger weniger Komponenten kann das Abbild erheblich an Größe und Komplexität zunehmen lassen.

Durch eine .inf-Datei, in der die Anwendung beschrieben wird, bekommen Sie Anhaltspunkte in Bezug auf die Abhängigkeiten, indem Sie nach Registrierungsschlüsseln und Dateien suchen, die von der .inf-Datei Ihrem System hinzugefügt werden. Suchen Sie nach den Abschnitten „CopyFiles“ und „AddReg“. Diese Eintragungen weisen auf Anwendungen, DLLs und andere Dateien hin, von denen Ihre Anwendung abhängt. Von den drei Add-Ins für Windows PE (ADO, HTA und WSH) war WSH am einfachsten zu erstellen. Da es immer noch eine weitervertreibbare WSH-Version für ältere Windows-Versionen gab und es heute eine in Windows integrierte .inf-Datei gibt, mit der die Dateizuordnungen für WSH vorgenommen werden (unter %windir%\inf\wsh.inf), war die Installation unter Windows PE verhältnismäßig einfach.

Orca und Erstellen von Snapshots

Wenn die betreffende Anwendung als Microsoft® Installer (MSI)-Datei verkauft wird, stehen Ihnen zwei Methoden für die Suche nach deren Abhängigkeiten zur Verfügung. Wenn Sie ein MSI-Experte sind, können Sie dazu Orca verwenden (ein Tool zum Bearbeiten von Windows Installer-Dateien, das im Rahmen des Windows Server® 2003 R2 Plattform SDK vertrieben wird): go.microsoft.com/fwlink/?LinkId=77941 Sie können den MSI auch für die gewünschten Komponenten installieren und eine Vorher/Nachher-Analyse der geänderten Dateien und Registrierungsschlüssel vornehmen. Sie können eine Sicherung von der Registrierung anlegen, die Anwendung installieren, die Registrierung erneut exportieren und anschließend WinDiff ausführen (siehe Randleiste „Verwenden von WinDiff“). Das Ergebnis lässt sich dann als Vorlage für Änderungen verwenden, die an der Registrierung vorzunehmen sind. Das Problem ist, dass es sich dabei um unzählige Änderungen handeln kann. Manchmal ist es jedoch am besten, wenn Sie keine .inf-Datei (oder den Autor der Anwendung) zur Verfügung haben.

Mit dem Prozess des Erstellens von Anwendungssnapshots werden Sie wahrscheinlich vertraut sein. Im Grunde genommen handelt es sich dabei um dieselbe Vorher-/Nachher-Analyse, die Sie durchführen, um Ihre Anwendung lauffähig zu bekommen. Früher war in Windows 2000 von Microsoft ein Tool enthalten, mit dem genau das möglich war. Leider funktionierte es mit späteren Windows-Versionen nicht mehr. Sie können zu diesem Zweck mittlerweile auf mehrere kommerzielle Anwendungen (so genannte Installationsrepackager) oder auch auf kostenlose Dienstprogramme zurückgreifen. Zum einen lässt sich dafür das Platform SDK installieren (siehe der Link im vorherigen Absatz), das WinDiff enthält. Hinweis: Wenn Sie mit WinDiff einen Vergleich durchführen möchten, sollten Sie die Anwendung im Idealfall auf Windows Server 2003, Service Pack 1 (SP1) installieren, da es sich dabei um die Version von Windows PE handelt, die zur Verwendung empfohlen wird: ein aus der Standard Edition oder Enterprise Edition (mit SP1) erstelltes Windows PE 1.6. Durch das Durchführen dieser Aufgabe unter Windows Server 2003 arbeiten Sie in einer Umgebung, die der von Windows PE am meisten ähnelt. Denken Sie daran, dass Sie MSI unter Windows PE nicht ausführen können. Folgen Sie den Schritten in der Randleiste „Verwenden von WinDiff“.

Dort finden Sie einen Großteil der Informationen, die geändert wurden. Bedauerlicherweise ist es nicht gerade einfach, die geänderten Informationen oder erfasste Dateien aus der Registrierung zu exportieren, um eine Art Manifest zur Installation Ihrer Anwendung zu erstellen. Sie müssen die Änderungen manuell implementieren. Dabei sind wir auf einige der größten Probleme mit der ersten Version von Windows PE gestoßen. Es war schon kompliziert, überhaupt die HTA-Komponenten zum Laufen zu bringen, da Microsoft sie außerhalb des Internet Explorers®) nicht definiert hatte. Durch Differenzierung konnten wir genügend HTA-Unterstützung bereitstellen, um es zum Laufen zu bringen. Sie können diese Schlüssel zwar manuell in die Registrierung von Windows PE einfügen, sollten damit aber warten, bis Windows PE hochgefahren ist. Sehen Sie sich die Dateien „OC.bat“ und „OC2.bat“ an, die zur Installation der HTA-, WSH- und/oder ADO-Unterstützung durch das Skript „buildoptionalcomponents.vbs“ aus den Buildtools von Windows PE verwendet wurden.

Nützliche Tools

Sogar nach dem Isolieren der direkten Abhängigkeiten findet man nicht immer alle Binärdateien, von denen Ihre Anwendung abhängt. Sie werden z. B. nicht wissen, ob sie zur Durchführung ihrer Aufgaben noch zusätzliche DLL- oder OCX-Dateien benötigen. Woher weiß man das? Mark Russinovich von Sysinternals (jetzt Technical Fellow bei Microsoft) hat ein praktisches Dienstprogramm namens „listdlls“ geschrieben, das genau diese Lücke füllt. Listdlls kann von microsoft.com/technet/sysinternals/utilities/ListDlls.mspx heruntergeladen werden. Um das Dienstprogramm zu verwenden, führen Sie den Befehl „listdlls.exe > dlls.txt“ aus, und sehen Sie sich die ausgegebenen Daten näher an. Abbildung 2 spiegelt die Ausgabe von listdlls nach der Ausführung auf sich selbst wider. Sie können diese Liste mit den DLL- und OCX-Dateien in Windows PE vergleichen, um zu bestimmen, ob alle Abhängigkeiten Ihrer Anwendung an der richtigen Stelle sind oder nicht (im Fall von listdlls sind sie bereits vorhanden). Bei der HTA-Unterstützung unter Windows PE war listdlls ganz wichtig für die Identifizierung bestimmter Abhängigkeiten, die sonst nicht aufzufinden waren.

Abbildung 2 Ausgabe von lisdlls nach Ausführung auf sich selbst

Abbildung 2** Ausgabe von lisdlls nach Ausführung auf sich selbst **(Klicken Sie zum Vergrößern auf das Bild)

Das bedeutet aber nicht, dass eine aufgelistete DLL auch unbedingt erforderlich ist, damit die Anwendung funktioniert. Wenn Sie z. B. Editor laden, lädt es die Datei „uxtheme.dll“ mit. Unter Windows PE ist diese DLL nicht verfügbar, und da Windows-Designs dort keine Verwendung finden, wird diese auch nie geladen. Man muss sich klar machen, welche von den durch listdlls angezeigten DLLs wirklich erforderlich sind, und welche bei Bedarf von Windows geladen werden. Das ist leider eine schwierige Angelegenheit. Man kann sich diese Fähigkeit entweder durch Ausprobieren oder durch Untersuchen der grundlegenden Ebenen von Windows aneignen. (Dazu empfehle ich das Buch Microsoft Windows Internals, Fourth Edition (Microsoft Press® 2004) von Mark Russinovich und David Solomon.)

Mark hat übrigens auch dieselbe Funktionalität in dem frei verfügbaren „Process Explorer“ (Ersatz für den Task-Manager von Windows) bereitgestellt. Der Unterschied besteht meiner Meinung nach darin, dass die von listdlls ausgegebenen Daten leichter bearbeitbare Skripts enthalten und sich besser für das Finden und Sammeln fehlender Abhängigkeiten eignen.

Bedenken Sie, dass Sie auch nach dem Hinzufügen einer DLL zu einem Abbild durchaus etwas zu tun haben könnten. Das heißt, es gibt zwei Arten von DLLs: solche, die registriert werden müssen, und solche, bei denen das nicht erforderlich ist. Leider kann man sie nicht so leicht voneinander unterscheiden. Man muss sie einzeln registrieren, um das herauszufinden. Führen Sie zum Registrieren einer DLL oder einer OCX „regsvr32 dllname.dll“ aus. Wenn es funktioniert, erhalten Sie eine Mitteilung, dass die DLL registriert wurde. Wenn nicht, erhalten Sie entweder keine Mitteilung, oder es wird ein Dialogfeld angezeigt, das Sie darüber informiert, dass die DLL nicht registriert wurde oder nicht registriert werden konnte. Beim Entwickeln der optionalen HTA- und ADO-Komponenten für Windows PE fanden wir heraus, dass DLLs bei der Durchführung ihrer Registrierung beschreibbaren Speicher brauchen, um entweder temporär eine .inf-Datei für die Installation abzulegen oder eine andere Abhängigkeit (z. B. ein bestimmtes Verzeichnis) aufzuzeichnen. Unter Windows PE bedeutete das, dass Fehler auftraten. Glücklicherweise können solche Aufgaben unter Windows PE 2.0 durchgeführt werden, da es jetzt standardmäßig einen sicheren Speicherbereich für temporäre Dateien gibt.

Außerdem hat Mark vor kurzem noch ein drittes Tool namens „Process Monitor“ veröffentlicht. Process Monitor kann als eine Art Superset von „Regmon“ und „Filemon“ betrachtet werden und bietet noch erheblich mehr Details als beide Programme zusammen, weil es dem Anwender eine ganz neue Ebene der Kommunikation zwischen Prozessen eröffnet. Dieses unglaublich leistungsfähige Tool kann Ihnen dabei helfen, Anwendungsfehler unter Windows zu beheben, und Ihnen Fragen zu gegenseitigen Abhängigkeiten von DLLs beantworten. Sie können Process Monitor herunterladen.

Entfernen von Windows PE-Dateien

Außer der Möglichkeit, Windows PE etwas hinzuzufügen, wurde oft eine zweite Bitte laut: Das Betriebssystem selbst sollte verkleinert werden. Sie können verschiedene Schritte unternehmen, um den Umfang von Windows PE etwas zu verringern. Ihre lizenzierte Kopie von Windows PE müsste eine Sammlung von Buildtools und eine Dokumentation umfassen. Eines der Dokumente ist eine Hilfedatei namens „winpe.chm“. Wenn Sie diese Datei öffnen und sich den Abschnitt mit dem Benutzerhandbuch für die Vorinstallationsumgebung durchlesen, stoßen Sie auf ein Thema, das sich mit der Verringerung der Größe von Windows PE beschäftigt. In diesem Abschnitt finden Sie eine Liste mit Dateien, die Sie beruhigt entfernen können, vorausgesetzt, Sie benötigen sie nicht für Ihre Zwecke. Die entfernbaren Dateien werden in drei Abschnitten behandelt:

  • Schriftartendateien können immer problemlos entfernt werden.
  • Netzwerkbezogene .inf-Dateien und Dienstprogramme können auch entfernt werden, doch das sollten Sie nur dann tun, wenn Sie Ihren Build überhaupt nicht in einem Netzwerk verwenden möchten.
  • Befehlszeilenprogramme sollten nicht entfernt werden. Ich rate Ihnen davon ab, solche Programme zu entfernen, wenn Sie nicht ganz genau wissen, welche Aufgaben diese haben und welche Folgen ein Entfernen haben könnte.

Wenn Sie wissen, welche Dateien Sie guten Gewissens ausschließen können, schreiben Sie einfach eine Batchdatei oder ein Skript, lassen Sie „mkimg.com“ den Build fertig stellen, und entfernen Sie anschließend Ihre Auswahl aus Windows PE.

Ändern der Windows PE-Registrierung

Sie werden bemerkt haben, dass wir die optionalen Komponenten absichtlich nicht zusammen mit dem Build installiert haben. Obwohl das ein bisschen mehr Zeit zur Laufzeit bedeutete, mussten wir auf der anderen Seite keine völlig neue Methode erfinden, um diese Komponenten wieder in Windows PE zu integrieren. Dazu hatten wir nämlich keine Zeit, und wenn es hart auf hart gekommen wäre, hätten wir die Komponenten ganz weglassen müssen. Doch was, wenn man eine Änderung an der Registrierung vornehmen will (wie das Einfügen eines Deltas mit den Registrierungsänderungen für Ihre Anwendung) oder einen Schlüssel bearbeiten möchte, mit dem die Anwendung vielleicht lauffähig bleibt? Das geht mit „regedit“ ganz einfach (siehe Abbildung 3). Führen Sie die folgenden Schritte aus:

  1. Führen Sie „regedit“ aus, und wählen Sie die Struktur HKEY_LOCAL_MACHINE.
  2. Wählen Sie „File“ (Datei) | „Load Hive“ (Struktur laden), und suchen Sie nach dem Speicherort Ihres Windows PE-Builds. Wählen Sie „setupreg.hiv“ unter I386\System32\ (oder MiniNT\System32, wenn Sie das Abbild auf einer Festplatte ablegen wollen).
  3. Geben Sie einen vorläufigen Namen für die Struktur wie z. B. „WinPE“ ein, und navigieren Sie unter HKLM zu diesem Knoten.
  4. Ändern Sie diesen Schlüssel entsprechend. Interessanterweise ist dieser Knoten eigentlich identisch mit dem Knoten „HKLM\System“, den man auf einer normalen Windows-Installation findet.
  5. Wenn Sie Ihre Änderungen durchgeführt haben, wählen Sie den Schlüssel unter HKLM aus, den Sie in Schritt 3 erstellt haben. Achten Sie dabei auf eine korrekte Durchführung, sonst beschädigen Sie u. U. Ihr System.
  6. Wählen Sie „File“ (Datei) | „Unload Hive“ (Struktur entfernen), und bestätigen Sie das Ja/Nein-Dialogfeld. Achten Sie darauf, die Registrierung jedes Mal freizugeben, denn eine Sperre verhindert ein erfolgreiches Build von Windows PE.

Abbildung 3 Öffnen der Windows PE-Registrierung

Abbildung 3** Öffnen der Windows PE-Registrierung **(Klicken Sie zum Vergrößern auf das Bild)

HKLM\System ändern Sie, indem Sie die nachfolgenden Schritte ausführen. Unter I386\System32 gibt es noch zwei weitere Schlüssel, mit denen Sie andere Bereiche der Registrierung ändern können: DEFAULT, die Standardstruktur für Benutzer (auch SYSTEM, das Sie ausführen, während Sie Windows PE verwenden), und SOFTWARE, das identisch mit HKLM\Software ist. Ändern Sie die Registrierung wie immer mit der größten Sorgfalt, und führen Sie dabei nur wirklich erforderliche Schritte aus.

Jetzt wissen Sie ungefähr, wie Sie Ihr Lieblingstool für die Fehlerbehebung oder Wiederherstellung auf Windows PE migrieren können. Nächsten Monat bespreche ich die PSTools-Suite mit Ihnen, eine Sammlung sehr nützlicher Tools für die Systemverwaltung, die ebenfalls von Mark Russinovich geschrieben wurden.

Verwenden von WinDiff

WinDiff kann Ihnen helfen, die Abhängigkeiten ihrer Anwendung zu finden. Führen Sie die folgenden Schritte für eine erfolgreiche Installation und Ausführung aus:

  1. Bereiten Sie Ihr System für die Installation vor. Die Zeiten und die Änderungen an Dateien oder der Registrierung zwischen dem ursprünglichen und finalen Snapshot müssen auf ein Minimum reduziert werden.
  2. Öffnen Sie die Eingabeaufforderung, und führen Sie „reg export HKLM C:\HKLM1.reg“ aus, um die Registrierungsstruktur von HKEY_Local_Machine vollständig zu exportieren.
  3. Führen Sie „dir C:\*.* /S > C:\C1.txt“ aus, um ein Abbild aller Dateien auf Laufwerk C: zu erstellen, falls C: Ihr Systemlaufwerk ist.
  4. Installieren Sie Ihre Anwendung, und konfigurieren Sie alle Einstellungen, die nach der Installation vorzunehmen sind.
  5. Führen Sie „reg export HKLM C:\HKLM2.reg“ aus.
  6. Führen Sie „dir C:\*.* /S > C:\C2.txt“ aus.
  7. Öffnen Sie WinDiff, und wählen Sie „File“ (Datei) | „Compare Files...“ (Dateien vergleichen...). Danach wählen Sie HKLM1.reg im ersten Dateifeld zu Öffnen der Datei aus und HKLM2.reg im zweiten.
  8. Eine in roter Schrift dargestellte Meldung teilt Ihnen mit, welche davon neueren Datums ist. Seien Sie geduldig: Der Vorgang kann etwas dauern, da die HKLM-Exporte manchmal ziemlich groß sind.
  9. Doppelklicken Sie auf den roten Text, um die Unterschiede zu erweitern.
  10. Sie können bestimmen, welche Daten in dem Vergleich angezeigt werden sollen, indem Sie „Options“ (Optionen) | Show Right-Only Lines“ (Nur-Rechts-Zeilen anzeigen) auswählen. Dadurch werden nur die neu hinzugefügten Zeilen in der zweiten Vergleichsdatei angezeigt. Sie sehen also dort nur neue Dateien und Registrierungsschlüssel.

Hinweis: Es kann sein, dass Sie die Find-Funktion einsetzen müssen, um Schlüssel zu finden, die sich auf Ihre Anwendung beziehen. In den Abbildungen A und B sehen Sie Datei- und Registrierungsänderungen an einer Beispieldatei, die ich erstellt habe. Zum Glück kann man in WinDiff auch kopieren und einfügen. Um diese Funktionen zu verwenden, klicken Sie einfach auf die !>-Zeile und wählen die gewünschten Zeilen aus.

Abbildung A WinDiff-Einträge

Abbildung A** WinDiff-Einträge **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung B Bestimmter Schlüssel in WinDiff

Abbildung B** Bestimmter Schlüssel in WinDiff **(Klicken Sie zum Vergrößern auf das Bild)

Wes Miller ist Entwicklungsmanager bei Pluck (www.pluck.com) in Austin, Texas. Davor arbeitete er bei Winternals Software in Austin und bei Microsoft als Programm-Manager und Produktmanager für Windows. Sie können Wes erreichen unter technet@getwired.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.