2009-08-10 7 views
0

Il est possible de propager dans une application déjà ouverte la valeur (variables d'environnement de Windows) d'une variable de Windows après sa création ou sa modification sans avoir à redémarrer les applications qui tournent?propagation de variables d'environnement sur système Windows

Comment? Peut-être que l'utilisation d'une erreur de serveur pour publier une telle question serait peut-être préférable?

Répondre

1

Non, je suis à peu près sûr que ce n'est pas possible.

+0

Je suis d'accord avec vous si je n'avais jamais quelque chose à l'oreille de la propagation d'une variable modifiée de Windows par la ligne de commande: net – pindare

3

Quelque chose comme SendMessage(HWND_BROADCAST,WM_WININICHANGE,0,"Environment") est votre meilleur pari, mais la plupart des applications l'ignoreront, mais Explorer devrait le gérer.

Si vous voulez entrer dans un pays fou non documenté, vous pouvez utiliser WriteProcessMemory et mettre à jour le bloc d'environnement dans chaque processus auquel vous avez accès.

+0

intéressant, en effet, il semble impossible d'obliger un processus qui met à jour son environnement variable, sauf si elle était précédemment planifiée. – pindare

3

Oui, c'est possible.

Méthode

Il est impliqué bien. Je vais décrire les étapes de base. Le détail de chaque étape est documenté dans de nombreux endroits sur le Web, y compris Stack Overflow.

  1. Créez une DLL d'assistance. La DLL ne fait rien sauf définir les variables d'environnement que vous voulez définir. Il peut le faire à partir de DllMain sans causer de problèmes. Juste ne vous fâchez pas avec d'autres appels de fonction à l'intérieur de DllMain. Comment vous communiquez à la DLL quelles variables à définir et quelles valeurs les définir est laissé pour vous de décider (lire un fichier, lire à partir du registre ...)

  2. Énumérer tous les processus que vous souhaitez mettre à jour (toolhelp32 aider avec ceci).

  3. Pour chaque processus que vous souhaitez mettre à jour, injectez votre DLL d'assistance. CreateRemoteThread() aidera avec ceci. Cela échouera pour 2% de toutes les applications sur NT 4, passant à 5% sur XP. Probablement des échecs de pourcentage plus élevés pour Vista/7 et les versions du serveur.

Les choses que vous devez vivre avec:

Si vous exécutez un processus 32 bits sur un système d'exploitation 64 bits, CreateRemoteThread ne parviendra pas à injecter votre DLL dans 32 bits apps 100% du temps (et ne peut pas injecter dans les applications 64 bits de toute façon car c'est un travail pour une application 64 bits).

EDIT: Il s'avère que 100% n'est pas correct. Mais c'est très aléatoire. Ne comptez pas dessus.

Ne pas rester résident

Si vous ne voulez pas que votre DLL d'aide pour rester résident dans l'application cible, retourner FALSE pour la notification DLL_PROCESS_ATTACH.

BOOL APIENTRY DllMain(HANDLE hModule, 
         DWORD ul_reason_for_call, 
         LPVOID lpReserved) 
{ 
    if (ul_reason_for_call == DLL_PROCESS_ATTACH) 
    { 
     // set our env vars here 

     SetEnvironmentVariable("weebles", "wobble but they don't fall down"); 

     // we don't want to remain resident, our work is done 

     return FALSE; 
    } 

    return TRUE; 
} 
+0

+1 pour l'effort, pour pousser un peu plus loin, savez-vous comment propager ces modifications au registre (certaines variables d'environnement de référence de registre, elles doivent être rafraîchies aussi), je ne connais tout simplement pas l'appel de l'API. – zinking

+0

Oui, utilisez regedit pour trouver où les variables d'environnement sont stockées (deux emplacements, pour un système d'exploitation 32 ou 64 bits et également un système d'exploitation 64 bits, un autre pour le sous-système 32 bits). Ensuite, écrivez le code qui navigue à l'endroit approprié dans le registre. Les écrire les valeurs appropriées. C'est impliqué et désordonné mais pas dur. –

Questions connexes