Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
On Jan 11, 8:08 pm, aski wrote:Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
Hello,
Vista empêche par défaut (excepté élévation de privilège) _l'écriture_
dans HKLM (ce qui est identique), à l'exception de certaines clés (qui
sont, si je me souviens bien, dupliquées dans une hive virtuelle).
KEY_ALL_ACCESS comprenant les droits d'écriture, il est normal que
l'API te renvoie un 2 pour certaines de celles-ci. En particulier, la
clés Classes en question n'a les droits Full Control qu'avec des
privilèges élevés.
Je te conseille de jeter un oeil à
http://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/windowsvistauacdevreqs.doc,
page 82 pour les détails.
Si tu as besoin d'un accès en lecture, le droit KEY_READ est
approprié. Ceci est illustré dans la FAQ:
http://faq.vb.free.fr/index.php?questionq. Dans le cas contraire, où tu
aurais réellement besoin d'un accès en écriture, le document mentionné
indique aussi comment demander une élévation de privilèges (notament à
l'aide d'un manifest approprié).
François
On Jan 11, 8:08 pm, aski <a...@asc.asc> wrote:
Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
Hello,
Vista empêche par défaut (excepté élévation de privilège) _l'écriture_
dans HKLM (ce qui est identique), à l'exception de certaines clés (qui
sont, si je me souviens bien, dupliquées dans une hive virtuelle).
KEY_ALL_ACCESS comprenant les droits d'écriture, il est normal que
l'API te renvoie un 2 pour certaines de celles-ci. En particulier, la
clés Classes en question n'a les droits Full Control qu'avec des
privilèges élevés.
Je te conseille de jeter un oeil à
http://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/windowsvistauacdevreqs.doc,
page 82 pour les détails.
Si tu as besoin d'un accès en lecture, le droit KEY_READ est
approprié. Ceci est illustré dans la FAQ:
http://faq.vb.free.fr/index.php?questionq. Dans le cas contraire, où tu
aurais réellement besoin d'un accès en écriture, le document mentionné
indique aussi comment demander une élévation de privilèges (notament à
l'aide d'un manifest approprié).
François
On Jan 11, 8:08 pm, aski wrote:Je n'arrive pas à ouvrir certaines clés du registre sous Vista et VB6
avec la fonction API classique :
RetVal = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_ALL_ACCESS,
hKey)
Pour
sKeyName = "SOFTWAREClasses"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWAREClassesPowerPoint.Application"
la fonction retourne 2
Les clés analogues de HKEY_CURRENT_USER ne posent pas de problème
Savez-vous s'il existe une sécurité dans Vista empêchant d'ouvrir de
telles clés ?
Hello,
Vista empêche par défaut (excepté élévation de privilège) _l'écriture_
dans HKLM (ce qui est identique), à l'exception de certaines clés (qui
sont, si je me souviens bien, dupliquées dans une hive virtuelle).
KEY_ALL_ACCESS comprenant les droits d'écriture, il est normal que
l'API te renvoie un 2 pour certaines de celles-ci. En particulier, la
clés Classes en question n'a les droits Full Control qu'avec des
privilèges élevés.
Je te conseille de jeter un oeil à
http://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/windowsvistauacdevreqs.doc,
page 82 pour les détails.
Si tu as besoin d'un accès en lecture, le droit KEY_READ est
approprié. Ceci est illustré dans la FAQ:
http://faq.vb.free.fr/index.php?questionq. Dans le cas contraire, où tu
aurais réellement besoin d'un accès en écriture, le document mentionné
indique aussi comment demander une élévation de privilèges (notament à
l'aide d'un manifest approprié).
François
Je me doutais que le problème provenait d'un problème de privilèges et j'ai
bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
Je me doutais que le problème provenait d'un problème de privilèges et j'ai
bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
Je me doutais que le problème provenait d'un problème de privilèges et j'ai
bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
Re François :Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
Re François :
Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
Re François :Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
Bonjour Henri,
aski a écrit :
> Re François :
>> Je me doutais que le problème provenait d'un problème de privilèg es et
>> j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dir e).
>> Cet essai n'a pas résolu le problème.
> J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
> Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La cl é que
tu indiques :
Si tu avais un problème de droit d'accès, je crois que c'est une erreu r
5 que tu aurais (ACCESS_DENIED)
Bonjour Henri,
aski a écrit :
> Re François :
>> Je me doutais que le problème provenait d'un problème de privilèg es et
>> j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dir e).
>> Cet essai n'a pas résolu le problème.
> J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
> Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La cl é que
tu indiques :
Si tu avais un problème de droit d'accès, je crois que c'est une erreu r
5 que tu aurais (ACCESS_DENIED)
Bonjour Henri,
aski a écrit :
> Re François :
>> Je me doutais que le problème provenait d'un problème de privilèg es et
>> j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dir e).
>> Cet essai n'a pas résolu le problème.
> J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
> Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La cl é que
tu indiques :
Si tu avais un problème de droit d'accès, je crois que c'est une erreu r
5 que tu aurais (ACCESS_DENIED)
On Jan 12, 2:20 pm, Jacques93 wrote:Bonjour Henri,
aski a écrit :Re François :J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François
On Jan 12, 2:20 pm, Jacques93 <jacques@Nospam> wrote:
Bonjour Henri,
aski a écrit :
Re François :
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>
Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François
On Jan 12, 2:20 pm, Jacques93 wrote:Bonjour Henri,
aski a écrit :Re François :J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François
À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
On Jan 12, 4:27 pm, aski wrote:À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
Hello,
Selon la documention de win32:
<quote src="http://msdn2.microsoft.com/en-us/library/ms724475.aspx">
The HKEY_CLASSES_ROOT (HKCR) key contains file extension associations
and COM class registration information such as ProgIDs, CLSIDs, and
IIDs. It is primarily intended for compatibility with the registry in
16-bit Windows.
Class registration and file extension information is stored under both
the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINESoftwareClasses key contains default settings that
can apply to all users on the local computer. The HKEY_CURRENT_USER
SoftwareClasses key contains settings that apply only to the
interactive user. The HKEY_CLASSES_ROOT key provides a view of the
registry that merges the information from these two sources.
HKEY_CLASSES_ROOT also provides this merged view for applications
designed for previous versions of Windows.
</quote>
Donc, si tu écris dans HKCR, l'information sera "au bon endroit",
c'est à dire:
<quote>
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINESoftwareClasses. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USERSoftwareClasses, the system will store
the information there instead of under HKEY_LOCAL_MACHINESoftware
Classes.
</quote>
Néanmoins, même si ça fonctionne, ce n'est que par compatibilité.
Si le but est de modifier l'information pour tout le monde, c'est HKLM
qu'il faut changer. Si le but est de changer les settings de
l'utilisateur courant uniquement, HKCU est l'endroit approprié.
Les deux ne sont donc, en général, pas équivalent.
François
On Jan 12, 4:27 pm, aski <a...@asc.asc> wrote:
À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
Hello,
Selon la documention de win32:
<quote src="http://msdn2.microsoft.com/en-us/library/ms724475.aspx">
The HKEY_CLASSES_ROOT (HKCR) key contains file extension associations
and COM class registration information such as ProgIDs, CLSIDs, and
IIDs. It is primarily intended for compatibility with the registry in
16-bit Windows.
Class registration and file extension information is stored under both
the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINESoftwareClasses key contains default settings that
can apply to all users on the local computer. The HKEY_CURRENT_USER
SoftwareClasses key contains settings that apply only to the
interactive user. The HKEY_CLASSES_ROOT key provides a view of the
registry that merges the information from these two sources.
HKEY_CLASSES_ROOT also provides this merged view for applications
designed for previous versions of Windows.
</quote>
Donc, si tu écris dans HKCR, l'information sera "au bon endroit",
c'est à dire:
<quote>
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINESoftwareClasses. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USERSoftwareClasses, the system will store
the information there instead of under HKEY_LOCAL_MACHINESoftware
Classes.
</quote>
Néanmoins, même si ça fonctionne, ce n'est que par compatibilité.
Si le but est de modifier l'information pour tout le monde, c'est HKLM
qu'il faut changer. Si le but est de changer les settings de
l'utilisateur courant uniquement, HKCU est l'endroit approprié.
Les deux ne sont donc, en général, pas équivalent.
François
On Jan 12, 4:27 pm, aski wrote:À ce propos, est-il équivalent de modifier une vealeur dans HKCR et
HKLM lorsqu'on n'est pas seul utilisateur ?
Si la réponse était oui, cela simplifierait beaucoup les problèmes
d'écriture.
Hello,
Selon la documention de win32:
<quote src="http://msdn2.microsoft.com/en-us/library/ms724475.aspx">
The HKEY_CLASSES_ROOT (HKCR) key contains file extension associations
and COM class registration information such as ProgIDs, CLSIDs, and
IIDs. It is primarily intended for compatibility with the registry in
16-bit Windows.
Class registration and file extension information is stored under both
the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINESoftwareClasses key contains default settings that
can apply to all users on the local computer. The HKEY_CURRENT_USER
SoftwareClasses key contains settings that apply only to the
interactive user. The HKEY_CLASSES_ROOT key provides a view of the
registry that merges the information from these two sources.
HKEY_CLASSES_ROOT also provides this merged view for applications
designed for previous versions of Windows.
</quote>
Donc, si tu écris dans HKCR, l'information sera "au bon endroit",
c'est à dire:
<quote>
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINESoftwareClasses. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USERSoftwareClasses, the system will store
the information there instead of under HKEY_LOCAL_MACHINESoftware
Classes.
</quote>
Néanmoins, même si ça fonctionne, ce n'est que par compatibilité.
Si le but est de modifier l'information pour tout le monde, c'est HKLM
qu'il faut changer. Si le but est de changer les settings de
l'utilisateur courant uniquement, HKCU est l'endroit approprié.
Les deux ne sont donc, en général, pas équivalent.
François
Hello François et Georges :
Le plus idiot est qu'une routine dirige vers un message dans le cas où
la fonction d'ouverture retourne 5. Je n'ai pas prêté attention à la
valeur et pensais qu'il s'agissait effectivement d'un problème de droits.
Hello François et Georges :
Le plus idiot est qu'une routine dirige vers un message dans le cas où
la fonction d'ouverture retourne 5. Je n'ai pas prêté attention à la
valeur et pensais qu'il s'agissait effectivement d'un problème de droits.
Hello François et Georges :
Le plus idiot est qu'une routine dirige vers un message dans le cas où
la fonction d'ouverture retourne 5. Je n'ai pas prêté attention à la
valeur et pensais qu'il s'agissait effectivement d'un problème de droits.
On Jan 12, 2:20 pm, Jacques93 wrote:Bonjour Henri,
aski a écrit :Re François :Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François
On Jan 12, 2:20 pm, Jacques93 <jacques@Nospam> wrote:
Bonjour Henri,
aski a écrit :
Re François :
Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>
Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François
On Jan 12, 2:20 pm, Jacques93 wrote:Bonjour Henri,
aski a écrit :Re François :Je me doutais que le problème provenait d'un problème de privilèges et
j'ai bien sûr essayé avec KEY_READ (pardon, j'ai oublié de le dire).
Cet essai n'a pas résolu le problème.
J'y suis enfin arrivé, j'avais dû faire une erreur de constante.
Merci François.
L'erreur 2 correspond à FILE_NOT_FOUND (ici clé non trouvée). La clé que
tu indiques :
<snip>Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)
Hello,
Effectivement. Toutes mes excuses pour erreur de ma part; j'aurais du
vérifier.
Cela étant, merci du retour, Aski!
François