WinPE : Créer des applications
Windows PE (WinPE) est concédé sous licence aux fabricants d’équipement d’origine (OEM) pour créer des utilitaires de déploiement et de récupération personnalisés. Cette rubrique fournit des instructions pour les oem pour développer des applications de déploiement et de récupération qui s’exécutent dans Windows PE.
Note Windows PE n’est pas un système d’exploitation à usage général. Il ne peut pas être utilisé à d’autres fins que le déploiement et la récupération. Il ne doit pas être utilisé comme client léger ou système d’exploitation incorporé.
Extensibilité
La majorité des applications Windows PE sont des applications d’interpréteur de commandes à fonction fixe qui fournissent leur propre interface graphique graphique. L’application d’installation de Windows et l’environnement de récupération Windows (Windows RE) en sont deux exemples.
S’il est acceptable d’afficher une invite de commandes, modifiez Startnet.cmd : il s’agit du moyen le plus pratique de démarrer automatiquement une application. Consultez WinPE : Monter et personnaliser.
Pour que votre application contourne la ligne de commande et démarre dans votre interface graphique graphique, utilisez Winpeshl.exe, Wpeinit.exe, wpeutil.exe et wpeutil.dll.
Winpeshl.exe, Wpeinit.exe, wpeutil.exe et wpeutil.dll
Par défaut, Winpeshl.exe est la première exécution du processus lors du démarrage de Windows PE. Cette valeur est spécifiée par la valeur de Registre suivante de type REG_SZ.
HKEY_LOCAL_MACHINE
System
Setup
CmdLine
Winpeshl.exe recherche un fichier appelé Winpeshl.ini. Si le fichier n’existe pas, Winpeshl.exe démarre un processus Cmd.exe qui exécute le script Startnet.cmd. Si Winpeshl.ini existe et qu’il contient des applications à lancer, ces applications sont exécutées au lieu de Cmd.exe.
Wpeinit.exe installe les appareils Plug-and-Play (PnP), démarre la pile réseau et traite les paramètres de Unattend.xml au démarrage de Windows PE. Pour plus d’informations, consultez WPEInit et Startnet.cmd : utilisation de scripts de démarrage WinPE.
La mise en réseau peut être démarrée à tout moment en exécutant soit en autorisant Wpeinit.exe à s’exécuter au démarrage de Windows PE, soit en exécutant la commande Wpeutil Command-Line Options .
Les applications shell personnalisées peuvent appeler directement dans Wpeutil.dll avec les fonctions LoadLibrary et GetProcAddress .
Chacune des fonctions exportées par Wpeutil.dll a la même signature de fonction que la fonction WinMain, comme illustré dans l’exemple de code suivant.
int InitializeNetworkingW(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
L’exemple de code suivant montre comment initialiser la mise en réseau.
#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;}
Pour obtenir la liste complète des exportations de Wpeutil.dll, consultez Options de Command-Line Wpeutil.
Paramètres du projet Visual Studio
Certains paramètres de projet Visual Studio de base peuvent être différents des paramètres par défaut créés par l’Assistant Projet Visual Studio. Veillez à configurer les paramètres de build de votre projet pour produire des applications et des DLL compatibles avec Windows PE, comme suit :
Vous devez développer des applications Windows PE avec du code C ou C++ natif qui n’utilise pas MFC ou ATL. Par conséquent, si vous utilisez l’Assistant Projet Visual Studio, choisissez un projet Win32 et assurez-vous que ni MFC ni ATL ne sont vérifiés.
Définissez les options de votre projet pour créer un lien vers les bibliothèques runtime C/C++ statiques, et non vers la version .dll de Msvcrt.dll.
Ouvrez les propriétés de votre projet et définissez Propriétés de configuration \ Bibliothèque d’exécution C/C++ sur Multi-threaded ou Multi-threaded de débogage, et non sur l’une des versions .dll. Si vous n’effectuez pas cette étape, votre application risque de ne pas s’exécuter sur Windows PE.
Si vous envisagez d’héberger votre application sur la version 64 bits de Windows PE, définissez les options de génération de projet pour compiler tous les fichiers binaires avec le compilateur x64 dans Visual Studio.
Si vous envisagez d’héberger votre application sur la version 32 bits de Windows PE, définissez les options de projet à compiler avec le compilateur x86.
Vérifiez que l’option du compilateur /clr: n’est pas définie dans votre projet. Cette option produit du code C++ managé, qui ne s’exécute pas sur Windows PE.
Avertissement Votre application peut utiliser des fichiers de .dll personnalisés que vous écrivez ou que vous pouvez utiliser sous licence auprès d’un tiers. Ajoutez ces fichiers .dll à votre application pour Windows PE. Toutefois, n’utilisez pas Msvcrt.dll et n’incluez pas de fichiers windows .dll supplémentaires qui ne font pas partie de Windows PE.
Informations de référence sur la compatibilité des API
Windows PE est un système d’exploitation d’amorçage léger basé sur un sous-ensemble de composants du système d’exploitation Windows. Il est conçu pour héberger des applications de déploiement et de récupération. En tant que tel, il contient de nombreux fichiers binaires Windows nécessaires pour héberger les API les plus importantes pour ces classes d’application. En raison de la taille et d’autres contraintes de conception, tous les fichiers binaires Windows ne sont pas présents dans Windows PE, et par conséquent, toutes les API Windows ne sont pas présentes ou utilisables.
API prises en charge dans Windows PE
Les API suivantes sont prises en charge dans Windows PE :
Si une API se comporte de la même façon que sur le système d’exploitation Windows complet et comme indiqué dans le Kit de développement logiciel (SDK) Windows pour le système d’exploitation Windows, elle est considérée comme prise en charge et peut être utilisée par les applications, sauf indication contraire. Étant donné que Windows PE est basé sur des composants de Windows, il contient un sous-ensemble important d’API Windows qui sont publiées dans le Kit de développement logiciel (SDK) Windows pour le système d’exploitation Windows. Les paramètres, les conventions d’appel et les comportements de ces API prises en charge seront identiques ou presque identiques à ceux du système d’exploitation Windows complet, sauf s’ils sont affectés par l’environnement Windows PE unique. Les applications utilisant uniquement ces API doivent être portables entre le système d’exploitation Windows complet et Windows PE.
Dans certains cas, un sous-ensemble des valeurs de paramètres possibles sera utilisable sur Windows PE. Cela peut être dû à des conditions propres à l’environnement d’exécution, telles que l’exécution sur un support en lecture seule, l’accès à l’état persistant ou d’autres limitations de conception. Dans ce cas, l’API peut ne pas être prise en charge, mais peut toujours être utilisée pour accomplir une tâche spécifique s’il n’existe aucune autre alternative.
En général, si une API fonctionne incorrectement ou pas du tout sur Windows PE, elle n’est pas prise en charge et ne doit pas être utilisée, même si elle réside dans un fichier binaire inclus dans Windows PE. L’API peut échouer parce que Windows PE est un sous-ensemble du système d’exploitation Windows, ou en raison des considérations de conception du runtime propres à Windows PE. Ces échecs ne sont pas considérés comme des bogues dans Windows PE.
Étant donné que de nombreux composants Windows ne sont pas présents dans Windows PE, de nombreuses API ne sont pas disponibles. Ils peuvent être complètement manquants, car le binaire Windows dans lequel ils résident n’est pas présent. Ils peuvent également être partiellement présents, car bien que le binaire Windows dans lequel ils résident soit présent, un ou plusieurs binaires dont ils dépendent ne le sont pas. En outre, certaines API présentes dans Windows PE ne fonctionnent pas correctement et se comportent différemment de celles de Windows. Ces API ne sont pas prises en charge et ne doivent pas être utilisées, car leur comportement sur Windows PE n’est pas défini.
Parfois, il n’existe pas d’API appropriée pour accomplir une tâche spécifique. Pour trouver une autre solution, vous avez besoin d’une logique d’application différente, d’une conception d’algorithme différente ou d’une redéfinition du problème sous-jacent.