WinPE: Erstellen von Apps
Windows PE (WinPE) ist für Originalgerätehersteller (OEMs) lizenziert, die damit angepasste Dienstprogramme für Bereitstellung und Wiederherstellung erstellen können. Dieses Thema enthält Richtlinien für OEMs zum Entwickeln von Bereitstellungs- und Wiederherstellungs-Apps, die unter Windows PE ausgeführt werden.
Hinweis Windows PE ist kein allgemeines Betriebssystem. Außer für die Bereitstellung und Wiederherstellung kann es nicht anderweitig verwendet werden, beispielsweise nicht als Thin-Client- oder Embedded-Betriebssystem.
Erweiterbarkeit
Die meisten Windows PE-Apps sind Shell-Apps mit festgelegter Funktion und eigener GUI. Zwei Beispiele sind die Windows Setup-App und die Windows-Wiederherstellungsumgebung (Windows RE).
Wenn es akzeptabel ist, eine Eingabeaufforderung anzuzeigen, ändern Sie „Startnet.cmd“ – dies ist die einfachste Möglichkeit, eine App automatisch zu starten. Siehe WinPE: Bereitstellen und Anpassen
Um die Befehlszeile zu umgehen und die App in der GUI zu starten, verwenden Sie Winpeshl.exe, Wpeinit.exe, wpeutil.exe und wpeutil.dll.
Winpeshl.exe, Wpeinit.exe, wpeutil.exe und wpeutil.dll
Standardmäßig ist Winpeshl.exe der erste Prozess, der beim Start von Windows PE ausgeführt wird. Dies wird durch den folgenden Registrierungswert des Typs REG_SZ festgelegt.
HKEY_LOCAL_MACHINE
System
Setup
CmdLine
Winpeshl.exe sucht nach einer Datei namens Winpeshl.ini. Wenn die Datei nicht vorhanden ist, startet Winpeshl.exe einen Cmd.exe-Prozess, der das Startnet.cmd-Skript ausführt. Wenn Winpeshl.ini vorhanden ist und Apps zum Starten enthält, werden diese Apps anstelle von Cmd.exe ausgeführt.
Wpeinit.exe installiert Plug & Play (PnP)-Geräte, indem beim Start von Windows PE der Netzwerkstapel gestartet wird und Unattend.xml-Einstellungen verarbeiten werden. Weitere Informationen finden Sie unter Wpeinit und Startnet.cmd: Verwenden von WinPE-Startskripts.
Networking kann jederzeit gestartet werden, indem Sie entweder zulassen, dass beim Start von Windows PE Wpeinit.exe ausgeführt wird, oder indem Sie einen Befehl aus Wpeutil-Befehlszeilenoptionen ausführen.
Angepasste Shell-Apps können mit den Funktionen LoadLibrary und GetProcAddress direkt Aufrufe in die Wpeutil.dll ausführen.
Jede der von Wpeutil.dll exportierten Funktionen weist dieselbe Funktionssignatur wie die WinMain-Funktion auf, wie im folgenden Codebeispiel dargestellt.
int InitializeNetworkingW(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
Im folgenden Codebeispiel wird veranschaulicht, wie Networking initialisiert wird.
#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 Wpeutil.dll-Exporte finden Sie unter Wpeutil-Befehlszeilenoptionen.
Visual Studio-Projekteinstellungen
Einige grundlegende Visual Studio-Projekteinstellungen unterscheiden sich möglicherweise von den Standardeinstellungen, die vom Visual Studio-Projekt-Assistenten erstellt wurden. Richten Sie die Buildeinstellungen Ihres Projekts folgendermaßen ein, damit Apps und DLLs erstellt werden, die mit Windows PE kompatibel sind:
Sie müssen Windows PE-Apps mit nativem C- oder C++-Code entwickeln, in dem MFC oder ATL nicht verwendet wird. Wählen Sie daher ein Win32-Projekt aus, und stellen Sie sicher, dass weder MFC noch ATL aktiviert ist, wenn Sie den Visual Studio-Projekt-Assistenten verwenden.
Legen Sie Ihre Projektoptionen so fest, dass eine Verknüpfung mit den statischen C/C++-Laufzeitbibliotheken und nicht mit der DLL-Version von Msvcrt.dll hergestellt wird.
Öffnen Sie die Projekteigenschaften, und legen Sie Konfigurationseigenschaften/C/C++-Laufzeitbibliothek auf Multithreaded oder Multithreaded-Debug fest, nicht auf eine der DLL-Versionen. Wenn Sie diesen Schritt nicht ausführen, wird Ihre App möglicherweise nicht unter Windows PE ausgeführt.
Wenn Sie Ihre App auf der 64-Bit-Version von Windows PE hosten möchten, legen Sie die Projektbuildoptionen so fest, dass alle Binärdateien mit dem x64-Compiler in Visual Studio kompiliert werden.
Wenn Sie Ihre App auf der 32-Bit-Version von Windows PE hosten möchten, legen Sie die Projektoptionen so fest, dass mit dem x86-Compiler kompiliert wird.
Stellen Sie sicher, dass für Ihr Projekt die Compileroption „/clr:“ nicht festgelegt ist. Diese Option erzeugt verwalteten C++-Code, der nicht unter Windows PE ausgeführt wird.
Warnung Ihre App kann angepasste DLL-Dateien verwenden, die Sie selbst schreiben oder von einem Dritten lizenzieren. Fügen Sie diese DLL-Dateien Ihrer App für Windows PE hinzu. Verwenden Sie jedoch Msvcrt.dll nicht, und beziehen Sie keine zusätzlichen Windows-DLL-Dateien ein, die nicht Teil von Windows PE sind.
API-Kompatibilitätsreferenz
Windows PE ist ein schlankes Bootstrap-Betriebssystem, das auf einer Teilmenge von Komponenten aus dem Windows-Betriebssystem basiert. Es ist für das Hosten von Bereitstellungs- und Wiederherstellungs-Apps konzipiert. Daher enthält es viele Windows-Binärdateien, die zum Hosten der APIs benötigt werden, die für diese App-Klassen am wichtigsten sind. Aufgrund der Größe und anderer konstruktiver Beschränkungen sind nicht alle Windows-Binärdateien in Windows PE vorhanden, und daher sind auch nicht alle Windows-APIs vorhanden oder verwendbar.
Unterstützte APIs in Windows PE
Die folgenden APIs werden in Windows PE unterstützt:
Wenn sich eine API genauso verhält wie im vollständigen Windows-Betriebssystem und wie im Windows SDK für das Windows-Betriebssystem dokumentiert, wird sie als unterstützt angesehen und kann von Anwendungen verwendet werden, sofern nicht anders angegeben. Da Windows PE auf Komponenten von Windows basiert, enthält es eine erhebliche Teilmenge von Windows-APIs, die im Windows SDK für das Windows-Betriebssystem veröffentlicht sind. Die Parameter, Aufrufkonventionen und Verhaltensweisen dieser unterstützten APIs sind identisch oder nahezu identisch mit dem vollständigen Windows-Betriebssystem, es sei denn, sie sind von der spezifischen Windows PE-Umgebung betroffen. Apps, die nur diese APIs verwenden, sollten zwischen dem vollständigen Windows-Betriebssystem und Windows PE portierbar sein.
In einigen Fällen kann eine Teilmenge der möglichen Parameterwerte in Windows PE verwendet werden. Dies kann auf Bedingungen zurückzuführen sein, die für die Laufzeitumgebung eindeutig sind, etwa die Ausführung auf einem schreibgeschützten Medium, kein Zugriff auf den beständigen Status oder andere Entwurfsbeschränkungen. In diesem Fall wird die API möglicherweise nicht unterstützt, kann jedoch weiterhin verwendet werden, um eine bestimmte Aufgabe auszuführen, wenn keine andere Alternative vorhanden ist.
Im Allgemeinen gilt: Wenn eine API unter Windows PE nicht oder nur fehlerhaft funktioniert, wird sie nicht unterstützt und darf nicht verwendet werden, selbst wenn sie sich in einer Binärdatei befindet, die in Windows PE enthalten ist. Die API kann fehlschlagen, da Windows PE eine Teilmenge des Windows-Betriebssystems ist oder aufgrund der für Windows PE spezifischen Laufzeitentwurfsaspekte. Solche Fehler gelten in Windows PE nicht als Fehler.
Da viele Windows-Komponenten in Windows PE nicht vorhanden sind, sind viele APIs nicht verfügbar. Möglicherweise fehlen sie vollständig, weil die Windows-Binärdatei, in der sie sich befinden, nicht vorhanden ist. Sie können auch nur teilweise vorhanden sein, da die Windows-Binärdatei, in der sie sich befinden, zwar vorhanden ist, eine oder mehrere Binärdateien, von denen sie abhängig sind, aber nicht. Darüber hinaus funktionieren einige APIs, die in Windows PE vorhanden sind, nicht ordnungsgemäß und verhalten sich anders als in Windows. Diese APIs werden nicht unterstützt und dürfen nicht verwendet werden, da ihr Verhalten unter Windows PE nicht definiert ist.
Manchmal gibt es möglicherweise keine geeignete API, um eine bestimmte Aufgabe auszuführen. Um eine alternative Lösung zu finden, wäre eine andere Anwendungslogik, ein anderes Algorithmusdesign oder eine Neudefinition des zugrunde liegenden Problems erforderlich.