Lecture du registre

Signaler
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014
-
cs_mcoppa
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014
-
Bonjour,

J'ai un programme écrit en VB6 pour lire les information sur la version de Windows à l'aide de la fonction :
Private Declare Function RegQueryValueEx Lib "advapi32" Alias "RegQueryValueExA" (ByVal hKey As Long, ByVal lpValueName As String, ByVal lpReserved As Long, ByRef lpType As Long, ByVal lpData As String, ByRef lpcbData As Long) As Long

Ce programme fonctionne parfaitement sous WXP 32bits, par contre sous Windows 7 64bits, certaines clés ne sont pas lues.
"CSDVersion" renvoie une erreur 2 ; idem pour "SourcePath" et "ProductId". Si on ouvre Regedit, ces clés sont bien présentes.

Quelqu'un peut-il m'éclairer ? Merci d'avance.



mcoppa

14 réponses

Messages postés
1241
Date d'inscription
mardi 10 octobre 2006
Statut
Membre
Dernière intervention
27 août 2013
4
Bonjour,

Il s'agit sûrement d'un problème de droit sur ces clés, si tu l'exécutes en tant qu'admin est-ce que ça fonctionne?


L'expérience, c'est une connerie par jour, mais jamais la même..
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Re

Non, c'est pareil et même si je lui dis de s'exécuter en mode compatibilité XP.
Ce qui est bizarre c'est que certaine clés sont lues normalement.


mcoppa
Messages postés
3172
Date d'inscription
dimanche 15 février 2004
Statut
Membre
Dernière intervention
9 avril 2017
28
"CSDVersion" renvoie une erreur 2

Pourquoi ne nous donnes tu aps le message d'erreur ? C'est le plus important ici !!!

_____________
Kenji
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Lors de l'ouverture, je n'ai pas d'erreur. Mais lors de la lecture, pour tous ceux qui ne sont pas lus, j'ai une erreur 2.


mcoppa

Bonjour,

Commence par là
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
220
Bonjour, (et un salut à cmarcotte)

J'ajouterais que l'utilisation de la fonction Environ devrait suffire
Environ$("OS")
te retournera l'OS
J'ignore (n'ayant pas installé VB6 sous Win 7 - 64 bits) si suffisant, mais probablement oui, en complétant par la vérification de l'existence d'un répertoire SYSWOW64 (avec la fonction DIR)

________________________
Réponse exacte ? => "REPONSE ACCEPTEE" facilitera les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement répéter son contenu. Je n'interviendrai que si nécessité de la compléter.
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
220
Regarde aussi (je l'avais oublié, ceux-là) ce que retournent
Environ$("PROCESSOR_ARCHITECTURE")
et
Environ$("PROCESSOR_LEVEL")

________________________
Réponse exacte ? => "REPONSE ACCEPTEE" facilitera les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement répéter son contenu. Je n'interviendrai que si nécessité de la compléter.
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Bonsoir à vous deux,
cmarcotte, j'ai regardé ton lien, mais il s'agit surtout de Visual Studio, or je travaille essentiellement en VB6. Je sais, je suis un peu vieux jeu, mais à mon âge on peut peut-être me pardonner.
ucfoutu, la variable environ() renvoie le même OS sous WXP et sous W7, OS=Windows_NT.
Ce que je cherche à lire c'est la totalité (ou une grande partie de la clé :
HKLM\Software\Microsoft\Windows NT\CurrentVersion
puis les diverses sous-clés qui donnent la version de Windows, le service pack, etc.
tel qu'on les trouve dans RegEdit.
Si ça fonctionne sous XP, je ne comprends pas pourquoi ça ne fonctionne pas toujours sous W7, d'autant que si on les lit avec RegEdit, ce sont bien les mêmes sous-clés.
Je n'ai pas installé VB6 sous W7, je vais peut-être essayer de commencer par là et voir ce qui se passe en pas à pas dans le programme.
Sûr aussi que je peux le faire d'une manière peu orthodoxe avec la commande REG en invite de commandes :
REG QUERY HKLM\Software\Microsoft\Windows NT\CurrentVersion > toto, puis il me suffit de lire le fichier toto pour avoir toutes mes informations, mais cela ne répond pas à ma question, et ça manque d'élégance !


mcoppa

Bonjour,

Il y a un paquet de fonctions de l'API Win32 (32 bits) qui ne fonctionnent pas correctement avec les machines à 64 bits. Même que Microsoft qui avait dit avoir cessé le développement de VBA a dû revoir sa décision au moins partiellement pour adapter VBA aux plate-formes 64 bits. Fondamentalement que ce soit avec VB6 ou VB.net, il faut user de précautions avant d'utiliser l'API WIN32.

Si tu veux des articles qui se rapprochent de VB6, il y en a qui concernent VBA par là, ou par là, par là, par là, et par là. Je termine là, parce que là je suis tanné de chercher.
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Merci,

Il y a effectivement des choses très intéressantes et je pense que les fonctions VBA 32 bits sont très proches de VB6.
Je n'ai pas le temps aujourd'hui de faire les essais, mais la semaine prochaine, je vous tiendrai au courant.

mcoppa
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
220
Je ne comprends pas ton problème.
Environ$("PROCESSOR_ARCHITECTURE") te retourne déjà l'essentiel (x86 systeme 32 et AMD64 ,système 64 bits)
Environ$("OS") te retourne également ce qui convient "Windows_NT" si XP ou supérieur
N'est-ce pas suffisant ?

Une autre manière de procéder :
Insère donc le contrôle sysinfo et vois ce que t'affiche ceci :
MsgBox Environ("OS") & vbCrLf & SysInfo1.OSPlatform & vbCrLf & SysInfo1.OSVersion

Et jette un coup d'oeil ici pour "traduire" le N° de version
Tapez le texte de l'url ici.
Je ne vois vraiment pas ce dont tu aurais besoin de plus !

________________________
Réponse exacte ? => "REPONSE ACCEPTEE" facilitera les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement répéter son contenu. Je n'interviendrai que si nécessité de la compléter.
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
220
Car pour moi (me tromperais-je ?) :
Les seules informations nécessaires à la prise d'une décision éclairée sont :
-la technologie de base (NT, par exemple)
-la version qui l'utilise


________________________
Réponse exacte ? => "REPONSE ACCEPTEE" facilitera les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement répéter son contenu. Je n'interviendrai que si nécessité de la compléter.
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Bonjour,

Je suis chiant, c'est vrai. Mais savoir que je suis sous WNT 6,1 ne me dit pas si je suis sous Windows 7 ou sous Windows Server 2008, si je suis en édition familiale ou professionnelle, ni quel Service Pack est installé.
Mais en fait, je veux pouvoir lire tous les renseignements du registre pour la clé CurrentVersion.
Je vais regarder les fonctions comme pour le VBA. Je pense effectivement qu'il y a de fortes chances pour qu'il s'agisse d'un pointeur entre la version 32 et la version 64 bits.

mcoppa
Messages postés
40
Date d'inscription
jeudi 8 avril 2004
Statut
Membre
Dernière intervention
25 juillet 2014

Bonjour,

Pour ucfoutu,

Ce que tu dis est vrai, "les seules informations nécessaires à la prise d'une décision éclairée", mais ce qui m'intéresse avant tout c'est de pouvoir disposer de toutes les données de la base de registres quand je peux en avoir besoin, simplement en lisant les données du registre. Si le programme REG peut le faire, on doit être à même de le faire aussi.
J'ai fait des recherches sur les MAJ de WXP où une certaine MAJ (KB2724197) provoque une perte importante de mémoire sous MsDos, et on regagne de la mémoire en supprimant le Himem.sys (ce qui est somme toute assez paradoxal), ou en supprimant la MAJ.
Je n'ai pas encore trouvé dans le registre où ces informations étaient logées.
Il existe (ça va faire râler) encore pas mal d'applications qui fonctionnent sous MsDos et qui ne seront jamais réécrites parce que, ou ces programmes n'intéressent plus suffisamment de monde, ou parce qu'elles ont déjà été réécrites et la clientèle vieillissante n'a pas voulu migrer.
Enfin, la recherche et la connaissance système m’intéressent.
Merci quand même de t'être intéressé à mes questions.

mcoppa