Bonjour aux cadors et aux autres,

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 = "SOFTWARE\Classes"
la fonction retourne bien zéro.
Par contre, pour les niveaux de clefs inférieurs, tels que
sKeyName = "SOFTWARE\Classes\PowerPoint.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 ?

J'ai parcouru la FAQ et utilisé Google sans succès.

Merci

--
Cordialement
Aski

AntiSpamEdit (ASE) - XtractOE et XtractWM - K9 en français
http://dechily.org/downloads.htm

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 = "SOFTWARE\Classes"
> la fonction retourne bien zéro.
> Par contre, pour les niveaux de clefs inférieurs, tels que
> sKeyName = "SOFTWARE\Classes\PowerPoint.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/downlo...uacdevreqs.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?question=71.
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

Bonjour François, tu as écrit le 12/01/2008 :

> 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 = "SOFTWARE\Classes"
>> la fonction retourne bien zéro.
>> Par contre, pour les niveaux de clefs inférieurs, tels que
>> sKeyName = "SOFTWARE\Classes\PowerPoint.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/downlo...uacdevreqs.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?question=71. 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.
Par contre la lecture et l'écriture des éléments correspondants de
HKEY_CLASS_ROOT ne pose pas de problème.

Pour le moment je teste uniquement en lecture et j'aurai plus tard à
écrire mais pas dans la sous-clef 'Classes'.
Je te remercie pour le premier lien, très dense et dur à digérer mais
très complet. Il devrait me permettre de poursuivre si j'arrive à
résoudre le problème de lecture qui ne devrait théoriquement pas
demander d'élévation de privilèges.

--
Cordialement
Aski

AntiSpamEdit (ASE) - XtractOE et XtractWM - K9 en français
http://dechily.org/downloads.htm

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.

--
Cordialement
Aski

AntiSpamEdit (ASE) - XtractOE et XtractWM - K9 en français
http://dechily.org/downloads.htm

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 :

"SOFTWARE\Classes\PowerPoint.Application"

se trouve dans HKEY_LOCAL_MACHINE, pas dans HKEY_CLASSE_ROOT

Tu peux utiliser soit :
sKeyName = "SOFTWARE\Classes\PowerPoint.Application"
retval = RegOpenKeyEx(HKEY_LOCAL_MACHINE, sKeyName, 0, KEY_READ, hKey)

soit :
sKeyName = "PowerPoint.Application"
retval = RegOpenKeyEx(HKEY_CLASSES_ROOT, sKeyName, 0, KEY_READ, hKey)

Si tu avais un problème de droit d'accès, je crois que c'est une erreur
5 que tu aurais (ACCESS_DENIED)

--
Cordialement,

Jacques.

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

Hello François et Georges :

> 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

C'est moi qui dois vous demander de m'excuser car mon programme
fonctionnait parfaitement et, à force de *bricoler*, j'ai inversé les
valeurs de clés (les constantes auxquelles je faisais allusion).
De plus, cela m'a donné l'occasion de télécharger le document fort
intéressant dont tu as donné le lien.

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.

À 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.

Merci à tous les deux.

--
Cordialement
Aski

AntiSpamEdit (ASE) - XtractOE et XtractWM - K9 en français
http://dechily.org/downloads.htm

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_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The HKEY_CURRENT_USER
\Software\Classes 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_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under HKEY_LOCAL_MACHINE\Software
\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,

> 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_MACHINE\Software\Classes key contains default settings that
> can apply to all users on the local computer. The HKEY_CURRENT_USER
> \Software\Classes 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_MACHINE\Software\Classes. If you
> write values to a key under HKEY_CLASSES_ROOT, and the key already
> exists under HKEY_CURRENT_USER\Software\Classes, the system will store
> the information there instead of under HKEY_LOCAL_MACHINE\Software
> \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

Réponse précise.
Malheureusement c'est ce que je craignais. J'ai donc le choix, soit
d'imposer l'utilisation de cet utilitaire à tous les utilisateurs, soit
de m'atteler au boulot ...
Merci François.

--
Cordialement
Aski

AntiSpamEdit (ASE) - XtractOE et XtractWM - K9 en français
http://dechily.org/downloads.htm

Bonsoir Robert,
aski a écrit :
> 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.
>

A ta place j'éviterai de me baser sur l'erreur 5, car même en demandant
des droits en écriture (KEY_WRITE) sur HKLM. Le code suivant :

sKeyName = "SOFTWARE\Classes\PowerPoint.Application"
retval = RegOpenKeyEx(HKEY_LOCAL_MACHINE, sKeyName, 0, _
KEY_WRITE, hKey)
MsgBox "HKLM : " & retval
RegCloseKey hKey

ne provoquera pas d'erreur 5 sous Vista (alors que on l'a sous XP). Cela
est du à la virtualisation, voir page 18 du document indiqué par François.

Te rappelles tu du fil avec Kiriasse concernant Program Files ?

<http://groups.google.fr/group/microsoft.public.fr.vb/browse_thread/thread/9651f57b9c5f2bb2/3932a1483ee9e1f6?hl=fr&lnk=st&q=virtualstore+jacqu es93+group%3Amicrosoft.public.fr.vb#3932a1483ee9e1 f6>

bien pour les clés de registre c'est similaire. Au lieu d'écrire les
clés dans HKLM\SOFTWARE, elles seront écrites dans
HKCU\SOFTWARE\Classes\VirtualStore. Et de la même manière que pour les
fichiers, cela est transparent, sauf que pour les fichiers on ne les
voient pas à l'endroit qu'on pensait dans l'explorateur, et que pour les
clés on ne les voient pas à l'endroit prévu via regedit.

Sinon, un petit truc pour avoir un libellé clair des retours d'API, et
ainsi éviter certaines confusions :


Private Const FORMAT_MESSAGE_FROM_SYSTEM = &H1000
Private Declare Function FormatMessage Lib "kernel32" Alias
"FormatMessageA" _
(ByVal dwFlags As Long, lpSource As Any, _
ByVal dwMessageId As Long, ByVal dwLanguageId As Long, _
ByVal lpBuffer As String, ByVal nSize As Long, Arguments As
Long) As Long


Public Function FriendlyError(ErrNo As Long) As String
Dim lResult As Long
Dim Buffer As String * 256

lResult = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, 0, _
ErrNo, 0, Buffer, Len(Buffer), 0)
If lResult > 0 Then
FriendlyError = Left(Buffer, lResult - 2) & _
" (" & Format(ErrNo) & ")"
Else
FriendlyError = "Erreur numéro " & Format(ErrNo)
End If
End Function


Essaie avec :

MsgBox FriendyError (2)

--
Cordialement,

Jacques.

Bonjour François Picalausa,
François Picalausa a écrit :
> 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
>

Pas bien grave :-) , mais c'est même un peu plus compliqué. Regardes ma
réponse à aski, qui parle des pages 18 à 22 du document que tu as indiqué.

L'erreur 5, c'est bien elle si il y a un problème de privilèges, on ne
l'obtiens que sous XP (ou précédent), pas sous Vista.

Ce principe de virtualisation a été mis en place, apparemment, pour
éviter que les utilisateurs modifient les droits d'accès sur les
répertoires ou les clés de registre, et garder une compatibilité avec
certains logiciel.

Mais il est bien précisé, que ce système est temporaire et ne sera pas
conservé dans les versions suivantes de l'OS :

<Citation>
Microsoft intends to remove virtualization from future versions of the
Windows operating system as more applications are migrated to Windows
Vista. For example, virtualization is disabled on 64-bit applications.
</Citation>

--
Cordialement,

Jacques.

Hello Jacques,

Tu as écrit :

> Pas bien grave :-) , mais c'est même un peu plus compliqué. Regardes
> ma réponse à aski, qui parle des pages 18 à 22 du document que tu as
> indiqué.
> L'erreur 5, c'est bien elle si il y a un problème de privilèges, on ne
> l'obtiens que sous XP (ou précédent), pas sous Vista.
>
> Ce principe de virtualisation a été mis en place, apparemment, pour
> éviter que les utilisateurs modifient les droits d'accès sur les
> répertoires ou les clés de registre, et garder une compatibilité avec
> certains logiciel.
>
> Mais il est bien précisé, que ce système est temporaire et ne sera pas
> conservé dans les versions suivantes de l'OS :
>
> <Citation>
> Microsoft intends to remove virtualization from future versions of the
> Windows operating system as more applications are migrated to Windows
> Vista. For example, virtualization is disabled on 64-bit applications.
> </Citation>

Cela rendra les choses certainement plus rationnelles.
Cependant, est-ce que cela ne gènera pas plus le fonctionnement de certains
"vieux" programmes ?