IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Discussion :

Turpitudes de Windows 7


Sujet :

Windows

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Turpitudes de Windows 7
    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

  2. #2
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 609
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 609
    Points : 188 580
    Points
    188 580
    Par défaut
    Citation Envoyé par Athur Voir le message
    Y aurait-il un moyen simple de conserver les droits du mode administrateur lorsqu'on les a déjà eus.
    Tu les conserves tant que l'application est lancée. Après, pour les demander à chaque fois, il faut regarder du côté du fichier des fichiers Manifest.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Suite
    Merci pour la réponse,
    Ca j'avais constaté que les droits été conservés tant que le l'application était active. Par contre quand l'utilisateur arrête son micro et le relance un peu plus tard, ça n'est plus l'utilisateur qui relance l'appli (plus question de faire clic droit...) c'est directement Windows, ce qui équivaut à une relance simple (donc sans clic droit...). Il faut donc que j'aille voir côté fichier Manifeste, mais je ne vois pas, a priori, comment se compile un programme avec un fichier manifeste.
    Merci

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Manifest
    Re-bonjour
    En regardant le site de msn et quelques questions déjà posées, j'ai fait ceci:
    Création du fichier manifest.xml ci-dessous:
    //*******************************************************
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    <?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:
    //********************************************************
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    #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 deux 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 7 ? (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

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Suite
    Pas de réponse, 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 dans cette façon de procéder:
    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.

  6. #6
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Je ne pense pas que le cpp ait besoin d'une référence au manifest, ce n'est pas une ressource qu'il utilise directement.

    C'est en fait une ressource qui est utiliser par le système d'exploitation au chargement de l’exécutable. Le compilateur doit faire normalement le nécessaire pour que Windows soit capable de trouver le manifest dans l’exécutable.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Manifest
    Merci pour la réponse.
    On va bien voir, j'ai envoyé le .exe à la personne qui doit faire le test chez elle sous Windows 7. Si la relation avec le manifest se fait à la compile ou au linkage le petit souci c'est que compile et linkage ont été faits chez moi (sous windows XP) alors que le .exe sera exécuté ailleurs sous Windows 7. J'espère que sous XP, Windows savait déjà quoi faire d'un manifest. J'attends que le destinataire du .exe se décide à faire le test...

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Résultat des essais
    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/....

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Conclusion
    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.

  10. #10
    Rédacteur/Modérateur
    Avatar de Andnotor
    Inscrit en
    Septembre 2008
    Messages
    5 671
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5 671
    Points : 13 065
    Points
    13 065
    Par défaut
    Si ton application doit systématiquement aller écrire dans des emplacements protégés, c'est qu'elle est mal conçue et avant d'aller trop loin, il faudrait revoir son architecture

    Même avec un manifest spécifiant requireAdministrator, l'utilisateur devrait être averti et confirmer l'élévation. S'il ne l'est pas, c'est qu'il a désactivé l'UAC !
    Demande à ton "Testeur" de refaire des tests en utilisant un compte utilisateur standard (ce que tu devrais aussi faire sous XP ) et en activant l'UAC. Tu seras certainement déçu des résultats.

    Le message "éditeur inconnu" se résout en signant numériquement l'application. A noter que certains antivirus se basent aussi sur l'absence de signature pour exécuter le programme dans un Sandbox.

    A part utiliser le compte System pour démarrer une application dans le contexte de l'utilisateur, je ne vois pas comment tu pourrais faire sans que l'utilisateur n'ait la moindre action à effectuer

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Réponse
    Je me suis peut-être mal exprimé, le privilège administrateur qui est demandé ça n'est pas pour écrire dans des emplacements protégés, c'est uniquement pour pouvoir créer une sous-clé dans les registres pour que le programme soit relancé par windows à chaque redémarrage du micro!!! Mais il se trouve que le fait d'avoir ou non demandé les privilèges a indirectement une conséquence sur l'endroit où le programme va créer et modifier ses fichiers (adresses réelles ou virtuelles, que je le veuille ou non). Qu'il écrive dans des adresses protégées ou virtuelles, je m'en fou, le principal c'est qu'il écrive toujours au même endroit !!!
    je ne demandais pas spécialement à écrire dans des emplacements protégés. Je voulais simplement que l'utilisateur n'ait pas de manip particulières à faire, peu importe si les fichiers sont créés sur des emplacements protégés ou non protégés.
    Or comme je crois l'avoir expliqué, si mon programme est sans fichier manifest donc sans privilèges, il ne peut pas s'inscrire dans les registres => manip obligatoire de l'utilisateur pour faire clic droit + comme l'utilisateur a demandé les privilèges le programme va systématiquement écrire dans les emplacements protégés (même si je ne le demande pas) + quand il relance le micro le programme a perdu ses droits donc il n'écrit plus dans les emplacements protégés mais dans les emplacements virtuels (donc plus au même endroit!!).
    Et si je mets le fichier manifest pour que l'utilisateur n'ait pas à faire le clic droit pour accéder aux registres, là le programme garde toujours ses droits, il écrit toujours au même endroit (emplacements protégés, mais je ne l'ai pas demandé) et c'est à la relance du micrro que windows sort le message: "éditeur inconnu....etc.." => encore une intervention de l'utilisateur !!
    Donc je répète dans les deux cas ça n'est pas satisfaisant!!
    Bon je disais que je m'en étais quand même sorti par un biais tordu, mais la résolution par signature numérique pourrait m'intéresser si ce n'est pas une usine à gaz, où peut-on STP trouver la façon de procéder. Merci

  12. #12
    Rédacteur/Modérateur
    Avatar de Andnotor
    Inscrit en
    Septembre 2008
    Messages
    5 671
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5 671
    Points : 13 065
    Points
    13 065
    Par défaut
    Citation Envoyé par Athur Voir le message
    Je me suis peut-être mal exprimé, le privilège administrateur qui est demandé ça n'est pas pour écrire dans des emplacements protégés, c'est uniquement pour pouvoir créer une sous-clé dans les registres pour que le programme soit relancé par windows à chaque redémarrage du micro!!!
    Et HKEY_LOCAL_MACHINE se situe où selon toi

    Je crois que tu mélanges tout !

    S'il n'y a pas de manifest ou qu'il ne contient pas l'information requestedExecutionLevel, il y a virtualisation.
    Si requestedExecutionLevel est défini, il n'y a pas de virtualisation. Qu'il soit défini sur AsInvoker ou requireAdministrator.

    A moins que cette clé soit définie sur AsInvoker, il y aura toujours une confirmation demandée à l'utilisateur (pour autant que l'UAC soit activé)

    De plus définir requireAdministrator alors que l'application est exécutée par un utilisateur standard ne va pas lui donner un Full-Access. Il demande un niveau d'accès, mais s'il n'a de toute façon pas les droits (n'est pas admin), ton appli va se planter lamentablement. Sous XP la même chose. tu auras juste droit à un access denied.

    Je te le dis: Il faut revoir ta copie. Par exemple prévoir un installer qui devra être exécuté en admin et fixera une fois pour toute la config.

    Un peu de lecture sur Manifest et UAC ici.

    Pour la signature, et bien il faut mettre la main au porte-monnaie et acheter un certificat chez Verisign, Comodo ou autres et signer l'exécutable avec SignTool.exe disponible dans le SDK Windows.

  13. #13
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Suite
    Je te remercie pour l'info concernant les signatures, mais c'est ce que je craignais, je n'ai pas envie d'aller jusque là.
    Par contre concernant le reste, je n'ai peut-être pas tout compris mais il me semble avoir compris en tout cas que tu dis exactement la même chose que moi.
    S'il n'y a pas manifest avec requireAdministrator et je rajouterai s'il n'y a pas clic droit avec demande des droits alors il y a virtualisation, c'est exactement ce que je dis ou alors tu n'as pas bien lu ou lu jusqu'au bout.
    S'il y a manifest avec requireAdministrator et je rajouterai encore ou demande des droits par clic droit alors il n'y a pas virtualisation, c'est exactement ce que je dis encore.
    Par contre, un élément important qui me semble t'avoir échappé c'est que clic droit avec demande des droits ça n'a pas à terme le même effet que manifest avec requireAdministrator, c'est ce que j'essaie d'expliquer depuis le début: avec clic droit, les privilèges administrateur ne sont conservés que jusqu'à l'arrêt du micro! quand le micro est relancé le même programme qui cette fois ci est lancé par windows (windows ne fait pas clic droit) et non plus par l'utilisateur n'a plus aucun droit et donc il écrit maintenant dans l'adresse virtuelle, ce qui n'est pas le cas EVIDEMMENT avec manifest + requireAdministrator !!
    Je ne sais pas ce qu'est un installer, si tu peux préciser, ça peut m'intéresser.
    Enfin concernant mon programme contrairement à ce que tu dis, il marche très bien, aussi bien sous XP que sous Windows 7, certes pour Windows 7 j'ai imaginé une solution qui contourne la protection de windows, mais en tout cas l'utilisateur sous win7 n'a jamais à faire clic droit pour demander les privilèges (IL FAIT UN SIMPLE DOUBLE CLIC) et pourtant JE MODIFIE LES REGISTRES pour que le programme puisse être relancé par windows, J'ECRIS TOUJOURS AU MÊME ENDROIT sur le disque dur et à la relance du micro AUCUNE QUESTION du genre "Voulez-vous autoriser le programme provenant d'un éditeur inconnu..." N'EST POSEE A L'UTILISATEUR. Ce programme tourne sous Win 7 sans problème depuis plus d'une semaine.
    Mais peut-être que un installer aurait été plus dans la norme, je ne sais pas.

  14. #14
    Rédacteur/Modérateur
    Avatar de Andnotor
    Inscrit en
    Septembre 2008
    Messages
    5 671
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5 671
    Points : 13 065
    Points
    13 065
    Par défaut
    Citation Envoyé par Athur Voir le message
    S'il n'y a pas manifest avec requireAdministrator et je rajouterai s'il n'y a pas clic droit avec demande des droits alors il y a virtualisation
    Faux. D'après le lien que je t'ai donné, seule la présence ou l'absence de requestedExecutionLevel détermine s'il y a virtualisation ou pas.

    Citation Envoyé par Athur Voir le message
    avec clic droit, les privilèges administrateur ne sont conservés que jusqu'à l'arrêt du micro!
    Encore faux. Pas jusqu'à l'arrêt du micro, mais jusqu'à la fin du processus. Tu peux lancer 10x ton programme sans rebooter, 10x tu devras passer par RunAs.

    Citation Envoyé par Athur Voir le message
    Enfin concernant mon programme contrairement à ce que tu dis, il marche très bien, aussi bien sous XP que sous Windows 7
    Je répète encore une fois: ton "testeur" n'a qu'un seul compte sur sa machine (il est administrateur) et il a désactivé l'UAC. Et donc de ton côté, tu as "l'impression" que requireAdministrator résout tout les problèmes. C'est une erreur !
    Et sous XP, tu es en admin aussi ? As-tu testé avec un compte limité ?

    Citation Envoyé par Athur Voir le message
    certes pour Windows 7 j'ai imaginé une solution qui contourne la protection de windows
    Et quelle est cette solution miracle ?

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Suite
    Re,
    J'ai l'impression de prêcher dans le vide où alors tu joues sur les mots, que le programme soit lancé 10 fois tant que le micro n'a pas été rebooté et qu'il garde dans ce cas les droits peut-être bien mais ça n'est pas du tout ça le problème.
    Je paufine alors l'explication: mon programme n'a pas besoin d'être lancé 10 fois, il n'est lancé par l'utilisateur qu'une fois, mais une fois lancé il reste actif en permanence 24h /24, 7 jours /7, 365 jours par an! c'est pour ça qu'il a besoin de s'inscrire dans les registres car quand l'utilisateur reboote son micro, c'est windows qui le relance et il reste à nouveau actif dans le gestionnaire TOUT LE TEMPS !!!
    Concernant ma première affirmation que tu as cité et pour laquelle tu me dis faux! c'est bien d'affirmer faux, mais moi je te dis dans cette phrase et ce que je te dis ça a été testé, ça n'est pas une affirmation de principe qu'avec le programme sans fichier manifest s'il est lancé par double clic il y a effectivement virtualisation, mais s'il est lancé par clic droit avec demande de privilèges il n'y a plus virtualisation et ceci sans fichier manifest !! je suis d'autant plus à l'aise pour l'affirmer que c'était mes premiers tests et à ce moment là, je ne savais même pas que les fichiers manifest existaient, je ne pouvais donc pas en avoir mis !!
    Concernant ma deuxième affirmation que tu as encore citée et pour laquelle tu me dis encore faux, là on joue sur les mots ou plutôt je n'avais peut-être pas suffisamment bien expliqué, mais avec l'explication que j'ai donnée ci-avant tu as peut-être maintenant compris, moi j'ai dit jusqu'à l'arrêt du micro et non pas jusqu'à la fin du processus car pour mon programme la fin du processus n'a pas de sens du moment que le processus est actif en permanence sauf évidemment à l'arrêt du micro!!
    Concernant la 3ème citation où tu me dis que l'utilisateur a désactivé je ne sais plus quoi, l'utilisateur même s'il a un seul compte et là je te renvoie au premier point s'il n'y a pas le fichier manifest ou s'il ne fait pas clic droit le programme ne peut pas s'exécuter car il ne peut pas accéder aux registres pour s'y inscrire, (ça faisait aussi partie des tout premiers tests) c'est d'ailleurs la première chose que fait le programme quand il est lancé manuellement par l'utilisateur!! et concernant XP je suis sous un compte limité!! Je n'ai pas de problème.
    Ma solution tordue qui marche sans intervention spécifique de l'utilisateur, je veux bien la donner à condition qu'on m'assure que je ne vais pas avoir toutes les critiques et invectives qui vont me tomber sur le dos.

  16. #16
    Rédacteur/Modérateur
    Avatar de Andnotor
    Inscrit en
    Septembre 2008
    Messages
    5 671
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5 671
    Points : 13 065
    Points
    13 065
    Par défaut
    Tu as certainement raison. Moi je vais m'arrêter là

  17. #17
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Reconnexion
    Bon désolé, je te présente mes excuses, j'ai revu mes tests, je t'ai dit une idiotie la dernière fois. Lors des premiers essais de mon programme sans fichier manifest, et lorsque je lui ai fait faire clic droit et runas administrator, le fichier avait été créé sur une adresse virtuelle.
    C'est d'autant plus idiot que c'est ce qui m'a fait découvrir les adresses virtuelles (j'avais dû lui faire faire une recherche du fichier pour savoir où il était passé!!) Mea culpa massima culpa.

    Que les droits administrateur ne sont conservés que jusqu'à la fin du processus (sans fichier manifest avec seulement clic droit etc...), c'est parfaitement d'accord, mais comme je l'ai dit mon processus ne s'arrête que lorsque l'utilisateur arrête son micro.

    En fait, mon programme aurait très bien pu marcher sans fichier manifest avec un simple clic droit (runas etc...) et les fichiers étaient toujours créés en adresses virtuelles. Je n'ai pas arrêté de dire des bêtises, encore désolé.

    En résumé, j'ai construit une usine à gaz, uniquement pour éviter à l'utilisateur de faire clic droit..... enfin, maintenant ça tourne comme ça. Le programme est sous Program Files, mais je crée quand même les fichiers en adresses virtuelles.

  18. #18
    Membre éprouvé
    Inscrit en
    Juin 2006
    Messages
    795
    Détails du profil
    Informations forums :
    Inscription : Juin 2006
    Messages : 795
    Points : 1 270
    Points
    1 270
    Par défaut

    Ca m'a l'air d'être une histoire de fous ça...

    Citation Envoyé par Athur Voir le message
    Lors des premiers essais de mon programme sans fichier manifest, et lorsque je lui ai fait faire clic droit et runas administrator, le fichier avait été créé sur une adresse virtuelle.
    Tu es sûr de ça ? Si oui alors y a un bug parce que si tu essaies d'écrire un fichier sur un emplacement protégé et qu'il écrit quand même sur l'emplacement virtualisé malgré que tu aies les droits admin ... ben, comment dire... hum... comment tu fais pour écrire à cet emplacement ?
    Même l'admin a pas les droits et se retrouve à écrire sur une vulgaire copie tel un malpropre !
    En tout cas c'est secure !! Pas moyen de modifier le fichier !

    Ensuite tu as dit que tu tournais sous XP avec un user n'ayant pas les droits admin qui arrive quand même à écrire sous HKEY_LOCAL_MACHINE ?
    Ca aussi ça me paraît fort de café. Si tu pouvais encore confirmer ça serait sympa.
    Je ne suis pas expert en sécurité mais normalement ça ne devrait pas être possible (pour des raisons évidentes de sécurité).

    Citation Envoyé par Athur Voir le message
    Par contre, un élément important qui me semble t'avoir échappé c'est que clic droit avec demande des droits ça n'a pas à terme le même effet que manifest avec requireAdministrator
    ...
    l'utilisateur sous win7 n'a jamais à faire clic droit pour demander les privilèges (IL FAIT UN SIMPLE DOUBLE CLIC) et pourtant JE MODIFIE LES REGISTRES pour que le programme puisse être relancé par windows, J'ECRIS TOUJOURS AU MÊME ENDROIT sur le disque dur et à la relance du micro AUCUNE QUESTION du genre "Voulez-vous autoriser le programme provenant d'un éditeur inconnu..." N'EST POSEE A L'UTILISATEUR. Ce programme tourne sous Win 7 sans problème depuis plus d'une semaine.
    Là aussi c'est du comportement de fou.
    Normalement, peut importe la manière que tu as utilisée pour lancer une appli en admin, elle se comportera toujours de la même manière !
    - que tu fasses un clic droit "Run as admin"
    - que tu ailles dans les propriétés du fichier et que tu lui demandes de toujours s'executer en admin
    - que tu fasses un raccourci qui lui éxecute le fichier en admin
    - que tu lances une console avec les droits admin et lances ton appli depuis celle-ci
    ... etc

    Le résultat sera toujours le même, tu lances ton appli en admin.

    Et si jamais t'es sous Vista/7 avec l'UAC d'activée, tu auras toujours une demande d'élévation des privilèges. Un autre comportement est juste une faille de sécurité.

    Citation Envoyé par Athur Voir le message
    Mais peut-être que un installer aurait été plus dans la norme, je ne sais pas.
    Effectivement je pense que c'est ce qu'il te faut !

    Citation Envoyé par Athur Voir le message
    je veux bien la donner à condition qu'on m'assure que je ne vais pas avoir toutes les critiques et invectives qui vont me tomber sur le dos.
    Moi je suis bien curieux de savoir comment tu as fait.
    Et ne t'inquiètes pas, je ne te critiquerais pas. Par contre je ne peux pas m'avancer quant aux autres intervenants...

  19. #19
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 214
    Points : 99
    Points
    99
    Par défaut Solution tordue
    Merci de t'intéresser à ce débat, le problème c'est que c'est assez ancien et que comme, moi je n'ai pas win 7, j'ai un peu oublié les choses pour répondre à tes premières questions. Ce programme était pour quelqu'un d'autre, je sais qu'il tourne toujours sans problème chez cette personne et donc sous win 7.
    Concernant ma solution tordue je me rappelle à peu près ce que j'ai fait.
    Je rappelle que le programme est un progamme de surveillance et fonctionne de la manière suivante: il est lancé une seule fois à la main par l'utilisateur il s'installe donc immédiatement comme processus actif permanent dans le gestionnaire et chaque fois que le propriétaire de l'ordi arrête et relance son micro c'est ensuite windows qui relance automatiquement ce même programme pour qu'il soit constamment actif dans le gestionnaire.
    Mon problème de pauvre utilisateur de XP était le suivant: c'était que lorsque le programme est lancé pour la première et seule fois par l'utilisateur sous win7 il ait les privilèges administrateur pour deux raisons: 1) pour pas que l'utilisateur soit obligé de faire clic droit pour les demander (je veux qu'il n'ait qu'à faire un double clic ordinaire) 2) Parce que lors de son premier lancement le programme doit modifier les registres pour que windows le relance après le prochain arrêt du micro. Mon problème se complique ensuite car une fois le programme installé et les registres modifiés, je ne veux plus que le programme ait les privilèges administrateur de manière à ce qu'il se comporte comme un programme ordinaire qu'il ne demande plus d'autorisation à l'utilisateur chaque fois qu'il doit écrire quelque part, qu'il aille donc toujours écrire ses observations au même endroit et donc dans des adresses utilisateur virtuelles !!
    On voit donc que ces deux besoins sont contradictoires c'est pourquoi je parle de solution tordue.
    La solution tordue vient du fait que pour des raisons pratiques de programmation et de recherche dans des fichiers je me suis écrit plusieurs utilitaires, en particulier un utilitaire qui découpe des fichiers, puis qui les recolle et surtout un utilitaire qui peut concaténer des fichiers qui n'avaient pas été préalablement découpés. C'est ainsi que je me suis aperçu que si je collais deux fichiers quelconques par exemple deux fichiers .pdf qui n'avaient rien à voir l'un avec l'autre pour ne faire qu'un seul fichier .pdf, lorsque je cliquais dessus ce dernier pour l'ouvrir, Windows n'y voyait que du feu, je n'avais aucune insulte et il ouvrait tout simplement le premier sans ce soucier du second qui était collé derrière.
    Eh bien c'est de cette particularité dont je me suis servi car il en va de même s'il s'agit de deux .exe (l'operating system ne s'aperçoit de rien).
    J'ai donc fait deux programmes un programme compilé avec fichier manifest et privilèges administrateur que j'ai placé en tête et un programme compilé sans fichier manifest et sans droits que je lui est collé derrière l'ensemble ne faisant qu'un seul .exe que j'ai demandé à l'utilisateur d'installer quelque part sous program file (x86) et de lancer par un simple double clic.
    Le fonctionnement ensuite est simple mais comme c'est assez ancien je ne garantis plus exactement l'ordre des opérations mais en gros il est celui-ci: par le double clic de l'utilisateur, windows lance le 1er programme qui a donc les privilèges, il accède donc aux registres et installe dans hkey_local_machine un nom de programme à lancer qui n'est pas lui-même mais le nom du programme qu'il va créer (celui qui n'aura pas les privilèges) ensuite ce programme avec privilège ouvre son propre .exe (donc lui-même) et recopie au même emplacement la partie qui lui a été collée derrière en lui donnant le même nom (et .exe) que celui qui a été mis dans les registres. Ensuite le programme avec privilèges lance dans le gestionnaire par un SHELL le programme qu'il vient de créer et qui sera le programme définitif permanent et sans privilèges. Ensuite le programme avec privilèges se termine. Enfin, la première chose que fait le programme définitif sans privilèges lorsqu'il démarre il delete le .exe du programme avec privilèges.
    Voilà pourquoi je disais que ma solution était tordue !
    A+

  20. #20
    Membre éprouvé
    Inscrit en
    Juin 2006
    Messages
    795
    Détails du profil
    Informations forums :
    Inscription : Juin 2006
    Messages : 795
    Points : 1 270
    Points
    1 270
    Par défaut
    Effectivement c'est assez original comme solution !
    Tu as l'air très ingénieux pour contourner les problèmes.

    Par contre si je puis me permettre, ton cas devrait pouvoir se résoudre avec un installeur.
    En fait, tu as réinventé l'installeur si j'ai bien compris.
    En effet tu as un premier .exe, qui contient le vrai programme que tu veux utiliser.
    Ce premier .exe se charge d'écrire dans la base de registre et de copier ton deuxième .exe (surement dans Program Files) en ayant les droits admin.

    C'est exactement le rôle de l'installateur !
    Préparer l'environement de ton application (modification de la Bdr, copie de fichier de conf, etc...) et copier ton application à l'endroit voulu.
    Dans ce cas, seul l'installateur doit avoir les droit admin mais en aucun cas (sauf exeception ) ton application.

    Il existe des applications gratuites qui te permettent de créer tes installateurs.
    Je te conseille InnoSetup.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [Windows]accès base de registre windows
    Par Greg01 dans le forum API standards et tierces
    Réponses: 27
    Dernier message: 05/06/2007, 16h14
  2. Documentation gratuite sur l'API Windows, COM, DCOM, OLE, etc.
    Par Community Management dans le forum Windows
    Réponses: 1
    Dernier message: 16/11/2006, 16h28
  3. Programme de boot qui passe la main à Windows
    Par Bob dans le forum Assembleur
    Réponses: 7
    Dernier message: 25/11/2002, 04h08
  4. OmniORB : code sous Windows et Linux
    Par debug dans le forum CORBA
    Réponses: 2
    Dernier message: 30/04/2002, 18h45
  5. Quel désassembleur/assembleur pour un exe Windows ?
    Par Anonymous dans le forum x86 32-bits / 64-bits
    Réponses: 6
    Dernier message: 17/04/2002, 11h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo