Attention aux miroirs brisés

points d’entrée et un thunking (principalement pour Itanium) et, le plus important, intercepte certaines opérations de Registre et de système de fichiers.

L’émulateur WOW64 expose également aux applications 32 bits des variables d’environnement différentes de celles vues par les applications 64 bits. Par conséquent, les applications 32 bits voient la variable d’environnement Program Files en tant que ProgramFiles(x86). Si vous écrivez du code tel que MsgBox(Environ("ProgramFiles")), vous obtenez par défaut "C:\Program Files" en 64 bits et "C:\Program Files
(x86)" en 32 bits.

L’émulateur procède de manière similaire avec le Registre et les dossiers system. Pour des raisons de compatibilité et de performances, le dossier %windir%\System32 est en réalité le dossier 64 bits. Autrement dit, les applications 64 bits n’ont pas d’interception d’émulation. Le dossier redirigé pour les opérations 32 bits est nommé par défaut %windir%\ SysWOW64. Le nom SysWOW64 indique qu’il est employé par l’émulateur 32 bits. Tout cela peut sembler un peu déroutant.

Sous WOW64, le Registre associe la redirection et la réflexion. La redirection réside au niveau des clés telles que HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. Au moins, le schéma de nommage dans le Registre est un peu amélioré. La réflexion fait en sorte que les processus 32 bits et 64 bits puissent modifier des clés communes telles que les associations de fichiers. En revanche, la redirection vise à garantir une isolation appropriée entre le 32 bits et le 64 bits.

L’aspect fondamental est que l’implémentation ne devrait pas être un problème pour vous, à moins que vous essayiez d’obtenir des détails pour une application 32 bits à partir d’une application 64 bits ou inversement. En général, il est nettement plus simple de compiler vers la même cible. Par exemple, si vous souhaitez utiliser VS, compilez votre application en ciblant x86, et vous ne devrez pas vous soucier de l’émulation des fichiers ou du Registre. Si vous exécutez votre application en définissant « Any CPU », alors selon son mode de lancement, vous devrez peut-être employer la redirection et des appels d’API tels que GetSystemWow64Directory, et utiliser l’API RegOpenKeyEx pour le Registre, y compris le masque d’accès KEY_WOW64_ 32KEY. Cela peut être épineux et complique les tests. Il est nettement préférable de compiler vers la même plate-forme que l’application et les informations ciblées.

J’ai rencontré une difficulté lors d’une association de la réflexion de Registre et de la fonction de contrôle des accès utilisateur (UAC) de Windows Vista. Alors que j’ouvrais une clé dans la ruche HKLM pour des permissions d’écriture et que l’API s’exécutait correctement, j’ai eu un échec lorsque j’ai essayé d’écrire sur la clé. Mon application s’exécutait en 32 bits sur un système Windows 64 et la clé en question était donc réfléchie. J’ai perdu beaucoup de temps à essayer de trouver la cause du problème car l’API du Registre ne se comportait pas de la manière habituelle. Au final, j’ai réussi à la faire fonctionner correctement en incluant un manifeste avec mon application. Bien que resquestedExecutionLevel ait été défini comme asInvoker, cela a suffi pour éliminer ce bug étrange.

L’UAC fournit la virtualisation de Registre et je pense que l’association de la redirection ou de la réflexion WOW64 et de la virtualisation UAC a poussé le bouchon trop loin. Désormais, je vérifie systématiquement que j’ai un manifeste sur mon application. Dans VS 2008, vous pouvez accéder au manifeste à partir de l’onglet Application dans la boîte de dialogue Project Properties. N’oubliez pas d’inclure une option requestedExecutionLevel.