Patch
Patch (Patchs ou Patches)
|
||||
| |
Un patch est, en informatique, un "bout" de code modifiant un programme, généralement pour y apporter un correctif (à une fonction ou à une faille de sécurité) mais un "crack" est aussi un patch et l'implantation d'un parasite dans un programme existant peut aussi se faire sous forme d'un patch.
Patch est un mot d'origine anglophone désignant un "bout de code" modifiant le code originel d'un programme. Des termes francisés, comme "rustine", sont proposés mais sont peu ou pas usités dans le milieu. Le terme "correctif" est un peu plus souvent employé en français.
Nota : pluriel anglais = patches et pluriel francisés = patchs. Un verbe à été créé pour désigner l'action d'appliquer un patch : "patcher".
Origine du mot Patch
Le mot "Patch" usité actuellement pour désigner un correctif trouve son origine dans le nom d'un programme Unix écrit par Larry Wall et publié en mai 1985 (Larry Wall, linguiste et non pas programmeur, sera l'auteur, deux ans plus tard, du langage Perl. Il travaille toujours au développement de Perl, de Patch et de "rn" (un lecteur de news). Il est l'auteur, édité chez O'Reilly, de "Programming Perl" ("Programmation en Perl"), connu aussi sous le terme de « Camel Book ».
Le programme "Patch" est un programme qui permet de prendre, en entrée, un fichier appelé "diff" (produit manuellement ou automatiquement - plusieurs programmes produisent des fichiers "diff" dont Diff, Subversion, CVS, RCS). Ce fichier, en texte pur (parfaitement lisible par un humain) contient les "différences" entre une version et une autre d'un texte quelconque (de ce point de vue, le code source d'un programme est un texte quelconque). Les différences (appelées désormais "le patch") sont appliquées au texte pour le modifier d'une version vers une nouvelle version. C'est l'usage intensif fait par les programmeurs du programme Patch qui a donné le nom de Patch au correctif lui-même, au delà du programme servant à appliquer le correctif.
Intérêt des Patches
Pourquoi distribuer des patchs corrigeant une application plutôt que de distribuer l'application corrigée elle-même ? Tout simplement parce que le patch est beaucoup plus petit à faire circuler que le programme entier et aussi parce que l'on peut choisir d'installer ou de ne pas installer tel ou tel patch, en fonction de critères propres à chacun, dans une application affectée de plusieurs patch.
Patch ou Binary patches ?
Un patch est normalement distribué sous forme d'un fichier contenant du texte parfaitement lisible par l'humain dont le code source (dans le langage d'écriture d'origine du logiciel modifié), des ordres (localiser telle ligne, ajouter ou remplacer etc. ...) et des commentaires. Il faut, pour l'appliquer (le rendre actif), le placer au bon endroit dans le code source du logiciel à patcher et, si l'on est dans un langage compilé et non pas interprété, il faut recompiler le tout (puis exécuter toutes les phases de post-compilation - édition des liens etc. ...). Inutile de dire que ceci ne concerne que les informaticiens développant des applications - les programmeurs - et pour des applications dont le code source peut être dévoilé.
Les "patches" généralement connus par le public (les "patches" de Windows, par exemple), n'ont rien à voir avec les "patches" d'origine. Ce sont des "Binary patches" (des patchs en binaire) - des programmes exécutables. Ils sont distribués sous forme d'un bout de code parfaitement illisible et concernent des logiciels dont le code source est "fermé" (secret - propriétaire - le code source ne doit pas être dévoilé). Ils viennent en remplacement d'un morceau du code exécutable d'une application déjà installée (ou en remplacement total de celui-ci). Un mécanisme implante ce bout de code au bon endroit (ou met le code de remplacement à l'extrémité du code actuel de l'application et implante une instruction qui dirige vers ce nouveau code à utiliser (tout en abandonnant l'ancien code, inutilisé, en place dans l'application - ce qui n'est pas sans poser des problèmes de maintenance et de relecture par de nouveaux programmeurs qui interviendraient sur un tel code "embrouillé" auquel ils n'ont pas participé initialement).
Des patches pour quoi faire ?
S'il est vrai que les patches sont, le plus souvent, des correctifs (on corrige un problème, une erreur, une faille de sécurité...), ils ne servent pas qu'à cela. Ils permettent également l'implantation de nouvelles fonctionnalités, le remplacement ou l'adjonction d'éléments graphiques, l'accélération d'une fonction, l'amélioration du confort d'usage etc. ... On peut tout faire en "patchant" une application, y compris la "cracker" ou y injecter un parasite...
Patches à problèmes et problèmes de patches
Les patchs posent parfois des problèmes car, leur nombre grandissant, ils peuvent se gêner mutuellement (interférer entre eux ou, pire, littéralement s'écraser les uns les autres - se marcher sur les pieds) et l'application fini par ressembler à un patchwork (comprenez, par là, que l'on ne sait plus quel bout de code fait quoi etc. ...).
Un patch mal écrit (ou trop rapidement écrit, dans la précipitation, afin de corriger dans l'urgence une faille de sécurité...) peut introduire plus de nouveaux problèmes qu'il n'en résoud, voire faire régresser l'application (Microsoft a ainsi été obligé de publier des correctifs de correctifs...).
Un patch "A" peut également être patché par un autre patch, "B", mais l'installation du patch "B" alors que le patch "A" n'avait pas été installé peut provoquer des instabilités de l'application ou son blocage - il faut donc développer des mécanismes de gestion hiérarchique et temporelle des patches ainsi que des mécanismes de localisation des textes à modifier s'ils ont été déplacés... Certains de ces mécanismes sont connus sous les noms de "context diffs" ou "unified diffs" ou "unidiffs".
Patch ou PlugIn
Les difficultés évoquées ci-dessus pourraient être levées en abandonnant le mécanisme des patchs au profit d'une méthode d'écriture totalement différente des applications, basée sur des mécanismes de greffons ("plugins" en anglais). Ceci doit être pensé au moment de la conception de l'application et de son architecture. Des applications vieillissantes ou trop répandues pour être chamboulée de fond en comble ne sont pas éligibles aux mécanismes des plugins - c'est le cas de Windows. Des applications comme Firefox sont "pensées" plugin dès leur conception et des modifications d'un plugin ne touchent que le plugin.
Un patch ne doit pas être confondu avec un "plugin" : un patch est un bout de code qui vient en remplacement d'un autre bout de code au beau milieu d'une application - un plugin est un bout de code autonome que l'application d'origine utilisera (appellera), si le plugin est présent, grâce à un mécanisme particulier de reconnaissance dynamique.
Service Pack.
Les éditeurs de grands logiciels sortent, de temps en temps, des packs cumulatifs de plusieurs patches pour une application, sous le nom de Service Pack (en abrégé : SP). Par exemple, Windows XP a connu les SP1 (9 septembre 2002) puis SP1a le 3 février 2003 (retrait de la machine virtuelle Java suite au procès intenté contre Microsoft par Sun Microsystems), puis SP2 le 6 août 2004 et sera en SP3 le 24 mars 2008.
Patch est un mot d'origine anglophone désignant un "bout de code" modifiant le code originel d'un programme. Des termes francisés, comme "rustine", sont proposés mais sont peu ou pas usités dans le milieu. Le terme "correctif" est un peu plus souvent employé en français.
Nota : pluriel anglais = patches et pluriel francisés = patchs. Un verbe à été créé pour désigner l'action d'appliquer un patch : "patcher".
Origine du mot Patch
Le mot "Patch" usité actuellement pour désigner un correctif trouve son origine dans le nom d'un programme Unix écrit par Larry Wall et publié en mai 1985 (Larry Wall, linguiste et non pas programmeur, sera l'auteur, deux ans plus tard, du langage Perl. Il travaille toujours au développement de Perl, de Patch et de "rn" (un lecteur de news). Il est l'auteur, édité chez O'Reilly, de "Programming Perl" ("Programmation en Perl"), connu aussi sous le terme de « Camel Book ».
Le programme "Patch" est un programme qui permet de prendre, en entrée, un fichier appelé "diff" (produit manuellement ou automatiquement - plusieurs programmes produisent des fichiers "diff" dont Diff, Subversion, CVS, RCS). Ce fichier, en texte pur (parfaitement lisible par un humain) contient les "différences" entre une version et une autre d'un texte quelconque (de ce point de vue, le code source d'un programme est un texte quelconque). Les différences (appelées désormais "le patch") sont appliquées au texte pour le modifier d'une version vers une nouvelle version. C'est l'usage intensif fait par les programmeurs du programme Patch qui a donné le nom de Patch au correctif lui-même, au delà du programme servant à appliquer le correctif.
Intérêt des Patches
Pourquoi distribuer des patchs corrigeant une application plutôt que de distribuer l'application corrigée elle-même ? Tout simplement parce que le patch est beaucoup plus petit à faire circuler que le programme entier et aussi parce que l'on peut choisir d'installer ou de ne pas installer tel ou tel patch, en fonction de critères propres à chacun, dans une application affectée de plusieurs patch.
Patch ou Binary patches ?
Un patch est normalement distribué sous forme d'un fichier contenant du texte parfaitement lisible par l'humain dont le code source (dans le langage d'écriture d'origine du logiciel modifié), des ordres (localiser telle ligne, ajouter ou remplacer etc. ...) et des commentaires. Il faut, pour l'appliquer (le rendre actif), le placer au bon endroit dans le code source du logiciel à patcher et, si l'on est dans un langage compilé et non pas interprété, il faut recompiler le tout (puis exécuter toutes les phases de post-compilation - édition des liens etc. ...). Inutile de dire que ceci ne concerne que les informaticiens développant des applications - les programmeurs - et pour des applications dont le code source peut être dévoilé.
Les "patches" généralement connus par le public (les "patches" de Windows, par exemple), n'ont rien à voir avec les "patches" d'origine. Ce sont des "Binary patches" (des patchs en binaire) - des programmes exécutables. Ils sont distribués sous forme d'un bout de code parfaitement illisible et concernent des logiciels dont le code source est "fermé" (secret - propriétaire - le code source ne doit pas être dévoilé). Ils viennent en remplacement d'un morceau du code exécutable d'une application déjà installée (ou en remplacement total de celui-ci). Un mécanisme implante ce bout de code au bon endroit (ou met le code de remplacement à l'extrémité du code actuel de l'application et implante une instruction qui dirige vers ce nouveau code à utiliser (tout en abandonnant l'ancien code, inutilisé, en place dans l'application - ce qui n'est pas sans poser des problèmes de maintenance et de relecture par de nouveaux programmeurs qui interviendraient sur un tel code "embrouillé" auquel ils n'ont pas participé initialement).
Des patches pour quoi faire ?
S'il est vrai que les patches sont, le plus souvent, des correctifs (on corrige un problème, une erreur, une faille de sécurité...), ils ne servent pas qu'à cela. Ils permettent également l'implantation de nouvelles fonctionnalités, le remplacement ou l'adjonction d'éléments graphiques, l'accélération d'une fonction, l'amélioration du confort d'usage etc. ... On peut tout faire en "patchant" une application, y compris la "cracker" ou y injecter un parasite...
Patches à problèmes et problèmes de patches
Les patchs posent parfois des problèmes car, leur nombre grandissant, ils peuvent se gêner mutuellement (interférer entre eux ou, pire, littéralement s'écraser les uns les autres - se marcher sur les pieds) et l'application fini par ressembler à un patchwork (comprenez, par là, que l'on ne sait plus quel bout de code fait quoi etc. ...).
Un patch mal écrit (ou trop rapidement écrit, dans la précipitation, afin de corriger dans l'urgence une faille de sécurité...) peut introduire plus de nouveaux problèmes qu'il n'en résoud, voire faire régresser l'application (Microsoft a ainsi été obligé de publier des correctifs de correctifs...).
Un patch "A" peut également être patché par un autre patch, "B", mais l'installation du patch "B" alors que le patch "A" n'avait pas été installé peut provoquer des instabilités de l'application ou son blocage - il faut donc développer des mécanismes de gestion hiérarchique et temporelle des patches ainsi que des mécanismes de localisation des textes à modifier s'ils ont été déplacés... Certains de ces mécanismes sont connus sous les noms de "context diffs" ou "unified diffs" ou "unidiffs".
Patch ou PlugIn
Les difficultés évoquées ci-dessus pourraient être levées en abandonnant le mécanisme des patchs au profit d'une méthode d'écriture totalement différente des applications, basée sur des mécanismes de greffons ("plugins" en anglais). Ceci doit être pensé au moment de la conception de l'application et de son architecture. Des applications vieillissantes ou trop répandues pour être chamboulée de fond en comble ne sont pas éligibles aux mécanismes des plugins - c'est le cas de Windows. Des applications comme Firefox sont "pensées" plugin dès leur conception et des modifications d'un plugin ne touchent que le plugin.
Un patch ne doit pas être confondu avec un "plugin" : un patch est un bout de code qui vient en remplacement d'un autre bout de code au beau milieu d'une application - un plugin est un bout de code autonome que l'application d'origine utilisera (appellera), si le plugin est présent, grâce à un mécanisme particulier de reconnaissance dynamique.
Service Pack.
Les éditeurs de grands logiciels sortent, de temps en temps, des packs cumulatifs de plusieurs patches pour une application, sous le nom de Service Pack (en abrégé : SP). Par exemple, Windows XP a connu les SP1 (9 septembre 2002) puis SP1a le 3 février 2003 (retrait de la machine virtuelle Java suite au procès intenté contre Microsoft par Sun Microsystems), puis SP2 le 6 août 2004 et sera en SP3 le 24 mars 2008.
| Historique des révisions de ce document : |
|
Historique
|
Rédigé en écoutant :
Music
Music