Bonjour,
Il y a quelque temps j'avais posé une question concernant la création de
fichiers par programme sous un répertoire système par exemple Program Files
(x86) car je m'étonnais que le fichier ne se crée pas à l'endroit désiré
mais quelque part sous c:\utilisateur\.....\Program Files (x86). On m'avait
expliqué que c'était à cause de la virtualisation et qu'il suffisait de
lancer le même programme en mode administrateur pour que les fichiers soient
créés à l'endroit souhaité.
J'ai pris bonne note et c'est ce que j'ai fait, mais voilà ce qui se passe:
Je lance le programme en mode administrateur et effectivement les fichiers
sont créés aux endroits souhaités. Mais en fait le programme ne fait pas que
ça, il accède aussi aux registres de Windows (HKEY_LOCAL_MACHINE) pour s'y
inscrire et être automatiquement relancé lui même au redémarrage du système
et ça ça marche aussi j'accède bien et j'écris bien dans les registres
puisque je suis en mode administrateur. Et à la relance du système je
constate ce qui marche encore que mon programme a bien été relancé puisqu'il
se trouve dans le gestionnaire.
Mais on y arrive, ce même programme qui est lancé au démarrage du système
par la clé HKEY_LOCAL_MACHINE a oublié que son lancement manuel initial
avait été fait en mode administrateur et au lieu de continuer à écrire ou
consulter les fichiers à l'endroit où il les a initialement créés va les
écrire et les consulter à l'adresse virtuelle c:\utilisateurs\....
Y aurait-il un moyen simple de conserver les droits du mode administrateur
lorsqu'on les a déjà eus.
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Claude BELLAMY
Le samedi 25/06/2011 19:24:13, Roger a écrit dans le message <news:4e061916$0$20787$ ce qui suit :
[...] Mais on y arrive, ce même programme qui est lancé au démarrage du système par la clé HKEY_LOCAL_MACHINE a oublié que son lancement manuel initial avait été fait en mode administrateur et au lieu de continuer à écrire ou consulter les fichiers à l'endroit où il les a initialement créés va les écrire et les consulter à l'adresse virtuelle c:utilisateurs.... Y aurait-il un moyen simple de conserver les droits du mode administrateur lorsqu'on les a déjà eus.
Depuis l'explorateur, sélectionner l'exécutable. Clic droit onglet "Compatibilité" zone "Niveau de privilège" cocher la case "Exécuter ce programme en tant qu'administrateur"
Par ailleurs, pour qu'un exécutable requière systématiquement des privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou compilé avec) contenant l'instruction
Tu as aussi la solution de lancer le programme via la commande RUNAS ou encore avec mon logiciel utilitaire SUPEREXEC http://www.bellamyjc.org/fr/superexec.html" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://www.bellamyjc.org/fr/superexec.html
--
May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP Expert IT Pro] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Le samedi 25/06/2011 19:24:13, Roger a écrit dans le message
<news:4e061916$0$20787$426a34cc@news.free.fr> ce qui suit :
[...]
Mais on y arrive, ce même programme qui est lancé au démarrage du système par
la clé HKEY_LOCAL_MACHINE a oublié que son lancement manuel initial avait été
fait en mode administrateur et au lieu de continuer à écrire ou consulter les
fichiers à l'endroit où il les a initialement créés va les écrire et les
consulter à l'adresse virtuelle c:utilisateurs....
Y aurait-il un moyen simple de conserver les droits du mode administrateur
lorsqu'on les a déjà eus.
Depuis l'explorateur, sélectionner l'exécutable.
Clic droit
onglet "Compatibilité"
zone "Niveau de privilège"
cocher la case "Exécuter ce programme en tant qu'administrateur"
Par ailleurs, pour qu'un exécutable requière systématiquement des
privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou
compilé avec) contenant l'instruction
Tu as aussi la solution de lancer le programme via la commande RUNAS ou
encore avec mon logiciel utilitaire SUPEREXEC
http://www.bellamyjc.org/fr/superexec.html
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP Expert IT Pro]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Le samedi 25/06/2011 19:24:13, Roger a écrit dans le message <news:4e061916$0$20787$ ce qui suit :
[...] Mais on y arrive, ce même programme qui est lancé au démarrage du système par la clé HKEY_LOCAL_MACHINE a oublié que son lancement manuel initial avait été fait en mode administrateur et au lieu de continuer à écrire ou consulter les fichiers à l'endroit où il les a initialement créés va les écrire et les consulter à l'adresse virtuelle c:utilisateurs.... Y aurait-il un moyen simple de conserver les droits du mode administrateur lorsqu'on les a déjà eus.
Depuis l'explorateur, sélectionner l'exécutable. Clic droit onglet "Compatibilité" zone "Niveau de privilège" cocher la case "Exécuter ce programme en tant qu'administrateur"
Par ailleurs, pour qu'un exécutable requière systématiquement des privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou compilé avec) contenant l'instruction
Tu as aussi la solution de lancer le programme via la commande RUNAS ou encore avec mon logiciel utilitaire SUPEREXEC http://www.bellamyjc.org/fr/superexec.html" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://www.bellamyjc.org/fr/superexec.html
--
May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP Expert IT Pro] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Roger
Depuis l'explorateur, sélectionner l'exécutable. Clic droit onglet "Compatibilité" zone "Niveau de privilège" cocher la case "Exécuter ce programme en tant qu'administrateur"
Merci pour la réponse, mais si tu regardes bien mon message initial, c'est ce que j'ai fait faire à l'utilisateur lors du premier lancement de l'appli et j'avais bien constaté que l'application gardait ses droits administrateur tant qu'elle était active. Cependant quand l'utilisateur arrête son micro puis le relance plus tard, ça n'est plus l'utilisateur qui relance l'application (donc pas question de lui faire faire clic droit) c'est directement Windows qui relance l'appli du fait de son inscription dans HKEY_LOCAL_MACHINE lors du 1er lancement. Et c'est là que je constate que le lancement de l'appli par windows lui fait perdre ses droits.
Par ailleurs, pour qu'un exécutable requière systématiquement des privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou compilé avec) contenant l'instruction <requestedexecutionlevel level="requireadministrator" />
C'était bien ça ma question, il faut que j'aille donc voir côté fichier maifest, mais, a priori, je ne vois pas comment compiler un programme avec un autre fichier que .cpp ou alors s'agit-il de le linker avec ce type de fichier ?
Ok, mais cette dernière solution résout-elle le problème du lancement du programme par Windows ou bien est-elle seulement équivalente à un lancement en mode administrateur par clic droit ? Merci
Cordialement, RG
Depuis l'explorateur, sélectionner l'exécutable.
Clic droit
onglet "Compatibilité"
zone "Niveau de privilège"
cocher la case "Exécuter ce programme en tant qu'administrateur"
Merci pour la réponse, mais si tu regardes bien mon message initial, c'est
ce que j'ai fait faire à l'utilisateur lors du premier lancement de l'appli
et j'avais bien constaté que l'application gardait ses droits administrateur
tant qu'elle était active. Cependant quand l'utilisateur arrête son micro
puis le relance plus tard, ça n'est plus l'utilisateur qui relance
l'application (donc pas question de lui faire faire clic droit) c'est
directement Windows qui relance l'appli du fait de son inscription dans
HKEY_LOCAL_MACHINE lors du 1er lancement. Et c'est là que je constate que le
lancement de l'appli par windows lui fait perdre ses droits.
Par ailleurs, pour qu'un exécutable requière systématiquement des
privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou
compilé avec) contenant l'instruction
<requestedexecutionlevel level="requireadministrator" />
C'était bien ça ma question, il faut que j'aille donc voir côté fichier
maifest, mais, a priori, je ne vois pas comment compiler un programme avec
un autre fichier que .cpp ou alors s'agit-il de le linker avec ce type de
fichier ?
Tu as aussi la solution de lancer le programme via la commande RUNAS ou
encore avec mon logiciel utilitaire SUPEREXEC
http://www.bellamyjc.org/fr/superexec.html
Ok, mais cette dernière solution résout-elle le problème du lancement du
programme par Windows ou bien est-elle seulement équivalente à un lancement
en mode administrateur par clic droit ?
Merci
Depuis l'explorateur, sélectionner l'exécutable. Clic droit onglet "Compatibilité" zone "Niveau de privilège" cocher la case "Exécuter ce programme en tant qu'administrateur"
Merci pour la réponse, mais si tu regardes bien mon message initial, c'est ce que j'ai fait faire à l'utilisateur lors du premier lancement de l'appli et j'avais bien constaté que l'application gardait ses droits administrateur tant qu'elle était active. Cependant quand l'utilisateur arrête son micro puis le relance plus tard, ça n'est plus l'utilisateur qui relance l'application (donc pas question de lui faire faire clic droit) c'est directement Windows qui relance l'appli du fait de son inscription dans HKEY_LOCAL_MACHINE lors du 1er lancement. Et c'est là que je constate que le lancement de l'appli par windows lui fait perdre ses droits.
Par ailleurs, pour qu'un exécutable requière systématiquement des privilèges admin, il faut qu'il ait été doté d'un fichier manifest (ou compilé avec) contenant l'instruction <requestedexecutionlevel level="requireadministrator" />
C'était bien ça ma question, il faut que j'aille donc voir côté fichier maifest, mais, a priori, je ne vois pas comment compiler un programme avec un autre fichier que .cpp ou alors s'agit-il de le linker avec ce type de fichier ?
Ok, mais cette dernière solution résout-elle le problème du lancement du programme par Windows ou bien est-elle seulement équivalente à un lancement en mode administrateur par clic droit ? Merci
Cordialement, RG
Roger
Re-bonjour En regardant ton site ainsi que celui de msn, j'ai fait ceci: Création du fichier manifest.xml ci-dessous: //******************************************************* <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.1.1.1" processorArchitecture="X86" name="mxj.exe" type="win32" /> <description>elevate execution level</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly> //******************************************************** Création d'un fichier manifest.rc ci-dessous: //******************************************************** #include <windows.h> #ifndef CREATEPROCESS_MANIFEST_RESOURCE_ID #define CREATEPROCESS_MANIFEST_RESOURCE_ID 1 #endif #ifndef RT_MANIFEST #define RT_MANIFEST 24 #endif CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml" //********************************************************** Compilé mon appli mxj.cpp avec Borland bcc32.exe Compilé mon appli manifest.rc avec Borland brc32.exe Linké mxj.obj et manifest.res avec Borland ilink32.exe Aucune erreur de compile, aucune erreur de linkage. J'ai ensuite lancé mon appli mxj.exe, elle s'exécute normalement sans aucune différence avec avant, faut dire que je suis sous Windows XP version familiale et que je n'ai pas besoin de privilèges car je n'ai pas de virtualisation et j'avais déjà accès sans protection particulière aux registres. Je vérifiais seulement que mon appli avec maintenant le fichier manifest intégré marchait toujours. Maintenant deux questions: 1.- Mon fichier manifest est-il correct, car comme je n'ai fait que recopier à droite à gauche je n'ai aucune idée si ma syntaxe est correcte et si elle sera efficace ? (je n'ai par exemple aucune idée de la validité des références placées derrière les paramètres xmlns ou version) 2.- Si j'exporte mon mxj.exe sur un ordi en windows 7 est-ce qu'il fonctionnera avec le privilège administrateur par simple lancement par double-clic (pas de clic droit) et sans avoir besoin de le recompiler sur cet ordi en windows ? (pour info mon appli mxj.exe fonctionnait déjà sous windows 7 avant d'intégrer le fichier manifest mais à condition de le lancer par clic droit et privilèges administrateur). Merci
Re-bonjour
En regardant ton site ainsi que celui de msn, j'ai fait ceci:
Création du fichier manifest.xml ci-dessous:
//*******************************************************
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.1.1.1" processorArchitecture="X86"
name="mxj.exe" type="win32" />
<description>elevate execution level</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
//********************************************************
Création d'un fichier manifest.rc ci-dessous:
//********************************************************
#include <windows.h>
#ifndef CREATEPROCESS_MANIFEST_RESOURCE_ID
#define CREATEPROCESS_MANIFEST_RESOURCE_ID 1
#endif
#ifndef RT_MANIFEST
#define RT_MANIFEST 24
#endif
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml"
//**********************************************************
Compilé mon appli mxj.cpp avec Borland bcc32.exe
Compilé mon appli manifest.rc avec Borland brc32.exe
Linké mxj.obj et manifest.res avec Borland ilink32.exe
Aucune erreur de compile, aucune erreur de linkage.
J'ai ensuite lancé mon appli mxj.exe, elle s'exécute normalement sans aucune
différence
avec avant, faut dire que je suis sous Windows XP version familiale et que
je n'ai pas
besoin de privilèges car je n'ai pas de virtualisation et j'avais déjà accès
sans protection particulière aux registres. Je vérifiais seulement que mon
appli avec maintenant le fichier
manifest intégré marchait toujours.
Maintenant deux questions:
1.- Mon fichier manifest est-il correct, car comme je n'ai fait que recopier
à droite à gauche
je n'ai aucune idée si ma syntaxe est correcte et si elle sera efficace ?
(je n'ai par exemple aucune idée de la validité des références placées
derrière les paramètres xmlns ou version)
2.- Si j'exporte mon mxj.exe sur un ordi en windows 7 est-ce qu'il
fonctionnera avec le privilège administrateur par simple lancement par
double-clic (pas de clic droit) et
sans avoir besoin de le recompiler sur cet ordi en windows ? (pour info mon
appli mxj.exe fonctionnait déjà sous windows 7 avant d'intégrer le fichier
manifest mais à condition de le
lancer par clic droit et privilèges administrateur).
Merci
Re-bonjour En regardant ton site ainsi que celui de msn, j'ai fait ceci: Création du fichier manifest.xml ci-dessous: //******************************************************* <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.1.1.1" processorArchitecture="X86" name="mxj.exe" type="win32" /> <description>elevate execution level</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly> //******************************************************** Création d'un fichier manifest.rc ci-dessous: //******************************************************** #include <windows.h> #ifndef CREATEPROCESS_MANIFEST_RESOURCE_ID #define CREATEPROCESS_MANIFEST_RESOURCE_ID 1 #endif #ifndef RT_MANIFEST #define RT_MANIFEST 24 #endif CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml" //********************************************************** Compilé mon appli mxj.cpp avec Borland bcc32.exe Compilé mon appli manifest.rc avec Borland brc32.exe Linké mxj.obj et manifest.res avec Borland ilink32.exe Aucune erreur de compile, aucune erreur de linkage. J'ai ensuite lancé mon appli mxj.exe, elle s'exécute normalement sans aucune différence avec avant, faut dire que je suis sous Windows XP version familiale et que je n'ai pas besoin de privilèges car je n'ai pas de virtualisation et j'avais déjà accès sans protection particulière aux registres. Je vérifiais seulement que mon appli avec maintenant le fichier manifest intégré marchait toujours. Maintenant deux questions: 1.- Mon fichier manifest est-il correct, car comme je n'ai fait que recopier à droite à gauche je n'ai aucune idée si ma syntaxe est correcte et si elle sera efficace ? (je n'ai par exemple aucune idée de la validité des références placées derrière les paramètres xmlns ou version) 2.- Si j'exporte mon mxj.exe sur un ordi en windows 7 est-ce qu'il fonctionnera avec le privilège administrateur par simple lancement par double-clic (pas de clic droit) et sans avoir besoin de le recompiler sur cet ordi en windows ? (pour info mon appli mxj.exe fonctionnait déjà sous windows 7 avant d'intégrer le fichier manifest mais à condition de le lancer par clic droit et privilèges administrateur). Merci
Laurent
"Roger" a écrit dans le message de news: 4e073c1f$0$19695$
Re-bonjour
1.- Mon fichier manifest est-il correct, car comme je n'ai fait que recopier à droite à gauche
"Roger" <roger.girardon@wanadoo.fr> a écrit dans le message de news:
4e073c1f$0$19695$426a34cc@news.free.fr...
Re-bonjour
1.- Mon fichier manifest est-il correct, car comme je n'ai fait que
recopier à droite à gauche
Si tu as suivi les exemple de MSDN comme
http://msdn.microsoft.com/en-us/library/bb756929.aspx
ça devrait le faire
tu peux déjà verifier s'il est bien en ressources avec des outils comme
resouce hacker
J'ai suivi les exemples, mais je posais la question car justement ce ne sont que des exemples, je me demandais s'il y avait des adaptations particulières à faire en fonction des configurations locales.
tu peux déjà verifier s'il est bien en ressources avec des outils comme resouce hacker
Je n'ai pas recherché hacker, mais je me suis fait un petit programme qui va rechercher ce qu'on veut (en ascii ou en hexa) dans n'importe quel fichier et qui affiche sur l'écran (en ascii + hexa) le contenu du buffer où se trouve ce qu'on cherche, j'ai pu ainsi vérifier que le contenu du fichier .xml se trouve dans mon .exe.
Si je posais la question c'est que l'ordi en windows 7 ne se trouve pas chez moi (donc je ne peux pas tester) et je préférais avoir un avis d'expert avant d'envoyer l'appli (le .exe) à l'intéressé.
Merci
1.- Mon fichier manifest est-il correct, car comme je n'ai fait que
recopier à droite à gauche
Si tu as suivi les exemple de MSDN comme
http://msdn.microsoft.com/en-us/library/bb756929.aspx
ça devrait le faire
J'ai suivi les exemples, mais je posais la question car justement ce ne sont
que des exemples, je me demandais s'il y avait des adaptations particulières
à faire en fonction des configurations locales.
tu peux déjà verifier s'il est bien en ressources avec des outils comme
resouce hacker
Je n'ai pas recherché hacker, mais je me suis fait un petit programme qui va
rechercher ce qu'on veut (en ascii ou en hexa) dans n'importe quel fichier
et qui affiche sur l'écran (en ascii + hexa) le contenu du buffer où se
trouve ce qu'on cherche, j'ai pu ainsi vérifier que le contenu du fichier
.xml se trouve dans mon .exe.
Si je posais la question c'est que l'ordi en windows 7 ne se trouve pas chez
moi (donc je ne peux pas tester) et je préférais avoir un avis d'expert
avant d'envoyer l'appli (le .exe) à l'intéressé.
J'ai suivi les exemples, mais je posais la question car justement ce ne sont que des exemples, je me demandais s'il y avait des adaptations particulières à faire en fonction des configurations locales.
tu peux déjà verifier s'il est bien en ressources avec des outils comme resouce hacker
Je n'ai pas recherché hacker, mais je me suis fait un petit programme qui va rechercher ce qu'on veut (en ascii ou en hexa) dans n'importe quel fichier et qui affiche sur l'écran (en ascii + hexa) le contenu du buffer où se trouve ce qu'on cherche, j'ai pu ainsi vérifier que le contenu du fichier .xml se trouve dans mon .exe.
Si je posais la question c'est que l'ordi en windows 7 ne se trouve pas chez moi (donc je ne peux pas tester) et je préférais avoir un avis d'expert avant d'envoyer l'appli (le .exe) à l'intéressé.
Merci
Roger
Re-bonjour J'ai quand même quelques inquiétudes sur cette façon de procéder: mon fichier manifest est peut-être correct, ainsi que ma façon de le compiler avec le .rc. Mais il y a quand même un truc qui ne me paraît pas clair : J'ai bien une référence au fichier manifest dans le .rc: CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml" (1 24 "manifest.xml") Je linke ensuite le .res (issu du .rc) avec le .obj (issu du .cpp) tout se passe bien, mais dans le .cpp je ne fais jamais référence au .rc. J'ai bien vérifié que le contenu du fichier manifest se trouve dans mon .exe, mais je ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il n'y a pas de référence sur le .rc)? Ne faut-il pas rajouter quelque chose dans le .cpp ? Merci
Re-bonjour
J'ai quand même quelques inquiétudes sur cette façon de procéder:
mon fichier manifest est peut-être correct, ainsi que ma façon de le
compiler avec le .rc. Mais il y a quand même un truc qui ne me paraît pas
clair :
J'ai bien une référence au fichier manifest dans le .rc:
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml"
(1 24 "manifest.xml")
Je linke ensuite le .res (issu du .rc) avec le .obj (issu du .cpp) tout se
passe bien, mais dans le .cpp je ne fais jamais référence au .rc. J'ai bien
vérifié que le contenu du fichier manifest se trouve dans mon .exe, mais je
ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il
dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il
n'y a pas de référence sur le .rc)?
Ne faut-il pas rajouter quelque chose dans le .cpp ?
Merci
Re-bonjour J'ai quand même quelques inquiétudes sur cette façon de procéder: mon fichier manifest est peut-être correct, ainsi que ma façon de le compiler avec le .rc. Mais il y a quand même un truc qui ne me paraît pas clair : J'ai bien une référence au fichier manifest dans le .rc: CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml" (1 24 "manifest.xml") Je linke ensuite le .res (issu du .rc) avec le .obj (issu du .cpp) tout se passe bien, mais dans le .cpp je ne fais jamais référence au .rc. J'ai bien vérifié que le contenu du fichier manifest se trouve dans mon .exe, mais je ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il n'y a pas de référence sur le .rc)? Ne faut-il pas rajouter quelque chose dans le .cpp ? Merci
Christian ASTOR
Roger a écrit :
mais je ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il n'y a pas de référence sur le .rc)?
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de l'exe (le PE), notamment dans la structure PS_CREATE_INFO (DetectManifest, ManifestDetected, ManifestAddress, ...)
Roger a écrit :
mais je ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il
dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il
n'y a pas de référence sur le .rc)?
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de
l'exe (le PE), notamment dans la structure PS_CREATE_INFO
(DetectManifest, ManifestDetected, ManifestAddress, ...)
mais je ne vois pas comment le .exe s'y retrouve, comment est-il au courant qu'il dispose d'un fichier manifest dans son propre code (vu que dans le .cpp il n'y a pas de référence sur le .rc)?
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de l'exe (le PE), notamment dans la structure PS_CREATE_INFO (DetectManifest, ManifestDetected, ManifestAddress, ...)
Roger
"Christian ASTOR" a écrit dans le message de news: >
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de l'exe (le PE), notamment dans la structure PS_CREATE_INFO (DetectManifest, ManifestDetected, ManifestAddress, ...)
Merci beaucoup RG
"Christian ASTOR" <castorix@club-internet.fr> a écrit dans le message de
news: >
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de l'exe
(le PE), notamment dans la structure PS_CREATE_INFO (DetectManifest,
ManifestDetected, ManifestAddress, ...)
"Christian ASTOR" a écrit dans le message de news: >
C'est l'OS qui s'en occupe, en détectant sa présence dans l'image de l'exe (le PE), notamment dans la structure PS_CREATE_INFO (DetectManifest, ManifestDetected, ManifestAddress, ...)
Merci beaucoup RG
Roger
Bonjour, Je viens d'avoir le retour des essais que la personne qui a le micro sous Windows7 a fait avec le .exe compilé chez moi sous XP avec inclusion du fichier manifest. Résultat: Presque tout marche: pas de question posée à l'utilisateur lorsqu'il lance le .exe par simple double clic, pourtant le .exe va modifier les registres de windows en particulier pour s'y mettre lui dans les registres afin d'être automatiquement relancé à chaque redémarrage du micro. Pas de question non plus posée à l'utilisateur quand le programme est ensuite lancé automatiquement par windows à la relance du micro. Si on s'arrêtait là tout serait parfait. Seul petit hic, après une relance auto par windows, il y a un moment où le .exe va modifier un fichier qui se trouve sous c:/program files (x86)/ (adresse réelle, pas virtuelle) et là windows sort le message: "Voulez-vous autoriser le programme provenant d'un éditeur inconnu à apporter des modifications à cet ordinateur" en donnant le nom du programme ainsi que le nom du fichier. Avant la relance du micro le .exe avait aussi modifié ce même fichier et là windows n'avait pas posé de question ! En conclusion, lors du lancement manuel par double-clic du .exe, le fait qu'il y ait un fichier manifest est doublement efficace car pas d'avertissement quand le programme modifie les registres et pas d'avertissement non plus quand le programme modifie le fichier qui est sous program files (adresse réelle). Par contre lors du lancement auto du .exe par windows à la relance du micro, le fait qu'il y ait un fichier manifest est en partie efficace puisque le .exe va encore chercher le fichier à modifier sous l'adresse réelle program files (et non pas sous l'adresse virtuelle), mais là le fichier manifest n'est qu'à moitié efficace puisque windows sort un message d'avertissement. Je ne sais pas si on peut contourner ce message tout en laissant le fichier modifié au même endroit, sinon, je pense qu'on doit pouvoir l'éviter en mettant le fichier sous c:/utilisateurs/....
Bonjour,
Je viens d'avoir le retour des essais que la personne qui a le micro sous
Windows7 a fait avec le .exe compilé chez moi sous XP avec inclusion du
fichier manifest.
Résultat: Presque tout marche: pas de question posée à l'utilisateur
lorsqu'il lance le .exe par simple double clic, pourtant le .exe va modifier
les registres de windows en particulier pour s'y mettre lui dans les
registres afin d'être automatiquement relancé à chaque redémarrage du micro.
Pas de question non plus posée à l'utilisateur quand le programme est
ensuite lancé automatiquement par windows à la relance du micro.
Si on s'arrêtait là tout serait parfait.
Seul petit hic, après une relance auto par windows, il y a un moment où le
.exe va modifier un fichier qui se trouve sous c:/program files (x86)/
(adresse réelle, pas virtuelle) et là windows sort le message: "Voulez-vous
autoriser le programme provenant d'un éditeur inconnu à apporter des
modifications à cet ordinateur" en donnant le nom du programme ainsi que le
nom du fichier. Avant la relance du micro le .exe avait aussi modifié ce
même fichier et là windows n'avait pas posé de question !
En conclusion, lors du lancement manuel par double-clic du .exe, le fait
qu'il y ait un fichier manifest est doublement efficace car pas
d'avertissement quand le programme modifie les registres et pas
d'avertissement non plus quand le programme modifie le fichier qui est sous
program files (adresse réelle).
Par contre lors du lancement auto du .exe par windows à la relance du micro,
le fait qu'il y ait un fichier manifest est en partie efficace puisque le
.exe va encore chercher le fichier à modifier sous l'adresse réelle program
files (et non pas sous l'adresse virtuelle), mais là le fichier manifest
n'est qu'à moitié efficace puisque windows sort un message d'avertissement.
Je ne sais pas si on peut contourner ce message tout en laissant le fichier
modifié au même endroit, sinon, je pense qu'on doit pouvoir l'éviter en
mettant le fichier sous c:/utilisateurs/....
Bonjour, Je viens d'avoir le retour des essais que la personne qui a le micro sous Windows7 a fait avec le .exe compilé chez moi sous XP avec inclusion du fichier manifest. Résultat: Presque tout marche: pas de question posée à l'utilisateur lorsqu'il lance le .exe par simple double clic, pourtant le .exe va modifier les registres de windows en particulier pour s'y mettre lui dans les registres afin d'être automatiquement relancé à chaque redémarrage du micro. Pas de question non plus posée à l'utilisateur quand le programme est ensuite lancé automatiquement par windows à la relance du micro. Si on s'arrêtait là tout serait parfait. Seul petit hic, après une relance auto par windows, il y a un moment où le .exe va modifier un fichier qui se trouve sous c:/program files (x86)/ (adresse réelle, pas virtuelle) et là windows sort le message: "Voulez-vous autoriser le programme provenant d'un éditeur inconnu à apporter des modifications à cet ordinateur" en donnant le nom du programme ainsi que le nom du fichier. Avant la relance du micro le .exe avait aussi modifié ce même fichier et là windows n'avait pas posé de question ! En conclusion, lors du lancement manuel par double-clic du .exe, le fait qu'il y ait un fichier manifest est doublement efficace car pas d'avertissement quand le programme modifie les registres et pas d'avertissement non plus quand le programme modifie le fichier qui est sous program files (adresse réelle). Par contre lors du lancement auto du .exe par windows à la relance du micro, le fait qu'il y ait un fichier manifest est en partie efficace puisque le .exe va encore chercher le fichier à modifier sous l'adresse réelle program files (et non pas sous l'adresse virtuelle), mais là le fichier manifest n'est qu'à moitié efficace puisque windows sort un message d'avertissement. Je ne sais pas si on peut contourner ce message tout en laissant le fichier modifié au même endroit, sinon, je pense qu'on doit pouvoir l'éviter en mettant le fichier sous c:/utilisateurs/....
Roger
Bon je résume sous windows 7, Petit rappel d'abord: j'ai un programme qui crée et écrit dans des fichiers et qui en outre (c'est important) va s'inscrire dans les registres pour être relancé automatiquement par windows lors du démarrage de windows. une fois ce petit rappel fait quelles sont les solutions que j'ai essayées:
A.- programme simple (sans fichier manifest) => 2 inconvénients: 1.- l'utilisateur lors de la première exécution du programme est obligé de faire un clic droit et de le lancer en tant qu'administrateur (sinon pas d'accès aux registres) 2.- le programme lors de son lancement initial (avec les privilèges) crée et écrit les fichiers dans des adresses réelles, mais dès la première relance du micro comme il n'a plus les droits il continue dans les adresses virtuelles.
B.- programme avec fichier manifest (donc avec privilèges) Pas de problème pour son lancement: simple double-clic, pas de problème pour l'accès aux registres, le programme crée et écrit les fichiers dans des adresses réelles 1 inconvénient très gênant: à la relance du micro et justement parce le programme a gardé les privilèges et veut écrire dans des fichiers en adresses réelles windows sort avant la première écriture le message suivant: "Voulez-vous autoriser le programme provenant d'un éditeur inconnu à apporter des modifications à cet ordinateur"
En conclusion, aucune des deux solutions n'est satisfaisante car elle réclament toutes deux à un moment quelconque une intervention spécifique de l'utilisateur: - soit le clic droit dans le cas A - soit la réponse OK au message de windows dans le cas B
S'il existe une solution officielle pour contourner ces deux inconvénients je suis preneur, je rajouterai que j'ai quand même réussi à les contourner, mais ma solution est tellement tordue que je n'ose pas l'exposer ici.
Bon je résume sous windows 7,
Petit rappel d'abord: j'ai un programme qui crée et écrit dans des fichiers
et qui en outre (c'est important) va s'inscrire dans les registres pour être
relancé automatiquement par windows lors du démarrage de windows.
une fois ce petit rappel fait quelles sont les solutions que j'ai essayées:
A.- programme simple (sans fichier manifest) => 2 inconvénients:
1.- l'utilisateur lors de la première exécution du programme est obligé de
faire un clic droit et de le lancer en tant qu'administrateur (sinon pas
d'accès aux registres)
2.- le programme lors de son lancement initial (avec les privilèges) crée et
écrit les fichiers dans des adresses réelles, mais dès la première relance
du micro comme il n'a plus les droits il continue dans les adresses
virtuelles.
B.- programme avec fichier manifest (donc avec privilèges)
Pas de problème pour son lancement: simple double-clic, pas de problème pour
l'accès aux registres, le programme crée et écrit les fichiers dans des
adresses réelles
1 inconvénient très gênant: à la relance du micro et justement parce le
programme a gardé les privilèges et veut écrire dans des fichiers en
adresses réelles windows sort avant la première écriture le message suivant:
"Voulez-vous autoriser le programme provenant d'un éditeur inconnu à
apporter des modifications à cet ordinateur"
En conclusion, aucune des deux solutions n'est satisfaisante car elle
réclament toutes deux à un moment quelconque une intervention spécifique de
l'utilisateur:
- soit le clic droit dans le cas A
- soit la réponse OK au message de windows dans le cas B
S'il existe une solution officielle pour contourner ces deux inconvénients
je suis preneur, je rajouterai que j'ai quand même réussi à les contourner,
mais ma solution est tellement tordue que je n'ose pas l'exposer ici.
Bon je résume sous windows 7, Petit rappel d'abord: j'ai un programme qui crée et écrit dans des fichiers et qui en outre (c'est important) va s'inscrire dans les registres pour être relancé automatiquement par windows lors du démarrage de windows. une fois ce petit rappel fait quelles sont les solutions que j'ai essayées:
A.- programme simple (sans fichier manifest) => 2 inconvénients: 1.- l'utilisateur lors de la première exécution du programme est obligé de faire un clic droit et de le lancer en tant qu'administrateur (sinon pas d'accès aux registres) 2.- le programme lors de son lancement initial (avec les privilèges) crée et écrit les fichiers dans des adresses réelles, mais dès la première relance du micro comme il n'a plus les droits il continue dans les adresses virtuelles.
B.- programme avec fichier manifest (donc avec privilèges) Pas de problème pour son lancement: simple double-clic, pas de problème pour l'accès aux registres, le programme crée et écrit les fichiers dans des adresses réelles 1 inconvénient très gênant: à la relance du micro et justement parce le programme a gardé les privilèges et veut écrire dans des fichiers en adresses réelles windows sort avant la première écriture le message suivant: "Voulez-vous autoriser le programme provenant d'un éditeur inconnu à apporter des modifications à cet ordinateur"
En conclusion, aucune des deux solutions n'est satisfaisante car elle réclament toutes deux à un moment quelconque une intervention spécifique de l'utilisateur: - soit le clic droit dans le cas A - soit la réponse OK au message de windows dans le cas B
S'il existe une solution officielle pour contourner ces deux inconvénients je suis preneur, je rajouterai que j'ai quand même réussi à les contourner, mais ma solution est tellement tordue que je n'ose pas l'exposer ici.