Affaires de Bureau
Extension de Windows PE
Wes Miller
Avant même la sortie de Windows PE il y a plus de cinq ans, les clients impatients réclamaient déjà davantage de fonctions. Malheureusement, Windows PE n'a pas été conçu pour être facilement étendu de la même façon que, disons, Windows XP, en ajoutant des couches supplémentaires du système d'exploitation. Bien sûr, Windows PE se devait d'offrir une prise en charge
Win32® rudimentaire (pour permettre le fonctionnement de la plupart des applications Windows®) et une prise en charge de réseau et de stockage de masse (pour communiquer sur le réseau et pouvoir installer Windows). Cependant, dès le début, le shell était un élément que nous souhaitions limiter. En utilisant cmd.exe à la place du shell Windows Explorer traditionnel, nous avons limité ce que l'environnement de Windows PE pouvait faire et, surtout, nous avons fait en sorte que l'environnement par défaut soit facilement scriptable pour toutes les tâches d'automatisation.
Cela ne signifie pas que vous ne pouvez pas étendre Windows PE ; vous devez juste vous rappeler qu'il est limité. Vous pouvez vous attendre à ce que votre application ne fonctionne pas ou à ce que son comportement soit incorrect si elle requiert une des technologies répertoriées à la figure 1 (cette liste n'est pas exhaustive).
Figure 1 API Windows manquantes
| .NET Framework (toutes versions) |
| Interfaces ADSI (Active Directory® Services Interfaces) |
| DirectX® |
| Microsoft Data Access Components (MDAC) |
| Jet (Access) |
| Visual Basic® (y compris les versions pré-.NET) |
| Tout type d'exécutable nécessitant une infrastructure qui n'est pas installée avec Windows en mode natif. |
| Windows Explorer ou Internet Explorer |
| Windows Media® Player |
| SAPI, MAPI, TAPI (API Windows Speech, Mail et Téléphonie, respectivement) |
Si vous ne savez pas de quoi votre application dépend, vous devez le découvrir. Mais comment ? Lorsque nous avons essayé de faire marcher ADO, des applications HTML (HTA) et des composants Windows Script Host (WSH) sous Windows PE avant sa sortie, nous avons été confrontés au même problème. Toutefois, vous devez être conscient que bien que cet article expose des façons de rechercher ces dépendances, l'ajout de fichiers binaires Windows à votre image Windows PE au delà de ce que la commande MKIMG inclut n'est pas couvert par le contrat de licence utilisateur final (CLUF). Il vous faudra acquérir un complément de licence auprès de Microsoft afin d'implémenter des modifications de cette nature dans votre environnement.
Comprendre les dépendances
Si vous ouvrez le fichier .inf d'une application dans le Bloc-notes et que vous l'examinez soigneusement, vous pouvez en apprendre beaucoup. En fait, c'est souvent la façon la plus facile de comprendre une application et de voir quelles sont ses dépendances. La chose importante à retenir au sujet de Windows PE est le fait que l'application est généralement si dépouillée que vous devrez déboguer plusieurs niveaux de dépendances : les dépendances directes propres de votre application et les dépendances que celles-ci peuvent amener, afin d'assurer un fonctionnement fiable de votre application. En gros, une cascade assez grande de dépendances peut survenir si vous ne faites pas attention. Avec quelques ajouts de composants accidentels (ou voulus), votre image peut grandir considérablement en taille et en complexité.
Si vous disposez d'un fichier .inf qui décrit l'application, vous pouvez obtenir des indices sur les dépendances en recherchant les clés de registre et les fichiers ajoutés à votre système par le fichier .inf. Recherchez les sections CopyFiles et AddReg. Ces entrées pointeront vers des applications, des fichiers DLL et d'autres fichiers dont dépend votre application. Parmi les trois compléments conçus pour Windows PE (ADO, HTA, et WSH), WSH fut le plus simple à créer. Étant donné qu'une version redistribuable de WSH était encore disponible pour des versions plus anciennes de Windows et qu'il existe actuellement un fichier .inf intégré dans Windows qui exécute les associations de fichiers pour WSH (dans %windir%\inf\wsh.inf), son installation dans Windows PE fut relativement facile.
Orca et prise d'instantanés
Si l'application en question est distribuée en tant que fichier Microsoft® Installer (MSI), vous pouvez faire deux choses pour trouver les dépendances. Si vous êtes un spécialiste de MSI, vous pouvez utiliser Orca (un outil d'édition des fichiers Windows Installer distribué dans le cadre du kit de développement logiciel Windows Server® 2003 R2 platform : Rendez-vous sur la page go.microsoft.com/fwlink/?LinkId=77941) pour l'afficher. Vous pouvez également installer le MSI pour les composants de votre choix, en réalisant une analyse avant/après des fichiers et de clés de registre qui ont été modifiés. Vous pouvez vider le registre, installer l'application, exporter à nouveau le registre, puis exécuter WinDiff dessus (voir l'encadré « Utilisation de WinDiff »). Le résultat peut ensuite être utilisé comme modèle pour les modifications qui doivent être apportées au registre. Le problème est que le nombre de modifications peut être assommant. Néanmoins, ce peut être la meilleure option si vous n'avez pas de fichier .inf (ou l'auteur de l'application) à votre disposition.
Vous connaissez peut-être le processus de prise d'instantanés d'applications. En gros, il s'agit de la même analyse avant/après que celle réalisée pour faire fonctionner votre application. Auparavant, Microsoft distribuait (avec Windows 2000) un outil qui faisait la même chose, mais cet outil n'est pas compatible avec les versions plus récentes de Windows. Un certain nombre d'applications commerciales (rassembleurs d'installations) peuvent s'en charger, mais certains utilitaires gratuits aussi. Comme solution, vous pouvez installer le kit de développement logiciel de plate-forme (voir le lien dans le paragraphe précédent), qui inclut WinDiff. Notez que pour réaliser la comparaison avec WinDiff, il est préférable d'installer l'application sur Windows Server 2003 Service Pack 1 (SP1) parce qu'il s'agit de la version de Windows PE que vous êtes censé utiliser : Windows PE 1.6 généré à partir de Standard Edition ou Enterprise Edition (avec SP1). En réalisant cette tâche sur Windows Server 2003, vous disposerez de l'environnement le plus proche de ce que vous obtiendriez sur Windows PE (où évidemment vous ne pouvez pas exécuter un MSI). Suivez les étapes de l'encadré « Utilisation de WinDiff ».
Vous trouverez ainsi un bon nombre des informations modifiées. Malheureusement, il n'existe pas de méthode facile pour exporter les informations modifiées des captures de registre ou de fichiers afin de créer un manifeste pour installer votre application. Vous devez incorporer les modifications manuellement. C'est là que nous avons rencontré certains de nos plus gros problèmes avec la première version de Windows PE. Le simple fait de parvenir à faire fonctionner les composants HTA relevait de la gageure puisqu'il n'y avait pas de définition pour eux (en dehors d'Internet Explorer®) au sein de Microsoft. En utilisant la différenciation, nous avons pu confectionner une prise en charge HTA suffisante pour que ça fonctionne. Vous pouvez ajouter manuellement ces clés dans le registre Windows PE, mais vous souhaiterez peut-être ajouter les clés une fois que Windows PE aura démarré. Vous pouvez regarder les fichiers OC.bat et OC2.bat utilisés pour installer la prise en charge HTA, WSH et/ou ADO dans Windows PE à l'aide du script buildoptionalcomponents.vbs inclus dans les outils de génération de Windows PE.
Outils utiles
Même après avoir isolé les dépendances directes, il est souvent difficile de trouver tous les fichiers binaires dont dépend votre application. Vous ne saurez pas, par exemple, si elle nécessite un autre fichier DLL ou OCX pour réaliser certaines tâches. Alors, comment savoir ? Mark Russinovich, rendu célèbre par Sysinternals (à présent Technical Fellow chez Microsoft), a conçu un utilitaire pratique appelé listdlls qui s'en charge. Vous pouvez télécharger listdlls à l'adresse microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. Pour utiliser l'utilitaire, exécutez la commande listdlls.exe > dlls.txt et examinez ensuite le résultat. La figure 2 présente le résultat de listdlls exécuté sur lui-même. Vous pouvez comparer cette liste aux fichiers DLL et OCX inclus dans Windows PE pour déterminer si toutes les dépendances de votre application sont en place ou non (dans le cas de listdlls, elles sont déjà présentes). Pour la prise en charge HTA dans Windows PE, listdlls était essentiel pour l'identification de certaines dépendances qui ne pouvaient pas être identifiées autrement.
.gif)
Figure 2 Résultat de listdlls exécuté sur lui-même (Cliquer sur l'image pour l'agrandir)
Mais ce n'est pas parce qu'une DLL est répertoriée que l'application en a forcément besoin pour fonctionner. Si vous chargez le Bloc-notes, par exemple, vous verrez qu'il charge uxtheme.dll. Sous Windows PE, cette DLL n'est pas disponible et, en fait, puisque les thèmes Windows ne sont pas utilisés, elle ne sera jamais chargée. Il est très difficile de distinguer les DLL répertoriées par listdlls qui vous sont utiles de celles qui sont chargées sur demande par Windows. Malheureusement, seule une expérimentation empirique ou une connaissance très poussée des aspects les plus précis de Windows vous y aideront (à cette fin, je recommande le livre de Mark Russinovich et David Salomon, Microsoft Windows Internals, Fourth Edition (Microsoft Press®,2004).
En fait, Mark inclut également la même fonctionnalité dans le remplacement de Process Explorer pour le gestionnaire des tâches de Windows, disponible gratuitement. La différence est que listdlls crée un résultat qui, à mon avis, est plus facilement converti en script et utilisé pour la recherche et le rassemblement de dépendances manquantes.
Notez que même après avoir ajouté une DLL à votre image, vous risquez d'être encore loin d'en avoir terminé. En effet, il existe deux types de DLL : celles qui doivent être enregistrées et celles qui ne doivent pas l'être. Malheureusement, il n'est pas facile de les distinguer, à moins d'essayer de les enregistrer toutes. Pour enregistrer une DLL (ou un OCX), exécutez regsvr32 dllname.dll. Si cela fonctionne correctement, une boîte de dialogue vous avertit que la DLL a été enregistrée. Sinon, vous ne recevez pas de message ou, plus probablement, une boîte de dialogue vous informera soit que l'enregistrement de la DLL a échoué, soit qu'il n'a pas pu se faire. Au cours du développement des composants facultatifs HTA et ADO pour Windows PE, nous avons découvert que les DLL requièrent un stockage réinscriptible lors de leur enregistrement, soit pour écrire temporairement un fichier .inf pour l'installation, soit pour enregistrer une autre dépendance (disons un répertoire spécifique dont elles ont besoin). Dans Windows PE, cela était synonyme d'échec. Heureusement, avec Windows PE 2.0, les tâches de ce type fonctionnent puisqu'il y a de l'espace disponible par défaut.
Process Monitor est un troisième outil créé par Mark et publié récemment. Process Monitor peut être considéré comme un sur-ensemble de Regmon et Filemon, qui fournit cependant beaucoup plus de détails tout en ajoutant une toute nouvelle couche de communication interprocessus. Cet outil incroyablement puissant peut vous aider à résoudre des problèmes d'applications dans Windows et à répondre à des questions sur les interdépendances des DLL. Process Monitor peut être
téléchargé.
Suppression de fichiers Windows PE
Outre la possibilité d'ajouter des éléments à Windows PE, l'une des demandes les plus fréquentes concernait la réduction de la taille de réduire Windows PE. Vous pouvez prendre certaines mesures pour réduire quelque peu la taille de Windows PE. Votre copie sous licence de Windows PE comprend normalement un ensemble d'outils de génération et de la documentation. L'un des documents est un fichier d'aide appelé winpe.chm. Si vous ouvrez ce fichier et que vous explorez la section Guide de l'utilisateur de l'Environnement de préinstallation Windows, vous devriez voir une rubrique intitulée Reducing the Size of Windows PE (Réduction de la taille de Windows PE). Cette section répertorie un ensemble de fichiers que vous pouvez supprimer en toute sécurité (si vous n'en avez pas besoin). Vous trouverez trois sections concernant les fichiers supprimables :
- Les fichiers de police peuvent toujours être supprimés.
- Les fichiers .inf concernant la mise en réseau et les utilitaires peuvent être supprimés, mais ne le faites que si vous n'avez absolument pas l'intention d'utiliser votre version sur le réseau.
- Les utilitaires de ligne de commande ne doivent pas être supprimés. Je vous déconseille d'en supprimer à moins que vous ne sachiez exactement à quoi ils servent et ce qui risque de se passer si vous les supprimez.
Après avoir déterminé quels sont les fichiers que vous pouvez exclure en toute sécurité, vous pouvez tout simplement écrire un fichier batch ou un autre script et les supprimer de votre version de Windows PE une fois que mkimg.cmd a terminé la mise en œuvre.
Modification du Registre Windows PE
Vous pouvez constater que nous avons fait le choix conscient de ne pas installer les composants facultatifs au moment de la mise en œuvre. Bien que ceci prenne un peu plus de temps au moment de l'exécution, cela signifie également que nous n'avons pas dû concevoir un moyen entièrement nouveau de replacer ces composants dans Windows PE, ce que nous n'avions pas le temps de faire et qui serait sans doute revenu à les omettre complètement. Mais que faire si vous souhaitez effectuer une modification du Registre, par exemple ajouter un delta de modification du Registre pour votre application, ou si vous voulez simplement modifier une clé qui pourrait empêcher le fonctionnement de l'application ? C'est en fait très simple grâce à regedit, comme illustré à la
figure 3. Procédez de la façon suivante :
- Exécutez regedit et sélectionnez la ruche HKEY_LOCAL_MACHINE.
- Sélectionnez Fichier | Chargement de la ruche, puis accédez à l'emplacement de votre version de Windows PE. Sélectionnez setupreg.hiv sous I386\System32\ (ou MiniNT\System32, si c'est une image que vous mettez sur un disque dur).
- Entrez un nom temporaire pour la ruche, tel que WinPE, et accédez à ce nœud sous HKLM.
- Apportez les modifications nécessaires à cette clé. Il est intéressant de noter que ce nœud correspond effectivement au nœud HKLM\System que l'on trouverait sur une installation Windows normale.
- Une fois vos modifications réalisées, sélectionnez la clé que vous avez créée sous HKLM à l'étape 3 (il est très important de ne pas se tromper ici car vous pourriez endommager votre système).
- Sélectionnez Fichier | Décharger la ruche... et confirmez dans la boîte de dialogue Oui | Non. Veillez à démonter le registre à chaque fois car son verrouillage empêcherait une mise en œuvre réussie de Windows PE.
.gif)
Figure 3 Ouverture du Registre Windows PE (Cliquer sur l'image pour l'agrandir)
En suivant ces étapes, vous pouvez modifier HKLM\System. Il existe également deux autres clés situées sous I386\System32 qui vous permettent de modifier d'autres zones du registre : DEFAULT est la ruche par défaut pour les utilisateurs (même SYSTEM, que vous exécutez en utilisant Windows PE) et SOFTWARE, qui est identique à HKLM\Software. Comme toujours, modifiez le registre avec précaution et seulement en cas de besoin.
Fort de ces informations, vous devriez pouvoir essayer de déplacer votre outil de dépannage ou de récupération préféré sur Windows PE. Le mois prochain, j'aborderai la suite PSTools, un ensemble d'outils de gestion système très utiles également écrit par Mark Russinovich.
Wes Miller est responsable du développement chez Pluck (www.pluck.com) à Austin, au Texas. Auparavant, Wes a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l'adresse suivante : technet@getwired.com.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.