Je suis en difficulté avec un problème de déterminer l'emplacement du répertoire de fichiers de programme 64 bits sur Windows Vista 64 bits à partir d'une application 32 bits.
Appels vers J'aimerais éviter autant que possible de coder le trajet de «C: \ Program Files».
Faire quelque chose comme Comment une application 32 bits peut-elle bien obtenir correctement l'emplacement du dossier de Windows Vista 64 bits?
Notre application dispose d'un composant de service censé lancer d'autres processus en fonction des demandes de composant spécifique à la session d'utilisateur. Les applications lancées peuvent être 32 bits ou 64 bits. Nous faisons ceci via ShgetKnowDederDePath (folderid_programfileX64) Ne retourne rien. MSDN Article connuFolderid indique également que cet appel particulier avec folderid_programfileX64 n'est pas pris en charge pour une application 32 bits.
getwindowsdirectory () , extraire le lecteur de la valeur de retour et ajouter "\ Program Files" à ce poste n'est pas attrayant non plus.
fond
CreateProcessasUser () en passant dans un jeton du processus d'initiation de la session d'utilisateur. Pour appeler à CreateProcessasUser , nous créons un bloc d'environnement via le CreateenVironMollock () API. Le problème est que CreateenVironMollock () , à l'aide du jeton de l'application d'utilisateur-session, crée un bloc avec programw6432 = "C: \ Program Files (x86)", qui est un problème pour 64 bits applications. Nous devons le remplacer avec la valeur appropriée.
4 Réponses :
Si vous lisez cette page avec soin, vous verrez soigneusement que folderid_programfileX64 est pris en charge pour 32 bits applications sur un système d'exploitation 64 bits. Il n'est pas pris en charge sur un système d'exploitation 32 bits, ce qui a un sens complet.
La partie officielle de la page indique qu'il fonctionne sur le système d'exploitation 64 bits. Cependant, au bas de la page, il y a un commentaire (que je suppose est là car Microsoft ne l'a pas rejeté), affirmant que pour l'appelant 32 bits, la méthode réussit cependant ne renvoie rien. Et oui, je l'ai essayé à partir de l'appelant 32 bits et aucun chemin n'est renvoyé (code d'erreur 0x80070002). L'environnement variable% Programw6432% ne se développe pas non plus à partir d'une application 32 bits.
La table dans MSDN a été mise à jour pour dire qu'elle ne fonctionne pas pour un programme 32 bits en cours d'exécution sur un système d'exploitation 64BIT. Ils répondent en fait aux commentaires!
Comme vous l'avez mentionné, l'utilisation de ShgetknownFolderdPathe à partir d'une application 32 bits ne fonctionnera pas sur un système d'exploitation de 64 bits. En effet, l'émulation WOW64 est en vigueur.
Vous pouvez cependant utiliser REGOPENKEEX Passage Le drapeau L'emplacement dans le registre:
HKEY_LOCAL_MACHINE \ LOGICIEL \ Microsoft \ Windows \ CurrentVersion
Vous êtes intéressé par la valeur de la chaîne:
ProgrammesDir
key_wow64_644key puis lisez ensuite le répertoire de fichiers de programme du registre.
Merci pour votre réponse Brian, cela a travaillé. Apprécier ton aide
Merci, cela vous est utile pour les applications 32 bits telles que les fronts contrôlant un service pouvant fonctionner avec des fichiers, par exemple, ajoutez les fichiers de programme 64 bits en tant que cible de scanner à partir d'une interface utilisateur 32 bits.
Il existe également une variable d'environnement spéciale pour les fichiers de programme 64 bits - aucun besoin de lire directement dans le registre. Mais au moins je sais maintenant comment accéder au registre en dehors de wow6432node :)
folderid_programfileX64 est pris en charge ...
MSDN dit qu'il est pris en charge, mais le document "WOW64" de Microsoft "Le document Meilleures pratiques de Microsoft dit que ce n'est pas le cas. Voir http: // Télécharger .microsoft.com / Download / A / F / 7 / AF7777E5-7DCD-4800-8A0A-B18336565F5B / WOW64_BESTPRAC.DOCX
pour citer:
• Certaines variables ne fonctionnent que si le processus est 64 bits. Par exemple, folderid_programfileX64 ne fonctionne pas pour les appelants 32 bits. Dans les versions de Windows antérieures à Windows que Windows 7,% Programw6432% ne fonctionnait pas dans le contexte de processus 32 bits. Une application doit déterminer si elle fonctionne dans un processus 64 bits avant d'utiliser ces variables.
sous Windows 7 x64, exécutant une application 32 bits dans le débogueur Visual Studio, je reçois également un code de retour de 0x80070002 (et un pointeur Null). Exécuter le même code compilé sous 64 bits renvoie la valeur S_OK et le chemin est correctement rempli.
J'ai utilisé le piratage de registre comme indiqué ci-dessus car je ne trouve aucune autre solution de contournement.
Regarde ma réponse. Il n'est pas nécessaire de lire le registre 64 bits - il existe également une variable d'environnement appelée programw6432 disponible pour les processus 32 bits et 64 bits dans des fenêtres 64 bits. Utilisez-le pour obtenir le chemin de fichier de programme de 64 bits.
Vous pouvez également interroger la variable d'environnement programw6432 . Il n'existe évidemment que dans des fenêtres 64 bits, mais il doit renvoyer le répertoire de fichiers de programme de 64 bits, et il semble être défini pour les programmes de 64 bits et 32 bits. Au moins cela a fonctionné pour moi (c #, getenvironmentvariable ) ...
La variable programmew6432 est documentée sur MSDN: WOW64 Détails de la mise en œuvre .
Par curiosité .. pourquoi? Si vous êtes un programme de 32 bits fonctionnant sur 64 bit, vous ne devez pas avoir besoin de connaître l'emplacement du répertoire des fichiers de programme 64 bits, vous devez utiliser celui qui vous sera retourné qui serait quelque chose comme ceci: c: \ Program Files (X86)