Lecture du registre

cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014 - 6 déc. 2012 à 10:28
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014 - 7 déc. 2012 à 13:24
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

lolokun Messages postés 1241 Date d'inscription mardi 10 octobre 2006 Statut Membre Dernière intervention 27 août 2013 7
6 déc. 2012 à 11:15
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..
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
6 déc. 2012 à 11:33
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
0
Utilisateur anonyme
6 déc. 2012 à 12:33
"CSDVersion" renvoie une erreur 2

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

_____________
Kenji
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
6 déc. 2012 à 14:05
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
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Utilisateur anonyme
6 déc. 2012 à 17:58
Bonjour,

Commence par là
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
6 déc. 2012 à 18:26
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.
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
6 déc. 2012 à 18:30
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.
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
6 déc. 2012 à 19:09
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
0
Utilisateur anonyme
7 déc. 2012 à 02:59
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.
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
7 déc. 2012 à 09:50
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
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
7 déc. 2012 à 09:59
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.
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
7 déc. 2012 à 10:06
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.
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
7 déc. 2012 à 10:38
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
0
cs_mcoppa Messages postés 40 Date d'inscription jeudi 8 avril 2004 Statut Membre Dernière intervention 25 juillet 2014
7 déc. 2012 à 13:24
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
0
Rejoignez-nous