Encore un Pb entre PBx86 et PBx64

Sujets variés concernant le développement en PureBasic
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Bonjour à tous.

Je viens une nouvelle fois faire appel à vous.
Je suis en train d’analyser le répertoire C:\windows\system32 de WINDOW10 qui détient des perles à la fois puissantes mais aussi très sensibles.
Et je me suis heurté au pb suivant.
Je peux lister les prg *.exe du répertoire system32 de plusieurs façons mais je me suis aperçu que les résultats dépendaient aussi du compilateur x86 ou x64.
Voici les éléments.
Tout d’abord en utilisant PB x86 et x64

Code : Tout sélectionner

Repertoire$ = "c:\windows\system32\"
  If ExamineDirectory(0, Repertoire$, "net*.exe")  
    While NextDirectoryEntry(0)
      Debug  DirectoryEntryName(0) 
    Wend
    FinishDirectory(0)
  EndIf
;   prg=RunProgram("d:\dirtot.bat")

; dirtot.bat   ;;; en D:
; echo on
; C:
; cd \windows\system32\
; dir *.exe /B > D:\fichtot.txt
; copy D:\fichtot0.txt D:\fichtot1.txt
; COPY D:\fichtot.txt D:\fichtot0.txt
J’ai volontairement limité les commandes aux cmd net*.exe mais vous pouvez l’étendre au répertoire complet.
La différence obtenue entre PBx86 et PBx64 avec net*.exe et de 8 cmd en x86 et de 11 cmd en x64.
Il manque 3 cmd en PBx86
Les résultats en x64 sont bons et identiques à ce que l’on obtient en MSDOS.

Obtenez-vous les mêmes résultats que moi
En PBx86
net.exe
net1.exe
netbtugc.exe
NetCfgNotifyObjectHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE[
Et résultats en PBx64
net.exe
net1.exe
netbtugc.exe
netcfg.exe
NetCfgNotifyObjectHost.exe
NetEvtFwdr.exe
NetHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE
Merci de tester.

Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
GallyHC
Messages : 1694
Inscription : lun. 17/déc./2007 12:44

Re: Encore un Pb entre PBx86 et PBx64

Message par GallyHC »

Bonjour,

Je viens de faire le test et j'ai bien la même différence entre x32 et x64

X32 :
net.exe
net1.exe
netbtugc.exe
NetCfgNotifyObjectHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE
X64:
net.exe
net1.exe
netbtugc.exe
netcfg.exe
NetCfgNotifyObjectHost.exe
NetEvtFwdr.exe
NetHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE
Cordialement,
GallyHC

PS: ça fait comme ma différence avec MemoryStatus(#PB_System_FreePhysical) et MemoryStatus(#PB_System_TotalVirtual) entre x32 et X64.
Configuration : Tower: Windows 10 (Processeur: i7 "x64") (Mémoire: 16Go) (GeForce GTX 760 - 2Go) - PureBasic 5.72 (x86 et x64)
Avatar de l’utilisateur
Ar-S
Messages : 9155
Inscription : dim. 09/oct./2005 16:51
Contact :

Re: Encore un Pb entre PBx86 et PBx64

Message par Ar-S »

Je suppose que le dossier system32 contient simplement des "verrous" concernant les applis x86 qui ont des interactions avec.
Sur un windows 10 x86, ton appli x86 devrait fonctionner.
~~~~Règles du forum ~~~~
.: Ar-S :. Tour + portable W10 x64 PB 5.6x / 5.7x
Section HORS SUJET : ICI
LDV MULTIMEDIA : Dépannage informatique & mes Logiciels PB
UPLOAD D'IMAGES : Uploader des images de vos logiciels
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Re: Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Merci GallyHc et Ar-s

Le Problème semble assez général et ne touche pas que PureBasic
En effet comme vous avez pu le voir j’avais déjà testé les produits avec MSDOS
Avec les tests des explorateurs et des éditeurs qui permettent l’exécution des fichiers *.exe j’ai obtenu deux catégories de logiciels. Un groupe qui est proche de Microsoft comme explorer.exe bloc-notes ou wordpad qui donnent des résultats OK
Le deuxième groupe avec Powerdesk Total-commander Ultraedit notepad++ explorerPlus donnent des résultats identiques à PBx86. C'est-à-dire mauvais
Pour corser le tout j’ai créé un fichier DIRtot.bat que j’exécute à travers l’un des logiciels précédemment décrit
Les résultats sont identiques à ceux obtenus avec les deux groupes définis ci-dessus. Donc mauvais avec les mauvais et bons avec les bons.

Voici pour ceux qui ne l’auraient pas vu le prg en *.bat
Ce programme doit être placé à la racine de D : par exemple et être exécuté par l’un des logiciels.
Une autre façon de vérifier les résultats OK c’est d’utiliser la commande cmd sous dos est d’exécuter le prg DIRTOT.bat
echo on
copy D:\fichtot0.txt D:\fichtot1.txt
COPY D:\fichtot.txt D:\fichtot0.txt
C:
cd \windows\system32\
dir *.exe /B > D:\fichtot.txt
A+

PS J'ai testé avec la command attrib il n'y a pas de différence entres les *.exe ils sont tous A c'est à dire en Archive.
A C:\WINDOWS\System32\net.exe
A C:\WINDOWS\System32\net1.exe
A C:\WINDOWS\System32\netbtugc.exe
A C:\WINDOWS\System32\netcfg.exe
A C:\WINDOWS\System32\NetCfgNotifyObjectHost.exe
A C:\WINDOWS\System32\NetEvtFwdr.exe
A C:\WINDOWS\System32\NetHost.exe
A C:\WINDOWS\System32\netiougc.exe
A C:\WINDOWS\System32\Netplwiz.exe
A C:\WINDOWS\System32\netsh.exe
A C:\WINDOWS\System32\NETSTAT.EXE
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Re: Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Bonjours à tous

En continuant à chercher pourquoi les logiciels proches de Microsoft obtenaient des résultats corrects
J’ai remarqué que ces produits utilisent UN CMD.EXE différent des autres prg.
Les prg qui donnent de bons effets sont issus de la COMMANDE WINDOWS\SYSTEM32\CMD.EXE

Alors que les logiciels qui donnent de mauvais résultats sont issus de la Commande WINDOWS\SYSWOW64\CMD.EXE.
J’ai essayé de lancer directement CMD.exe en me plaçant soit dans l’un ou l’autre des répertoires.
Ensuite j’ai obtenu les résultats suivants avec la cmd dir net*.exe /B
En WINDOWS\SYSTEM32\CMD.exe
net.exe
net1.exe
netbtugc.exe
netcfg.exe
NetCfgNotifyObjectHost.exe
NetEvtFwdr.exe
NetHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE
Et en WINDOWS\SYSWOW64\CMD.EXE.
net.exe
net1.exe
netbtugc.exe
NetCfgNotifyObjectHost.exe
netiougc.exe
Netplwiz.exe
netsh.exe
NETSTAT.EXE
Alors la question pourquoi en pbx32 bits l’instruction runprogram appel cmd du répertoire WINDOWS\SYSWOW64\CMD.EXE.
Alors que tous les produits microsoft utilisent le répertoire WINDOWS\SYSTEM32\CMD.exe

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Re: Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Bonjour à tous

Voila la réponse à la différence entre les deux répertoires trouvée sur internet.
Différence entre sous repertoires system32 et syswow64

Bonjour,

Sous les précédentes versions de windows, j'avais l'habitude d'utiliser le logiciel Cathy de Robert Vasicek pour cataloguer l'ensemble de mes fichiers présents sur supports internes et externes.

Ce programme nécessitait la présence de msvcr100.dll et mfc100.dll qui figuraient dans system32.

Manuellement je les ai recopiées dans system32 de windows10. Cela ne marche pas.

Il a fallu que je les recopie dans syswow64 pour que le programme soit opérationnel.

D'ou ma question : quelle est la différence entre les sous répertoires system32 et syswow64 ?

Merci pour votre aide
Ce fil de discussion est verrouillé. Vous pouvez suivre la question ou voter pour indiquer si une réponse est utile, mais vous ne pouvez pas répondre à ce fil de discussion.
|
Réponse Réponse
PapyNet
PapyNet

MVP |
Modérateur bénévole

Hello Herser [MVP] !

Bonjour

La différence tient simplement au fait que tu étais auparavant sur un Windows 32 bits et que tu es passé sur un Windows 64 bits, et cette différence existe depuis XP 64 bits (rare il est vrai)

Sur un Windows 64 bits les applications strictement 32 bits peuvent tourner (mais pas les 16 bits) en passant par un émulateur 32 bits appelé Windows (sous entendu 32 bits) on Windows 64 bits, abrégé en*WoW64.*

Pour des raisons de rétrocompatibilité, *system32* reste le répertoire des fichiers nécessaires à Windows (qu'il soit en 32 ou 64 bits) et*syswow64* le répertoire nécessaire aux applications 32 bits sur un Windows 64 bits.

C'est à priori déstabilisant puisque system32 c'est pour les applications 64 bits et syswow64 pour les applications 32 bits

Mais quand on comprend ce que veut dire wow64, tout s’éclaire.

c'est la réponse à cette question "pourquoi faire simple quand on peut faire compliqué" ? !!!!! et cela perdure avec W10
Je suis d'accord avec la dernière phrase.

pourquoi faire simple quand on peut faire compliqué" ? !!!!!

Et pourquoi Fred a t-il choisi comme interpréteur de commande MSDOS sysWOW64 plutôt que system32 ?????

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Marc56
Messages : 1948
Inscription : sam. 08/févr./2014 15:19

Re: Encore un Pb entre PBx86 et PBx64

Message par Marc56 »

Bonjour,

TL;DR
C'est Windows qui choisi quel CMD.EXE et DLL en fonction de l'OS appelant: Donc PB 32 bits => CMD de SysWOW64

En détails:
Pour assurer la compatibilité ascendante (depuis plus de 20 ans!), Windows mets toujours ses DLL et outils systèmes dans %windir%\System32 quelque soit la version 32 ou 64 bits de Windows. (merci pour nous qui faisons des Setup)

Dans un Windows 64 bits, %windir%\System32 contient donc les versions 64 bits pour ne pas créer de conflits de noms entre les versions des DLL et outils 32 ou 64 bits.
Les versions 32 bits sont alors dans SYSWOW64 (contrairement à ce que son nom indique)

Un appel au shell (CMD.EXE) exécuté depuis PB 32 bits utilisera donc le CMD contenu dans SYSWOW64 (donc 32 bits), de même pour n'importe quel programme 32 bits, mais c'est le système d'exploitation qui gère ça tout seul (et pas Fred).

Avantage pour les développeurs: ne pas s'occuper de savoir où mettre et appeler une DLL peut importe la version de l'utilisateur.

SysWOW64 est l'acronyme de System Windows 32 bits on Windows 64 bits, donc une sorte d'émulateur 32 bits.

Si tu lances un programme 32 bits dans un windows 64 bits et que tu regarde les process utilisés, tu verra tout un tas de C:\Windows\SysWOW64\... à la place des habituels c:\windows\system32

Process Explorer
https://docs.microsoft.com/fr-fr/sysint ... s-explorer

Ça parait bizarre comme ça, mais merci à Microsoft de nous permettre de faire et d'utiliser des programmes qui tournent de Windows XP (2001, 20 ans!) à Windows 10 sans qu'on s'occupe de quoi que ce soit.

:wink:
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Re: Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Merci Marc56

A l’analyse j’avais bien compris que microsoft avait placé les produits 32 bits dans le répertoire syswow64 et les produits 64 bits dans le répertoire system32. (Pourquoi faire simple quand on peut faire compliquer)

Utilisateur de sysinternals _suite j’utilise plutôt procmon qui a remplacé filemon pour vérifier les process ou les fichiers qui sont utilisés.
On voit que sous pb32bits l’appel à syswow64 est souvent appelé et nettement moins sous pb64bits.

Mais ceci n’explique pas pourquoi un logiciel 32bits lorsqu’on lui demande de lister les fichiers d’un répertoire ne donne pas les mêmes résultats qu’un logiciel 64bits. (Manque de cohérence entre les deux prg).
Remarque : Le problème n’est pas propre à Purebasic mais il existe un défaut d’un point de vue logique

Essayez ce prg sous PB32bits et sous pb64bits les résultats sont différents. Bizarre vous avez dit bizarre !!!

Code : Tout sélectionner

Repertoire$ = "c:\windows\system32\"
 If ExamineDirectory(0, Repertoire$, "*.*")  
   i32=0
    While NextDirectoryEntry(0)
      Debug  DirectoryEntryName(0) 
      i32+1
    Wend
    FinishDirectory(0)
  EndIf
  prg=RunProgram("d:\dirtot.bat")
  Debug "*****************************************************"
 Repertoire$ = "c:\windows\sysWOW64\"
 If ExamineDirectory(0, Repertoire$, "*.*") 
   i64=0
    While NextDirectoryEntry(0)
      Debug  DirectoryEntryName(0) 
      I64+1
    Wend
    FinishDirectory(0)
  EndIf
  Debug "i32="+Str(i32)+" i64="+Str(i64)

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
ChrisR
Messages : 143
Inscription : sam. 14/févr./2015 16:20

Re: Encore un Pb entre PBx86 et PBx64

Message par ChrisR »

Bonjour,
Ce n'est pas nouveau, la redirection est comme cela depuis Vista, Windows 7 x64
Redirecteur de système de fichiers (traduction auto)
File System Redirector

Pour info, Il en est de même pour le registre avec certaines clés redirigées vers Wow6432Node, voir:
Redirecteur du Registre (traduction auto)
Registry Redirector


Tu peux utiliser Sysnative pour supprimer la redirection avec PB x86 (32bits)

Code : Tout sélectionner

CompilerIf #PB_Compiler_Processor = #PB_Processor_x86
  Repertoire$ = "C:\Windows\Sysnative\"  ;Vista+
CompilerElse
  Repertoire$ = "C:\Windows\System32\"
CompilerEndIf

Ou utiliser les APIs Wow64DisableWow64FsRedirection et Wow64RevertWow64FsRedirection

Code : Tout sélectionner

CompilerIf #PB_Compiler_Processor = #PB_Processor_x86
  Procedure DisableWow64FsRedirection()
    Protected IsWow64ProcessFlag, Flag
    OpenLibrary(0, "Kernel32.dll")
    If IsLibrary(0)  
      GetFunction(0, "IsWow64Process")
      CallFunction(0, "IsWow64Process", GetCurrentProcess_(), @IsWow64ProcessFlag)
      If IsWow64ProcessFlag <> 0 And SizeOf(Integer) = 4
        GetFunction(0, "Wow64DisableWow64FsRedirection") 
        CallFunction(0, "Wow64DisableWow64FsRedirection", Flag)
      EndIf
      CloseLibrary(0)
    EndIf
  EndProcedure
  
  Procedure RevertWow64FsRedirection()
    Protected IsWow64ProcessFlag, Flag
    OpenLibrary(0, "Kernel32.dll")
    If IsLibrary(0)  
      GetFunction(0, "IsWow64Process")
      CallFunction(0, "IsWow64Process", GetCurrentProcess_(), @IsWow64ProcessFlag)
      If IsWow64ProcessFlag <> 0 And SizeOf(Integer) = 4
        GetFunction(0, "Wow64RevertWow64FsRedirection") 
        CallFunction(0, "Wow64RevertWow64FsRedirection", Flag)
      EndIf
      CloseLibrary(0)
    EndIf
  EndProcedure
  ;#KEY_WOW64_64KEY	0x0100	Access a 64-bit key from either a 32-bit Or 64-bit application.
  ;#KEY_WOW64_32KEY	0x0200	Access a 32-bit key from either a 32-bit Or 64-bit application.
CompilerEndIf

CompilerIf #PB_Compiler_Processor = #PB_Processor_x86  
  DisableWow64FsRedirection()
CompilerEndIf
Marc56
Messages : 1948
Inscription : sam. 08/févr./2014 15:19

Re: Encore un Pb entre PBx86 et PBx64

Message par Marc56 »

Mais ceci n’explique pas pourquoi un logiciel 32bits lorsqu’on lui demande de lister les fichiers d’un répertoire ne donne pas les mêmes résultats qu’un logiciel 64bits. (Manque de cohérence entre les deux prg).
  • Sur un autre répertoire que l'un des répertoires système, j'ai le même nombre de fichiers.
  • Il est normal qu'un programme 32 bits ne voit pas tous les fichiers système 64 bit.
  • Il vaut mieux faire les deux versions d'un même programme (surtout qu'en mode projet c'est facile) plutôt qu'un 32 bits bidouillé.
  • Dans tous les cas, toujours utiliser les variables système (ex: %windir%\system32) ça fonctionne partout.
PAPIPP
Messages : 525
Inscription : sam. 23/févr./2008 17:58

Re: Encore un Pb entre PBx86 et PBx64

Message par PAPIPP »

Merci Chrisr et Marc56

J’avais bien compris que tout prg en 32 bits subit la redirection vers SYSWOW64 pour des besoins de transparence et de compatibilité.
Mais loin de moi de penser que microsoft bascule aussi tout appel externe au produit à l’un de ces répertoires.
Il faut donc une grosse bidouille pour accéder sous un prg 32 bit au répertoire system32 réservé en priorité aux prg 64bits.
J’ai tester les deux algos de redirection ils fonctionnent parfaitement bien.
Pour des pb de pédagogie j’ai gardé le deuxième ici comme exemple.

Code : Tout sélectionner

Global I32,I64
Procedure SYS32()
Repertoire$ = "c:\windows\system32\"
 If ExamineDirectory(0, Repertoire$, "net*.*")  
   i32=0
    While NextDirectoryEntry(0)
      Debug  DirectoryEntryName(0) 
      i32+1
    Wend
    FinishDirectory(0)
  EndIf
  prg=RunProgram("d:\dirtot.bat")
  EndProcedure
  Debug "*****************************************************"
Procedure SYS64()
 Repertoire$ = "c:\windows\sysWOW64\"
 If ExamineDirectory(0, Repertoire$, "net*.*") 
   i64=0
    While NextDirectoryEntry(0)
      Debug  DirectoryEntryName(0) 
      I64+1
    Wend
    FinishDirectory(0)
  EndIf
EndProcedure 
sys32()
  Debug "*****************************************************"
sys64()
  Debug "i32="+Str(i32)+" i64="+Str(i64)
  Debug "**********************   APRES   REDIRECTION *******************************"

CompilerIf #PB_Compiler_Processor = #PB_Processor_x86
  Procedure DisableWow64FsRedirection()
    Protected IsWow64ProcessFlag, Flag
    OpenLibrary(0, "Kernel32.dll")
    If IsLibrary(0)  
      GetFunction(0, "IsWow64Process")
      CallFunction(0, "IsWow64Process", GetCurrentProcess_(), @IsWow64ProcessFlag)
      If IsWow64ProcessFlag <> 0 And SizeOf(Integer) = 4
        GetFunction(0, "Wow64DisableWow64FsRedirection") 
        CallFunction(0, "Wow64DisableWow64FsRedirection", Flag)
      EndIf
      
      sys32()
      Debug "*****************************************************"
      sys64()
      Debug "i32="+Str(i32)+" i64="+Str(i64)
      
      CloseLibrary(0)
    EndIf
  EndProcedure
  
  Procedure RevertWow64FsRedirection()
    Protected IsWow64ProcessFlag, Flag
    OpenLibrary(0, "Kernel32.dll")
    If IsLibrary(0)  
      GetFunction(0, "IsWow64Process")
      CallFunction(0, "IsWow64Process", GetCurrentProcess_(), @IsWow64ProcessFlag)
      If IsWow64ProcessFlag <> 0 And SizeOf(Integer) = 4
        GetFunction(0, "Wow64RevertWow64FsRedirection") 
        CallFunction(0, "Wow64RevertWow64FsRedirection", Flag)
      EndIf
      CloseLibrary(0)
    EndIf
  EndProcedure
  ;#KEY_WOW64_64KEY	0x0100	Access a 64-bit key from either a 32-bit Or 64-bit application.
  ;#KEY_WOW64_32KEY	0x0200	Access a 32-bit key from either a 32-bit Or 64-bit application.
CompilerEndIf

CompilerIf #PB_Compiler_Processor = #PB_Processor_x86  
  DisableWow64FsRedirection()
CompilerEndIf

Par ailleurs j’ai continué à explorer les divers logiciels gratuits comme explorateur. Les résultats sont divers
Powerdesk donne les mêmes résultats sur les deux répertoires !!! explorer de windo10 donne des résultats différents sur les deux répertoires Total_Commander donne des résultats mitigés etc…
Cela ne m’étonne pas car avec la traduction que Chrisr a envoyé
Redirecteur de système de fichiers
• 31/05/2018
• 3 minutes de lecture
Le répertoire% windir% \ system32 est réservé aux applications 64 bits sur Windows 64 bits. La plupart des noms de fichiers DLL n’ont pas été modifiés lors de la création de versions 64 bits des dll. par conséquent, les versions 32 bits des dll sont stockées dans un répertoire différent. WOW64 masque cette différence à l’aide d’un redirecteur de système de fichiers.
Dans la plupart des cas, chaque fois qu’une application 32 bits tente d’accéder à% windir% \ system32,% windir% \ LastGood \ system32 ou% windir% \regedit.exe, l’accès est redirigé vers un chemin d’accès spécifique à l’architecture.
Notes
Ces chemins d’accès sont fournis à des fins de référence uniquement. Pour des fins de compatibilité, les applications ne doivent pas utiliser ces chemins directement. Au lieu de cela, ils doivent appeler les API décrites ci-dessous.
Table 1
Chemin d’accès d’origine Chemin Redirigé pour les processus x86 32 bits Chemin Redirigé pour les processus ARM 32 bits
% windir% \ system32 % windir% \ SysWOW64 % windir% \ SysArm32
% windir% \ LastGood \ system32 % windir% \ LastGood \ SysWOW64 % windir% \ LastGood \ SysArm32
% windir% \regedit.exe % windir% \ SysWOW64 \regedit.exe % windir% \ SysArm32 \regedit.exe
Si l’accès amène le système à afficher l’invite du contrôle de compte d’utilisateur, la redirection n’a pas lieu. Au lieu de cela, la version 64 bits du fichier demandé est lancée. Pour éviter ce problème, spécifiez le répertoire SysWOW64 pour éviter la redirection et assurez-vous d’accéder à la version 32 bits du fichier, ou exécutez l’application 32 bits avec des privilèges d’administrateur pour que l’invite UAC ne s’affiche pas.

o Windows Server 2003 et Windows XP : * * le contrôle de compte d’utilisateur n’est pas pris en charge.
Certains sous-répertoires sont exempts de redirection. L’accès à ces sous-répertoires n’est pas redirigé vers% windir% \ SysWOW64 :
% windir% \ system32 \ CatRoot
% windir% \ system32 \ Catroot2
% windir% \ system32 \ DriverStore
% windir% \ system32 \ drivers, \ etc.
% windir% \ system32 \ LogFiles
% windir% \ system32 \ spool

o Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP : * *% windir% \ system32 \ DriverStore est redirigé.
On voit que la bidouille est de rigueur.

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Répondre