Où installer de petits programmes sans installateurs sur Windows?

Sur la plate-forme Windows, la plupart des grandes applications sont équipées de leur propre installateur, qui configure des dossiers sous C:\Program Files , éventuellement d'autres endroits, et peut-être en ajoutant des clés de registre, etc.

Mais il existe encore quelques outils qui consistent juste en un .exe ou peut-être aussi un README et un .dll ou deux.

Comment installer de tels outils? Directement dans C:\Program Files ? Tout dans un sous-dossier sous C:\Program Files ? Quelque part sous C:\Users\Me ? Quelque part totalement différent?

Ou peut-être différentes approches pour les outils avec juste un .exe à ceux qui ont également d'autres fichiers, ou peut-être que ceux avec .dll s doivent être traités différemment …

Existe-t-il un moyen standard accepté de le faire? Une «meilleure pratique»? Si la réponse dépend de la version de Windows, j'utilise Windows 7.

En particulier, ce qui pourrait frapper les gens comme la réponse évidente semble avoir une prise:

J'avais essayé de créer manuellement de nouveaux sous-dossiers sous C:\Program Files . En fait, je pensais que je l'avais fait auparavant, mais Windows met en place une boîte de dialogue Accès aux dossiers de destination refusée . Cela m'a fait réfléchir deux fois plutôt que simplement aveuglément, cliquer Continuer .

Accès au dossier de destination refusé

En supposant que des esprits plus importants que le mien ont été confrontés à plusieurs reprises au cours des années, j'aimerais demander à la communauté si une sorte de «meilleure pratique» est acceptée.

Utilisez C:\Tools

Ou C:\Users\<user>\Tools

J'utilise de nombreux petits programmes sans installateur et je recommande ce qui suit:

  • Enregistrez-les dans C:\Tools
  • Si un programme se compose d'un seul fichier, placez-le directement sous C:\Tools
  • Si un programme se compose de plusieurs fichiers, placez-le sous C:\Tools\ProgramName
  • Les outils SysInternals ont une catégorie spéciale C:\Tools\_SysInternals car il y en a beaucoup

Je déplace simplement C:\Tools de machine en machine lors de la migration, fonctionne comme un charme.

Exemple pratique (liste abrégée):

 C: \ Tools \ autoexec-elevated.bat
 C: \ Tools \ cleanup.bat
 C: \ Tools \ BabelMap.exe
 C: \ Tools \ netmon.exe
 C: \ Tools \ notifu.exe
 C: \ Tools \ putty.exe
 C: \ Tools \ UDPixel.exe
 C: \ Tools \ battery.vbs

 C: \ Tools \ 3dclip-1.5.1 \
 C: \ Tools \ alternatestreamview \
 C: \ Tools \ blender-2.71-windows64 \
 C: \ Tools \ Notepad ++ \
 C: \ Tools \ QueryExpress \
 C: \ Tools \ winscp555 \
 C: \ Tools \ Xinorbis \

 C: \ Tools \ _Sysinternals \ accesschk \
 C: \ Tools \ _Sysinternals \ Autoruns \
 C: \ Tools \ _Sysinternals \ depends22_x64 \
 C: \ Tools \ _Sysinternals \ depends22_x86 \
 C: \ Tools \ _Sysinternals \ LogonSessions \

J'espère que cela donne une idée.

EDIT: Informations complémentaires

Je suppose que sous installation dans votre question Comment installer de tels outils? Vous voulez dire l'installation manuelle, quelque chose comme la copie des fichiers.

Règle de base: utilisez des dossiers créés manuellement pour les fichiers manuellement entretenus. Laissez les dossiers système être utilisés par les processus (installation) que vous ne contrôlez pas directement. Vous bénéficierez immédiatement de la reconnaissance du contenu dont le contenu est «le vôtre» (et vous pouvez le copier gratuitement) et quelle application est gérée par l'installateur.

Donc, lors de l'installation manuelle (en copiant), restez loin de

  • C:\Program Files – les programmes trouvés ici ne peuvent pas être simplement migrés, doivent être réinstallés (donne un excellent indice de migration)
  • C:\Program Files (x86) – comme ci-dessus, mais sur les systèmes 64 bits, les programmes 32 bits vont ici (peut donner un indice pour déterminer si une application particulière est 32 bits ou 64 bits)
  • C:\ProgramData – les stockages d'applications trouvés ici montrent que ces programmes maintiennent certaines de leurs données à leur manière. Mais vous avez demandé de mettre vos programmes sous Données? Pas une bonne idée.
  • C:\Users\Steven\AppData – à nouveau, mettre des programmes sous Data n'est pas une bonne idée. Si vous avez demandé des données, plusieurs choses intéressantes peuvent être écrites sur ce chemin. Mais pour les programmes simplement «non». 🙂

Chemin possible

  • C:\Users\Steven – peut être votre racine alternative s'il s'agit d'un ordinateur partagé et que vous souhaitez le maintenir en ordre, vous décidez de ne pas créer de répertoires globaux. Vous pouvez considérer C:\Users\Steven\Tools pour vos programmes ou même C:\Users\Steven\Desktop\Tools si vous souhaitez utiliser un accès confortable au dossier de bureau disponible via un raccourci de plusieurs endroits dans Windows. Mais mieux peut être l'ancien et vous pouvez toujours placer le raccourci vers ce dossier sur un bureau ou chaque fois que cela est nécessaire.

Pour autant que je sache, il n'y a pas d'approche universelle.

Placer vos applications dans C:\Program Files est plutôt standard. Et vous obtiendrez la protection d'accès : les utilisateurs réguliers (et non élevés) ne peuvent pas écrire sur C:\Program Files . Donc, vous ne pouvez pas supprimer accidentellement, écraser ces fichiers; Et ils sont mieux protégés contre les virus.

C'est pourquoi vous obtenez la demande d'alerte-élévation – lorsque vous essayez de créer un dossier dans C:\Program Files .

Par conséquent, C:\Program Files est l'endroit le plus sécurisé pour les fichiers exécutables.

Cependant, il ne convient pas aux applications (portables) qui stockent leur configuration près de .exe car elles ne pourront pas enregistrer les modifications de configuration.


C:\ProgramData sert à stocker les données d'application partagées entre les utilisateurs. Par défaut, tous les utilisateurs peuvent créer des fichiers et des dossiers ici, mais seul l'utilisateur qui les a créé peut modifier les fichiers.

Ce dossier pourrait être facilement utilisé pour les applications / outils partagés. Dans le même temps, je n'ai jamais vu une application dans ce dossier.


Si vous placez des applications dans votre profil d'utilisateur, C:\Users\<username> , d'autres utilisateurs du système n'auraient aucun accès. Vous avez toutes les autorisations pour votre profil, de sorte que vous n'obtiendrez aucun avertissement de sécurité. C'est la raison pour laquelle Chrome s'installe dans le profil de l'utilisateur: il peut se mettre à jour facilement sans inciter à l'élévation.

En mode utilisateur, les packages Windows Installer, les fichiers .msi , installez sur C:Users\<username>\AppData\Microsoft\Installer\<ProductId> . Il est donc tout à fait standard de conserver des applications non partagées dans le profil de l'utilisateur.

J'ai un dossier utils dans le profil de mon utilisateur avec des applications qui ne sont utiles que pour moi. Ce dossier est ajouté à ma variable d'environnement PATH de mon utilisateur pour un accès facile.

Pour les applications partagées, j'utilise C:\tools ou un répertoire similaire, peut-être sur un autre lecteur. Il est ajouté à la variable PATH globale.

Je suis d'accord avec des réponses déjà données à un certain point. Mais pour les très petits programmes (utils), j'ai tendance à les mettre dans le dossier bin (dans mon cas E: \ bin). Ces programmes sont généralement des fichiers exe unique ou mes propres scripts python. J'ajoute ce dossier à la variable PATH afin que je puisse utiliser ce programme à partir de la ligne de commande (ce que j'ai tendance à utiliser beaucoup).

Pour autant que je sache, il n'y a pas de meilleures pratiques. C'est vraiment à vous de décider individuellement de la façon dont vous voulez le gérer.

J'ai tendance à suivre la même norme que n'importe quelle application avec un installateur. S'il s'agit d'un fichier exécutable ou d'une bibliothèque, je placerais dans \Program Files\ s'il s'agit de 64Bit et Program Files (x86)\ s'il s'agit de 32Bit.

Les fichiers de données que j'ai tendance à stocker dans mes dossiers Users puisqu'ils sont normalement spécifiques à un utilisateur.

Il existe également des applications telles que Google Chrome et les applications Click-Once qui se déploient sur Users\AppData\ , mais celles-ci ne sont généralement pas disponibles pour plusieurs profils.

Je préfère la première méthode, car si je dois me connecter à un autre profil ou en tant qu'administrateur, je peux toujours accéder aux applications.

En ce qui concerne l'avertissement d'autorisation. C'est exactement cela, un avertissement . Il est simplement de vous avertir d'utiliser le dossier pour les mauvaises raisons, mais cela ne vous empêche pas de l'utiliser.

Si vous cherchez à standardiser ces applications, je suggérerais d'utiliser les normes de package Chocolatey . Ceci est bon pour beaucoup de raisons différentes; Principalement parce que beaucoup du logiciel a déjà été emballé pour vous et est prêt à installer de n'importe où avec quelques commandes seulement.

Il est également facile de créer vos propres paquets pour les applications que vous ne pouvez pas distribuer librement. Vous avez probablement le droit de distribuer tout ce que vous possédez sur votre propre réseau; Donc, pour ces applications, vous pouvez configurer un référentiel local . Si vous gérez de nombreux ordinateurs ou avez une bande passante limitée, cela peut être utile même pour les choses gratuites.

Si vous prenez les choix d'installation par défaut de cygwin, il place tous vos fichiers sur c: \ cygwin. Je prendrais la même approche. J'ai personnellement le dossier AC: \ apps. Dans le passé, j'ai utilisé c: \ utils, et c: \ cli (court pour ligne de commande). Cela dépend vraiment de la façon dont vous souhaitez organiser vos fichiers. Je suggérerais que les utilitaires uniques soient placés dans un dossier catchall. Pour une suite d'utilitaires (p. Ex. Cygwin, sysinternals, rktools), puis-je suggérer un sous-dossier. Par exemple, vous pouvez mettre tous les sysinternals à l'intérieur de c: \ apps \ sysinternals. Si vous installez cygwin, cela prendra la plupart (sinon la totalité) des commandes Unix que vous avez vécues.

N'oubliez pas de modifier vos variables environnementales (Démarrer> Panneau de configuration> Système> Avancé> Variables environnementales) et appuyer tous les nouveaux chemins d'application vers la variable système PATH. Cela vous permet de les exécuter à la demande à partir de l'invite de commandes ou en utilisant Windows + R (exécuter la commande).

Je pense que créer un raccourci vers C:\Tools dans le menu Send To dans Windows est la meilleure option car il est toujours accessible depuis n'importe où. De cette façon, vous pouvez rapidement "installer" vos petits programmes en cliquant avec le bouton droit de la souris et en choisissant Outils dans le menu Envoyer vers de n'importe où dans Windows.

J'ai eu ce didacticiel sur Comment ajouter au menu Envoyer à de HowToGeek
Je colle le résumé:

Pour accéder au dossier SendTo, vous devez ouvrir une fenêtre Explorer, puis collez-la dans la barre d'adresse.

% APPDATA% \ Microsoft \ Windows \ SendTo

Ensuite, collez le raccourci du dossier dans lequel vous souhaitez que vos programmes soient copiés là-bas.

Ensuite, chaque fois que vous téléchargez une nouvelle application portable, il suffit de l'extraire et de l'envoyer à cet endroit.
Le seul problème est la création de raccourcis qui, je pense, valent le faire manuellement.
Cordialement.

C:\Users\Me\toolName (aka% homepath% \ toolName) est le bon endroit pour mettre les outils en supposant que vous le désirez pour l'utilisateur Me car certains de ces outils créent des fichiers (temp) et nécessiteront l'autorisation de l'utilisateur dans l'ordre Pour écrire dans Program files dossier Program files . Un autre avantage est que vous n'oublierez pas de le sauvegarder car il est déjà dans l'espace utilisateur.

La variable d'environnement du chemin du système par défaut dans Windows est quelque chose comme (selon la version de Windows installée):

 %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ 

Hors de ces options,% SystemRoot% (qui est généralement C:/ ) semble être le meilleur choix pour vous lire / écrire et il sera facile de faire référence plus tard.

Il n'y a pas de règles à ce sujet, vous pouvez les installer là où vous le souhaitez, mais l'installation de votre OSP (partition du système d'exploitation) dans un dossier non-utilisateur est généralement une bonne idée, car vous obtiendrez les mêmes protections d'accès Est-ce que vous avez d'autres applications? Cela rend plus difficile de supprimer accidentellement, ou de les modifier par un tiers (p. Ex. Virus).

Personnellement, je place habituellement le programme dans "C: \ Program Files (x86)", car la plupart des programmes que j'ai rencontrés sont 32 bits, mais s'il s'agissait d'un programme à 64 bits, je le placerais dans C: \ Program Files " Si c'est un programme lié au système (par exemple: Imagex.exe), je le placerai dans "C: \ Windows \ system32" pour les programmes 32 bits et "C: \ Windows \ system32" pour les programmes 64 bits pour permettre un accès plus simple à partir du Ligne de commande lors de l'exécution d'instructions de commande élevées, car vous démarrez en C: \ Windows \ system32 "par défaut; Cela signifie que vous pouvez taper "nom.exe" au lieu de C: \ location \ name.exe "pour exécuter le programme.

Certaines personnes préfèrent se séparer de leur portable (ne nécessite pas d'installation ou d'effectuer des alternances non surveillées en dehors de son dossier) et les programmes non installés (non portables, mais ne nécessitent pas l'utilisation d'un programme d'installation) à partir de programmes réguliers en créant un nouveau répertoire Sur leur OSP (par exemple: C: \ Portable Program Files (x86) ou C: \ Dumpable Program Files (x86). Je vous conseillerai le 2ème de 2 compte tenu du plus grand niveau de précision, même s'il ne sonne pas comme joli.

Pour résumer, il n'y a pas de règles, cependant, si vous les installez sur l'OSP (dans un dossier non-utilisateur), vous pourrez aider à protéger le programme contre les désinstallations / modifications indésirables (y compris les modifications malveillantes) et, dans certaines circonstances L'organisation peut être bénéfique (p. Ex.: Le dossier system32 mentionné précédemment pour les programmes CLI système).