Erstellen von Apps für Windows PE

Windows PE (WinPE) ist für unabhängige Softwareanbieter (Independent Software Vendor, ISV) und Originalgerätehersteller (Original Equipment manufacturer, OEM) zum Erstellen benutzerdefinierter Dienstprogramme für die Bereitstellung und Wiederherstellung lizenziert. In diesem Thema finden ISVs und OEMs Richtlinien zum Entwickeln von Bereitstellungs- und Wiederherstellungs-Apps, die in Windows PE ausgeführt werden.

noteHinweis
Windows PE ist kein Betriebssystem für die allgemeine Verwendung. Es darf ausschließlich für die Bereitstellung und Wiederherstellung verwendet werden. Das Betriebssystem darf nicht als Thin Client oder als eingebettetes Betriebssystem verwendet werden. Für diese Zwecke stehen andere Microsoft®-Produkte zur Verfügung, z. B. Windows Embedded CE.

Bei der Mehrzahl der Windows PE-Anwendungen handelt es sich um Shell-Apps mit einer festgelegten Funktion und einer eigenen GUI. Hierzu zählen beispielsweise die Windows Setup-Anwendung und die Windows-Wiederherstellungsumgebung (Windows Recovery Environment, Windows RE).

  • Falls das Anzeigen einer Eingabeaufforderung für Ihre App geeignet ist, bearbeiten Sie „Startnet.cmd“ – dies ist die einfachste Art, eine App automatisch zu starten. Siehe WinPE: Bereitstellen und Anpassen.

  • Wenn Ihre App die Eingabeaufforderung umgehen und in Ihre GUI starten soll, verwenden Sie „Winpeshl.exe“, „Wpeinit.exe“, „wpeutil.exe“ und „wpeutil.dll“.

„Winpeshl.exe“ ist standardmäßig der erste Prozess, der nach dem Start von Windows PE ausgeführt wird. Dies wird durch den folgenden Registrierungseintrag des Typs REG_SZ angegeben.

HKEY_LOCAL_MACHINE
   System
      Setup
         CmdLine

„Winpeshl.exe“ sucht die Datei „Winpeshl.ini“. Wenn die Datei nicht vorhanden ist, startet „Winpeshl.exe“ einen „Cmd.exe“-Prozess, der das Skript „Startnet.cmd“ ausführt. Wenn „Winpeshl.ini“ vorhanden ist und zu startende Apps enthält, werden diese Apps anstelle von „Cmd.exe“ gestartet.

„Wpeinit.exe“ installiert Plug & Play-Geräte (PnP-Geräte), die den Netzwerkstapel starten und „Unattend.xml“-Einstellungen beim Start von Windows PE verarbeiten. Weitere Informationen finden Sie unter "Wpeinit" und "Startnet.cmd": Verwenden von WinPE-Startskripts.

Sie können das Netzwerk jederzeit starten, indem Sie die Ausführung von „Wpeinit.exe“ beim Start von Windows PE zulassen oder indem Sie den Befehl Befehlszeilenoptionen von Wpeutil ausführen.

Benutzerdefinierte Shell-Apps können mit den Funktionen LoadLibrary und GetProcAddress direkt in „Wpeutil.dll“ aufgerufen werden. Weitere Informationen finden Sie unter INFO: Alternativen zur Verwendung von „GetProcAddress()“ mit „LoadLibrary()“.

Alle von „Wpeutil.dll“ exportierten Funktionen verfügen über dieselbe Funktionssignatur wie WinMain Function, wie im folgenden Beispielcode dargestellt.

int InitializeNetworkingW(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);

Der folgende Beispielcode veranschaulicht die Initialisierung des Netzwerks.

#include <windows.h>
#include <tchar.h>
#include <stdio.h>
typedef int (*WpeutilFunction)( 
HINSTANCE hInst, 
HINSTANCE hPrev, 
LPTSTR lpszCmdLine, 
int nCmdShow 
);
int __cdecl _tmain( int argc, TCHAR *argv[] )
{
    
HMODULE         hWpeutil          = NULL;
    
WpeutilFunction InitializeNetwork = NULL;
    
int             result            = 0;
    
TCHAR           szCmdLine[]       = _T("");
    
hWpeutil = LoadLibrary( _T("wpeutil") );
    
if( NULL == hWpeutil )
    
{
        _tprintf( _T("Unable to load wpeutil.dll \ n") );
        
return GetLastError();
}
    
InitializeNetwork = (WpeutilFunction)GetProcAddress( 
hWpeutil, 
"InitializeNetworkW" 
);
    
if( NULL == InitializeNetwork )
    
{
        
FreeLibrary( hWpeutil );
        
return GetLastError();
    
}
    
result = InitializeNetwork( NULL, NULL, szCmdLine, SW_SHOW );
    
if( ERROR_SUCCESS == result )
    
{
        _tprintf( _T("Network initialized. \ n") );
    
}
  
else
    
{
        _tprintf( _T("Initialize failed: 0x%08x"), result );
    
}
    
FreeLibrary( hWpeutil );

return result;}

Eine vollständige Liste der von „Wpeutil.dll“ exportierten Funktionen finden Sie unter Befehlszeilenoptionen von Wpeutil.

Manche der grundlegenden Visual Studio-Projekteinstellungen können von den Standardeinstellungen, die vom Visual Studio-Projektassistent erstellt werden, abweichen. Sie müssen die Einstellungen Ihres Projektbuilds so einrichten, dass die produzierten Apps und DLLs mit Windows PE kompatibel sind. Gehen Sie dazu wie folgt vor:

  1. Windows PE-Apps müssen mit systemeigenen Code in C oder C++ entwickelt werden, der weder Microsoft Foundation Class (MFC) noch Active Template Library (ATL) verwendet. Das heißt, wenn Sie den Visual Studio-Projektassistenten verwenden, müssen Sie ein Win32-Projekt auswählen und sicherstellen, dass weder MFC noch ATL ausgewählt ist.

  2. Legen Sie die Projektoptionen so fest, dass auf die statischen C/C++-Laufzeitbibliotheken und nicht auf die DLL-Version von „Msvcrt.dll“ verwiesen wird.

  3. Öffnen Sie die Eigenschaften Ihres Projekts und legen Sie für Konfigurationseigenschaften \ C/C++-Laufzeitbibliothek die Option Multithreaded oder Multithreaded-Debug fest. Wählen Sie keine DLL-Version aus. Wenn Sie diesen Schritt nicht ausführen, kann Ihre App möglicherweise nicht unter Windows PE ausgeführt werden.

  4. Wenn Ihre App von der 64-Bit-Version von Windows PE gehostet werden soll, legen Sie in den Projektbuildoptionen fest, dass alle Binärdateien mit dem x64-Compiler in Visual Studio kompiliert werden sollen.

  5. Wenn Ihre App von der 32-Bit-Version von Windows PE gehostet werden soll, legen Sie in den Projektoptionen fest, dass die Kompilierung mit dem x86-Compiler erfolgen soll.

  6. Stellen Sie sicher, dass in Ihrem Projekt nicht die Compileroption „/clr:“ ausgewählt ist. Mit dieser Option wird verwalteter C++-Code generiert, der unter Windows PE nicht ausgeführt werden kann.

WarningWarnung
Ihre App kann benutzerdefinierte DLL-Dateien verwenden, die Sie selber schreiben oder von einem Drittanbieter in Lizenz nutzen. Fügen Sie diese DLL-Dateien zur Ihrer App für Windows PE hinzu. Verwenden Sie jedoch nicht „Msvcrt.dll“, und fügen Sie keine zusätzlichen Windows-DLL-Dateien ein, die nicht Teil von Windows PE sind.

Windows PE ist ein schlankes Bootstrap-Betriebssystem, das auf einer Teilmenge der Komponenten des Windows-Betriebssystems basiert. Das System ist als Host für Bereitstellungs- und Wiederherstellungsanwendungen konzipiert. Es enthält daher zahlreiche zum Hosten der APIs erforderliche Windows-Binärdateien, die für Apps dieser Klasse am wichtigsten sind. Aufgrund von Größen- und anderen designhabhängigen Einschränkungen sind nicht alle Windows-Binärdateien in Windows PE enthalten, d. h., nicht alle Windows-APIs sind vorhanden oder verwendbar.

Die foglenden APIs werden in Windows PE unterstützt:

  1. Windows-API-Sätze (Mincore.lib).

  2. Deployment Image Servicing and Management (DISM)-API (Dismapi.lib).

  3. Imageerstellungs-APIs für Windows (Wimgapi.lib).

APIs, deren Verhalten mit dem Verhalten auf einem vollständigen Windows-Betriebssystem identisch ist und den Beschreibungen im Windows SDK für Windows-Betriebssysteme entspricht, zählen zu den unterstützten APIs und können von Apps verwendet werden, wenn nicht anders angegeben. Windows PE basiert auf Windows-Komponenten und enthält daher viele Windows-APIs, die im Windows SDK für das Windows-Betriebssystem veröffentlicht sind. Die Parameter, Aufrufkonventionen und das Verhalten dieser unterstützten APIs sind mit denen eines vollständigen Windows-Betriebssystems identisch oder nahezu identisch, es sei denn, sie werden von der eindeutigen Windows PE-Umgebung beeinflusst. Apps, die ausschließlich diese APIs verwenden, können in der Regel unter dem vollständigen Windows-Betriebssystem und unter Windows PE verwendet werden.

In manchen Fälle kann ein Teil der möglichen Parameterwerte in Windows PE verwendet werden. Dies hängt von den spezifischen Bedingungen der Laufzeitumgebung ab, wie z. B. die Ausführung auf einem schreibgeschützten Medium ohne Zugriff auf einen beständigen Zustand oder andere designabhängige Einschränkungen. In diesem Fall wird die API möglicherweise nicht unterstützt. Die API kann dennoch verwendet werden, um eine spezifische Aufgabe zu erfüllen, für die es ansonsten keine Alternative gibt.

Grundsätzlich gilt, dass APIs, die unter Windows PE nicht ordnungsgemäß oder überhaupt nicht ausgeführt werden, nicht unterstützt werden. Diese APIs dürfen daher nicht verwendet werden, auch wenn sich die API in einer Binärdatei befindet, die in Windows PE enthalten ist. Die Ausführung der APIs schlägt möglicherweise fehl, weil Windows PE nur einen kleinen Teil des Windows-Betriebssystems umfasst. Möglicherweise geht die Ursache aber auch auf Windows PE-spezifische Überlegungen zum Laufzeitdesign zurück. Solche Fehler werden nicht als Fehler in Windows PE eingestuft.

Da zahlreiche Windows-Komponenten in Windows PE nicht vorhanden sind, stehen viele APIs nicht zur Verfügung. Entweder fehlen diese APIs vollständig, weil die Windows-Binärdatei, in der sie sich befinden, nicht vorhanden ist; oder die APIs sind nur teilweise vorhanden, weil zwar die Windows-Binärdatei, in der sie sich befinden, vorhanden ist, eine oder mehrere Binärdateien, von der sie abhängen, jedoch nicht. Darüber hinaus funktionieren manche der in Windows PE vorhandenen APIs nicht ordnungsgemäß oder verhalten sich anders als unter Windows. Diese APIs werden nicht unterstützt und dürfen nicht verwendet werden, da ihre Verhalten in Windows PE nicht definiert ist.

Es kann daher vorkommen, dass keine passende API zur Durchführung einer speziellen Aufgabe vorliegt. Um eine alternative Lösung zu finden, ist möglicherweise eine andere App-Logik, ein anderes Algorithmusdesign oder eine Neudefinition des zugrunde liegenden Problems erforderlich.

Siehe auch

Anzeigen:
© 2014 Microsoft