Bonjour,
 
Je poste dans API Win32, c'est ce qui me semble le plus proche ...
 
Alors voilà, je tente de rendre mon application compatible avec le système de redirections de Windows7 64bits (Wow64).
 
J'utilise Wow64DisableWow64FsRedirection et Wow64RevertWow64FsRedirection pour encadrer l'appel à ShellExecuteEx qui lance des applications ou ouvre des répertoires.
 
Et justement, je n'ai pas eu de soucis avec les fichiers, qu'ils soient ou pas "redirigés" (qu'ils soient dans "Programmes" ou dans "Program Files (x86)" par exemple), mais pour les répertoires ça ne marche pas.
 
Parfois le répertoire est bien ouvert, mais la plupart du temps j'ai un "La procédure spécifiée est introuvable".
 
Pour tester, j'ai mis l'appel à ShellExecuteEx (entre les redirections) au début de mon code, juste après le "OleInitialize", et le plantage est systématique.  
 
Si je fais l'appel à ShellExecuteEx en dehors des redirections ça marche, mais plus pour les fichiers qui nécessitent une redirections (comme VPCWizzard par exemple).
 
Enfin, le plus curieux à mon sens: une fois qu'un ShellExecuteEx a fonctionné (par exemple en dehors des redirections), alors tous les appels suivants fonctionneront même s'ils sont entre les redirections. Par contre, si je commence par un appel qui provoque l'erreur, alors les appels à d'autres fonctions SHxxx (comme SHDoDragDrop) provoqueront la même erreur. Ce qui semble indiquer que quelque chose d'interne à planté (COM ?). Par contre les appels à ShellExecuteEx sur des fichiers (avec ou sans redirection) continuent à fonctionner.
 
 Voilà j'espère que quelqu'un aura une piste, ça fait des jours que je tourne ça dans tous les sens et que je ne trouve rien.
 
 Merci
 
 
 

La ligne suivante n'aurait-elle pas été oubliée ?

Voir doc http://msdn.microsoft.com/en-us/li [...] S.85).aspx

D'après la doc de OleInitialize, il appelle en interne CoInitializeEx, donc je me suis dit que ça suffisait ... et OleInitialize ne prend pas de paramètre donc peut-être que quelque chose manque ?

Bon j'ai un OleInitialize au début du programme et un uninit à la fin.
 
J'ai sorti l'appel à ShellExecute dans un nouveau thread, sans faire aucun appel à OleInitialize ou CoInitializeEx, et là ça à l'air de marcher (ceci dit c'est assez aléatoire donc c'est pas gagné).
 
J'aime pas trop les solutions qui sont pile le contraire de ce que MS dit de faire ...

Donc tu as une application 32 bit sur un système 64 bit et tu veux accéder aux dossiers/fichiers systèmes 64 bits?
Comment utilises-tu shellexecuteex? Précises tu le nom du fichier executable ou juste le nom du fichier?
La redirection Wow64DisableWow64FsRedirection ne marche que pour le thread en cours(dixit la doc), cela pourrait signifier que si ton programme 32 bit lance un autre programme 32 bit , la redirection ne fonctionnera pas pour ce dernier? et donc que même si tu précise correctement le bon nom de fichier/dossier en paramètre(donc dans ton programme appelant), ce dernier sera quand même changé dans le programme changé?
 
la: http://stackoverflow.com/questions [...] n-win7-x64 il parle aussi de creer le nouveau programme avec useShellExecute a true c'est du c# mais je sais pas l'equivalent en c (peut etre SEE_MASK_NOASYNC ?)

Exemple concret:
C:\Windows\System32\VPCWizard.exe
 
Si je le lance sans désactiver la redirection, il trouvera pas le programme, avec il le lance normal.
 
J'appelle ShellExecuteEx avec le nom de fichier complet.
Je fais systématiquement un appel à Wow64DisableWow64FsRedirection avant le ShellExecuteEx, et le revert après.
 
Le truc c'est que je récupère les chemins comme Windows me les donne via drag and drop (que ce soit des raccourcis ou des fichiers normaux), et que donc j'obtiens des chemins qui peuvent être ... euh "virtuels", impossible de savoir si y a ou pas besoin de désactiver la redirection. En la désactivant, ça marche à tous les coups pour les fichiers.

Et le programme qui ouvre ces fichier il est 32 ou 64 bit?
(si tu ouvres un fichier txt par exemple, tu passes uniquement le chemin complet du fichier avec le verbe "open", et c'est quelle version de notpad qui s'ouvre la 32 ou la 64?

Mon programme est en 32 bits.
 
Edit: Mais je pense que le problème inverse se produirait s'il était en 64 (?)

C'est pas ce que je te demande:
quand ton programme recoit un fichier .txt via drag & drop, tu fais un shellexecute dessus? C'est bien le notepad qui s'ouvre? Est ce que c'est la version 32 bit ou la version 64 bit du notepad qui s'ouvre? (on peut manuellement ouvrir le 32 ou le 64 bit)
Par contre j'ai pas reussi à ouvrir (manuellement) un explorer 32 bit (il doit se connecter a l'explorer deja ouvert je pense), donc cela peut affecter les dossiers a ouvrir?

Ah ok, en fait je fais pas de drag and drop de txt pour ouvrir notepad.
 
Je fais des drag and drop de raccourcis vers n'importe quoi comme application dans mon truc, et je lance l'application associée au raccourci.
 
Donc dans le cas de C:\Windows\System32\VPCWizard.exe, le fichier ne sera pas ouvert sans désactiver la redirection.
 
Dans le cas de "C:\Program Files" si je désactive ça ouvrira "C:\Program Files (x86)", donc je ne dois pas la désactiver.
 
Pour tout dire, je n'ai pas de problème avec le fonctionnement normal de Wow64xxx, mon programme fait ce qu'il est censé faire dans le cas général.
 
Le soucis est que quand j'utilise les Wow64xxx, il semble que quelque chose quelque part se passe, et qu'un ShellExec avec comme lpFile un répertoire (et pas un fichier) échoue avec le code d'erreur "access denied". Même si je n'utilise pas wow64xxx pour l'ouverture du dossier, s'il a été appelé précédemment dans l'application, alors ça provoque l'erreur desfois.
 
Ceci dit, j'ai trouvé un contournement qui semble fonctionner: j'appelle ShellExec avec "explorer" dans le lpFile et mon dossier en paramètre, et pour le moment ça fonctionne à chaque fois.