Turpitudes de Windows 7

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

<requestedexecutionlevel level="requireadministrator" />


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

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

Cordialement,
RG

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

"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

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

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

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, ...)

"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, ...)

Merci beaucoup
RG

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

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.