Pourquoi ai-je besoin de redémarrer l'ordinateur après avoir installé un nouveau logiciel ?

Cela dépend.

Si le logiciel installé affecte une partie intégrale du système d'exploitation, alors un redémarrage est nécessaire. Par exemple, un nouveau noyau pour le système d'exploitation.

Sur les systèmes Windows, il est souvent utilisé car les utilisateurs sont considérés comme étant trop stupides pour utiliser correctement leurs ordinateurs. Par exemple, Microsoft publie des détails sur la façon de changer le "Type de noeud" utilisé pour le réseau sur son site web, y compris l'instruction de "redémarrer l'ordinateur" alors qu'il suffit seulement de redémarrer un service réseau comme détaillé ici. Parce que nous, en tant qu'utilisateurs, sommes trop stupides pour redémarrer un service, on nous dit de tout redémarrer.

Pour certains logiciels, j'en suis arrivé à la conclusion que c'est une habitude et souvent pas nécessaire même quand on nous le dit. Si je ne pense pas qu'un logiciel ait modifié quelque chose de majeur dans le système d'exploitation, je ne prends pas la peine de le faire, et je n'ai rencontré aucun problème (et s'il y avait des problèmes, ils seraient faciles à résoudre).

Parfois, un logiciel peut apporter une modification qui ne peut pas entrer en vigueur lorsque l'ordinateur est en cours d'utilisation. Certaines raisons pourraient être - un fichier est en cours d'utilisation, le changement ne peut se produire qu'au démarrage de l'ordinateur, il pourrait y avoir un problème de sécurité qui ne peut être réglé que avant que l'ordinateur ait son réseau actif, peut-être que l'antivirus interférerait avec l'installation.

Parfois, c'est simplement une programmation négligente de la part des développeurs.

Je suis sûr qu'il y en a beaucoup d'autres.

Souvent, lors de l'installation d'un nouveau logiciel, une dll (fichier) utilisée par de nombreux autres packages logiciels doit être mise à jour vers une nouvelle version. (Cela est beaucoup plus probable lorsque vous mettez à jour une application déjà installée.)

Si la dll est utilisée par une application en cours d'exécution, une partie de celle-ci sera chargée en mémoire et le reste sera lu à partir du disque lorsque cela est nécessaire. Par conséquent, la dll sera verrouillée sur le disque. (Pensez aux problèmes si elle n'était pas verrouillée!)

Une DLL verrouillée ne peut pas être mise à jour, donc le programme d'installation demandera à Windows de remplacer la DLL par la nouvelle version la prochaine fois que la machine redémarrera. D'où la nécessité d'un redémarrage.

Certains meilleurs installateurs vous indiqueront les applications qui doivent être fermées avant d'exécuter le programme d'installation, permettant ainsi à la DLL d'être mise à jour sans redémarrage. Cependant, cela rend l'interface utilisateur de l'installateur plus complexe et entraîne davantage d'appels de support.

Un programme d'installation pour une application peut également demander à l'application de sauvegarder son état, de se fermer, puis de redémarrer une fois que la DLL a été mise à jour. Cela ne peut être fait que si la DLL est utilisée par une seule application. La plupart des applications qui se mettent automatiquement à jour font cela - cela devrait être la norme pour les applications grand public lorsqu'il y a beaucoup d'utilisateurs.

Tout ce qui précède peut conduire à une logique complexe difficile à tester. Tester les installateurs prend beaucoup de temps, car il faut essayer de deviner chaque état possible de la machine de l'utilisateur. Il est donc souvent préférable qu'un programme d'installation soit simple et fonctionne toujours, même s'il entraîne quelques redémarrages pour l'utilisateur.

Il est rare qu'un utilisateur décide d'acheter une autre application en raison de redémarrages de l'installateur, donc le vendeur passe du temps (de l'argent) à travailler sur ce qui est nécessaire pour inciter les utilisateurs à acheter leurs applications.

Combien de fois avez-vous rencontré un problème après avoir installé une application qui s'est résolu en redémarrant? Pensez aux coûts de support de nombreux utilisateurs appelant pour des problèmes qui se résolvent simplement avec un redémarrage. Il peut rapidement devenir très tentant pour un développeur de demander toujours à l'utilisateur de redémarrer après avoir installé son logiciel même lorsque cela ne semble pas nécessaire.

----------

La plupart des systèmes d'exploitation et des logiciels ont été écrits à une époque où l'espace disque et la mémoire coûtaient beaucoup d'argent. Il y a maintenant une tendance pour que les applications aient une copie privée de toutes les dll qu'elles utilisent, ce qui rend la mise à niveau plus simple, mais utilise plus d'espace de stockage.

Sur les serveurs, cela se fait avec des "conteneurs", cependant les "conteneurs" ne fonctionnent pas bien pour les logiciels de bureau, car vous souhaitez pouvoir accéder aux données enregistrées par une application avec une autre application. (Sinon, utilisez simplement un iPhone.)

La raison en est que si vous ne le faites pas: vous allez planter. De Raymond Chen:

Même si vous remplacez un fichier qui est en cours d'utilisation, il peut encore y avoir du code dans le système qui veut utiliser l'ancienne version. Par exemple, supposez que vous ayez deux fichiers qui fonctionnent ensemble:

• A.dll
• B.dll

Vous appliquez un correctif qui met à jour les deux fichiers, mais A.dll est en cours d'utilisation. Pas de problème. Vous les remplacez simplement tous les deux. Par conséquent, les programmes qui utilisaient toujours A.dll continuent d'utiliser l'ancienne version, mais les nouveaux programmes utiliseront la nouvelle. Et tous les programmes obtiennent la nouvelle version de B.dll.

Maintenant un programme qui utilisait l'ancienne A.dll décide d'appeler une fonction. Il s'attend naturellement à l'ancienne version de B.dll, mais au lieu de cela il reçoit la nouvelle version. En fonction du type de modification que vous avez apportée à B.dll, cet appel peut fonctionner—ou cela peut planter. Les deux DLL supposent que leur partenaire provient du même ensemble de correspondance.

Pour être tout à fait honnête, c'est moins de travail (et donc moins d'argent) de la part des développeurs de logiciels de supposer que les mises à jour nécessiteront toujours un redémarrage. C'est probablement autant une décision des comptables que des développeurs.

En fin de compte, il y a très peu de mises à jour qui ne pourraient pas, dans un monde idéal, être effectuées sans redémarrage, mais cela nécessite beaucoup de planification préalable, et il y a certains risques, étant donné la grande variété de configurations possibles pour un système.