Créer des applications pour Windows PE

La licence de Windows PE (WinPE) est accordée à des éditeurs de logiciels indépendants et à des fabricants d’ordinateurs OEM (Original Equipment Manufacturer) pour leur permettre de créer un déploiement personnalisé et des utilitaires de récupération. Cette rubrique fournit des recommandations aux éditeurs de logiciels indépendants et aux fabricants OEM pour leur permettre de développer des applications de déploiement et de récupération qui s’exécuteront dans Windows PE.

noteRemarque
Windows PE n’est pas un système d’exploitation à usage général. Il ne peut pas être utilisé pour un autre objectif que le déploiement et la récupération. Il ne doit pas être utilisé comme client léger ni système d’exploitation intégré. D’autres produits Microsoft®, tels que Windows Embedded CE, peuvent être utilisés à ces fins.

La majorité des applications Windows PE sont des applications à environnement fonctionnel fixe qui fournissent leur propre interface graphique utilisateur. L’application d’installation de Windows et l’environnement de récupération de Windows (Windows RE) en sont deux exemples.

  • Il est acceptable de montrer une invite de commandes, puis de modifier Startnet.cmd. Il s’agit de la méthode la plus pratique pour démarrer automatiquement une application. Voir WinPE : Monter et personnaliser.

  • Pour que votre application contourne la ligne de commande et démarre dans votre interface graphique utilisateur, utilisez Winpeshl.exe, Wpeinit.exe, wpeutil.exe et wpeutil.dll.

Par défaut, Winpeshl.exe est le premier processus exécuté lorsque Windows PE est démarré. Il est spécifié par la valeur de Registre ci-dessous, 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 contient des applications à lancer, ces applications sont exécutées à la place de Cmd.exe.

Wpeinit.exe installe les périphériques PnP (Plug-and-Play) en commençant par la pile réseau et en traitant les paramètres Unattend.xml lorsque Windows PE démarre. Pour plus d’informations, voir Wpeinit et Startnet.cmd : Utilisation de scripts de démarrage WinPE.

La gestion de réseau peut être démarrée à tout moment en exécutant Wpeinit.exe ou en l’autorisant à s’exécuter au démarrage de Windows PE, ou en exécutant la commande des Options de ligne de commande de Wpeutil.

Les applications d’environnement personnalisé peuvent appeler directement Wpeutil.dll avec les fonctions LoadLibrary et GetProcAddress. Pour obtenir des informations connexes, voir INFO : Alternatives à l’utilisation de GetProcAddress() avec LoadLibrary().

Chacune des fonctions exportées par Wpeutil.dll possède la même signature de fonction que la fonction WinMain, comme illustré dans l’exemple de code ci-dessous.

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

L’exemple de code ci-dessous montre comment initialiser la gestion de 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 Wpeutil.dll, voir Options de ligne de commande de Wpeutil.

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 génération de votre projet pour produire des applications et des DLL compatibles avec Windows PE, comme suit :

  1. Vous devez développer les applications Windows PE à l’aide de code C ou C++ natif qui n’utilise pas MFC ni ATL. Ainsi, si vous utilisez l’Assistant Projet Visual Studio, choisissez un projet Win32 et assurez-vous que MFC et ATL ne sont pas sélectionnés.

  2. Définissez les options du projet pour associer les bibliothèques Runtime C/C++ statiques et non pas la version .dll de Msvcrt.dll.

  3. Ouvrez les propriétés de votre projet et définissez Propriétés de configuration \ Bibliothèque Runtime C/C++ sur Multithread ou sur Débogage multithread, et non pas sur l’une des versions .dll. Si vous n’effectuez pas cette étape, votre application peut ne pas s’exécuter sur Windows PE.

  4. Si vous envisagez d’héberger votre application dans la version 64 bits de Windows PE, définissez les options de génération de projet pour compiler tous les binaires à l’aide du compilateur x64 dans Visual Studio.

  5. Si vous envisagez d’héberger votre application dans la version 32 bits de Windows PE, définissez les options de projet pour compiler à l’aide du compilateur x86.

  6. Assurez-vous que l’option de compilateur /clr: n’est pas définie pour votre projet. Cette option génère du code C++ managé, qui ne s’exécutera pas sur Windows PE.

WarningAvertissement
Votre application peut utiliser des fichiers .dll personnalisés que vous écrivez ou exploitez sous licence d’un tiers. Ajoutez ces fichiers .dll à votre application pour Windows PE. Toutefois, n’utilisez pas Msvcrt.dll et n’incluez pas des fichiers .dll Windows supplémentaires qui ne font pas partie de Windows PE.

Windows PE est un système d’exploitation léger de démarrage basé sur un sous-ensemble de composants issus du système d’exploitation Windows. Il a été conçu pour héberger des applications de déploiement et de récupération. Comme tel, il contient de nombreux binaires Windows requis pour héberger les API les plus importantes pour ces classes d’applications. En raison des contraintes de taille et d’autres contraintes de conception, certains binaires Windows ne figurent pas dans Windows PE et, par conséquent, certaines API Windows ne sont pas présentes ou utilisables.

Les API suivantes sont prises en charge dans Windows PE :

  1. Jeux d’API Windows (Mincore.lib).

  2. API DISM (Dismapi.lib).

  3. API Imaging pour Windows (Wimgapi.lib).

Si une API se comporte de la même façon que dans 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 sera considérée comme prise en charge et pourra être utilisée par les applications, sauf mention contraire. Comme Windows PE est basé sur des composants issus de Windows, il contient un sous-ensemble significatif 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 les mêmes ou quasiment les mêmes que dans le système d’exploitation Windows complet, à moins qu’ils soient 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 possibles des paramètres 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’incapacité d’accéder à un état persistant ou d’autres limitations de conception. Dans ce cas, l’API peut ne pas être prise en charge tout en étant encore utilisée pour accomplir une tâche spécifique en l’absence de solution alternative.

En règle générale, si une API fonctionne de façon incorrecte 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 binaire inclus dans Windows PE. L’API peut provoquer des échecs du fait 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. De tels échecs ne sont pas considérés comme des bogues dans Windows PE.

Comme de nombreux composants Windows ne sont pas présents dans Windows PE, un grand nombre d’API ne sont pas disponibles. Elles peuvent être totalement absentes si le binaire Windows dans lequel elles résident n’est pas présent. Il est possible également qu’elles soient seulement partiellement présentes si le binaire Windows dans lequel elles résident est présent, mais qu’un ou plusieurs binaires dont elles dépendent ne sont pas présents. En outre, certaines API qui sont présentes dans Windows PE ne fonctionnent pas correctement et se comportent autrement que dans Windows. Ces API ne sont pas prises en charge et ne doivent pas être utilisées, car leur comportement dans Windows PE est non défini.

Parfois, il peut n’y avoir aucune API appropriée pour accomplir une tâche spécifique. Pour trouver une solution alternative, vous pouvez avoir besoin d’une autre logique d’application, d’une conception d’algorithme différente ou d’une redéfinition du problème sous-jacent.

Voir aussi

Afficher:
© 2015 Microsoft