Suivi des composants

séparation
limite la flexibilité de Windows et accroît le coût global de possession (TCO)
d’une infrastructure NT.

Dans Windows NT 4.0, le problème des DLL étant difficile à  résoudre, la
meilleure stratégie est d’essayer d’éviter le problème

Windows 2000 et NT 4.0 utilisent des comptes de références (refcounts) pour faire
le suivi du nombre d’applications dépendant de tel ou tel composant partagé. Le
comptage des références est un mécanisme fragile, parce qu’il compte sur chaque
application dépendante pour s’ajouter ou se soustraire correctement du compte
de références d’un composant, quand celui-ci est installé ou désinstallé par l’application.
Les applications n’effectuent pas cette opération ou, du moins, pas correctement.
Les comptes de références des DLL partagées et des autres composants résident
dans le Registre sous la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs.
Dans le cas d’un composant COM, celui-ci se sert de son GUID (Globally Unique
ID) pour enregistrer son emplacement dans HKEY_CLASSES_ROOT\CLSID et HKEY_CLASSES_ROOT\Interface.
L’entrée HKEY_CLASSES_ROOT\CLSID spécifie l’emplacement du composant COM dans
le système de fichiers (un chemin vers le composant réside normalement dans la
valeur du Registre InprocServer32). Une application qui appelle un composant COM
particulier parcourt le Registre pour le localiser. L’application appelante utilise
le GUID du composant, qui renvoie à  une interface dans le composant ou dans le
ProgID (programmatic identifier) du composant, pour localiser la clé dans HKEY_CLASSES_ROOT\CLSID
qui décrit le composant dans le Registre. L’application localise alors la DLL,
le fichier EXE ou le composant OCX contenant la fonctionnalité dont l’application
a besoin.

Si le composant n’est pas basé sur COM (par exemple une bibliothèque de fonctions
Win32), l’application utilise un processus différent pour localiser et charger
le fichier dont elle a besoin. Il s’agit très souvent d’un processus de recherche
qui consiste à  rechercher d’abord dans la mémoire du système, puis dans \winnt\system32,
puis dans le répertoire de l’application, et ensuite dans tout chemin défini dans
le système. Dans Windows NT, les applications achetées ou développées installent
la plupart des composants partagés, par défaut, dans \winnt\system32.

Supposons, par exemple, que vous achetiez et installiez l’application A. Celle-ci
installe la version 1.0 de comctrl32.ocx dans \winnt\system32 sur toutes les stations
de travail. Six mois plus tard, vous installez l’application B. Celle-ci comprend
la version 2.0 de comctrl32.ocx. Son programme d’installation remarque la version
1.0 de l’OCX et la met à  niveau vers la version 2.0, écrasant la version précédente.
Vous pensez certainement que la version A va continuer à  fonctionner avec la version
2.0 du nouveau composant. Or cette compatibilité ne se produit pas souvent.
Fréquemment, l’application A échoue et affiche un message à  propos d’un point
d’entrée ou d’un ordinal, que le programme ne peut pas trouver, ou d’une méthode
non supportée. Dans ce cas, il y a deux choix possibles. Soit décider que les
applications A et B n’existeront pas sur la même machine, soit mettre à  niveau
l’application A pour supporter la version 2.0 du composant. Cette deuxième solution
peut s’avérer difficile si l’application A a été déployée sur 50.000 PC ou si
son développeur ne se trouve plus dans l’entreprise et que vous n’avez pas le
code source. Heureusement, Microsoft reconnaît la difficulté posée par ce problème
aux entreprises et essaie d’y remédier dans Windows 2000 et Windows 98 Second
Edition (Win98SE).