Windows confidentiel Windows peut mais Won’t
Raymond Chen
Windows fait peuvent remplacer une DLL qui est utilisé en renommant d'origine, puis copier le nouveau fichier en place. Toutefois, le monde de Windows préfère ne pas cela. Pourquoi ?
Même si vous remplacez un fichier qui est en cours d'utilisation, il existe toujours peut-être code dans le système souhaite utiliser l'ancienne version. Par exemple, supposons que vous avez deux fichiers A.DLL et B.dll, qui fonctionnent ensemble. Vous émettez un correctif qui met à jour des fichiers, mais A.DLL est en cours d'utilisation. Aucun problème. Vous remplacez simplement les deux. Par conséquent, les programmes qui utilisaient toujours A.DLL conserver utilisant la version ancienne, mais nouveaux programmes utiliseront l'autre. Et tous les programmes obtenir la nouvelle version de B.dll.
Un programme qui utilisait l'ancien A.DLL décide à présent appeler une fonction dans. Il attend naturellement l'ancienne version de B.dll, mais au lieu de cela il obtient la nouvelle version. En fonction de quel type de modification apportée à B.dll, cet appel peut ne fonctionner, ou il peut se bloquer. Les deux DLL suppose que son partenaire provient le même ensemble correspondant.
Même si vous mettez à jour uniquement une DLL unique avec sans dépendances, sont toujours des problèmes potentiels car la DLL doit interagir avec les versions antérieures de lui-même .
Supposons que vous remplacez ole32.dll s'il est en cours d'utilisation. Un programme récemment lancé appelle la nouvelle ole32.dll puis lance une opération glisser-déplacer. L'utilisateur fait glisser l'objet sur une fenêtre créée par un des programmes qui lancés avant la mise à jour. Vous disposez à présent le nouveau ole32.dll envoyer des messages à l'ancien ole32.dll.
Lorsque vous écrivez du code qui communique entre les processus, généralement prévu que la même version du code s'exécuter dans chaque processus, car les deux extrémités dans le canal de communication doivent décider comment ils vous allez communiquer ! " Je vais pour envoyer message 5, qui signifie que le « texte demande » et vous permet de répondre par l'envoi du message 12, qui signifie « ici est le texte que vous avez demandé. » prévu » Si les deux côtés ne s'exécutent pas la même version du code, il est probable que le mécanisme de communication seront différent ; il peut être discrète, mais il peut, en fait, entraîner une incompatibilité.
Que vous ajouté un champ à une structure et que structure se trouve être utilisés dans le message 5. Enfin, tant mieux. Vous maintenant avez deux incompatibles versions du message 5 quelque, qui utilise la structure ancienne et qui utilise la nouvelle structure. Si vous n'êtes pas des deux côtés de la communication accord sur la structure, message 5 ne fonctionnera pas.
Si vous êtes point pour prendre en charge exécuter le anciennes et nouvelles versions côte à côte, vous devez à inventer un nouveau message, par exemple, message 52 et la nouvelle version de la DLL prend en charge les deux messages 5 puis message 52. Elle doit déterminer la version de la DLL exécutée sur l'autre côté tout d'abord et envoyez-le le message approprié.
Même si vous n'avez pas modifié la structure de lui-même, vous avez peut-être modifié la signification de certains champs de la structure. Si la structure a une énumération et la nouvelle version ajoute une nouvelle valeur à cette énumération, c'est toujours une incompatibilité entre l'ancienne et nouvelle.
Bien sûr, vous pouvez essayer définir de nouveaux messages chaque fois que vous émettez un correctif et écrivez du code pour prendre en charge d'interopérabilité entre les versions anciennes et nouvelles pendant la dans lequel les deux versions conflictuelles de la DLL s'exécutent en même temps. Toutefois, pouvez obtenir difficile lorsque vous êtes sur le correctif de troisième et que vous avez quatre ensembles différents de messages, une pour la version d'origine et une pour chacun des correctifs.
Même si vous avez besoin que les correctifs doivent être installés en séquence, il ne vous gagner des efforts ; tant que vous autorisez le programme initial conserver en cours d'exécution, vous devez continuer l'interopérabilité avec elle.
Et puis personnes écrivez articles signaler que vous êtes un idiot parce que vous êtes trop lent émettre des correctifs !
Donc il n'est pas que Windows doit redémarrer après avoir remplacé un fichier qui est en cours d'utilisation. Il est simplement qu'il serait plutôt pas traitent la complexité dont le résultat dans le cas contraire. Ingénierie est un ensemble des compromis. Pouvez-vous accéder à l'effort en charge des versions antérieures de vous-même à une situation qui n'est pas encore une configuration recommandée stable-état ?
de Raymond Chen Site Web, The Old New Thing et son livre identique libellée traitent de l'historique de Windows et de la Win32 programmation. Il souhaite une maison de déplacement sans échec.