XPCOM

Une architecture multi-plateformes

L'architecture introduite par XPCOM a été conçue de sorte à être multi-plateformes. Ainsi, une même application doit pouvoir être exécutée de la même manière sous Microsoft Windows, sous Linux, sous MacOS... Plus généralement, tout système d'exploitation disposant d'un compilateur C++ et d'un interpréteur Perl permet la création d'applications basées sur XPCOM.

Les systèmes d'exploitation qui supportent l'architecture XPCOM sont très nombreux :

Problèmes de portabilité

Le problème de la portabilité est délicat à appréhender en informatique, et la communauté Mozilla y apporte des solutions.

Il faut tout d'abord distinguer deux types de langages de programmation :

Portabilité

La première différence entre ces deux classes de langage concerne la diffusion des composants. En effet, supposons qu'un développeur conçoive un composant sous Linux. Il semble logique de vouloir diffuser ce composant afin d'en faire profiter un maximum de personnes. Toutefois, il est fort peu probable pour que le composant soit beaucoup utilisé si l'utilisateur final doit le compiler.

C'est effectivement un des problèmes du langage C++ que de nécessiter une compilation propre à la plateforme de destination. Certes, cette méthode présente l'avantage de créer des programmes optimisés. En revanche, il n'est pas possible, pour un utilisateur, de télécharger le composant et de le lancer sans repasser par une étape de compilation. De plus, cela nécessite la compilation de l'ensemble de l'architecture XPCOM.

A l'inverse, les langages de programmation de la seconde classe pallient ce problème grâce à une couche de liaison entre le programme et le système d'exploitation. Ainsi, il existe, au sein de Mozilla, un interpréteur qui permet l'exécution de programmes écrits en JavaScript. Dans le cas du langage Perl, l'interpréteur Perl se charge de la liaison entre le programme et l'OS. Enfin, Java exploite quant à lui une architecture de machine virtuelle.

Portabilité du code source

La seconde différence réside dans la portabilité du code source. Tous les langages ne sont pas armés de la même manière face à ce problème.

Dans les langages de la seconde classe, les types de données et les ressources systèmes sont ceux proposés par le langage. L'interpréteur ou la machine virtuelle sous-jacente ont la charge de proposer une vue du système qui est la même pour tous les systèmes d'exploitation.

Dans les langages de la première classe, en revanche, le code source fait directement appel aux ressources systèmes et utilise les types de données propres à la machine cible. Par exemple, le code C++ utilise des appels système pour exploiter le réseau (ces appels système diffèrent d'un OS à l'autre), et utilisent des types de données qui sont ceux du processeur (le type int, par exemple, n'est pas le même sur toutes les plateformes).

Solutions

Pour pallier ces deux problèmes majeurs, la communauté Mozilla a mis au point des règles d'écriture de code C++.

La bibliothèque de fonctions Netscape Portable Runtime (NSPR) (http://www.mozilla.org/projects/nspr/index.html) doit impérativement être utilisée par tous les composants inclus dans Mozilla. Cette bibliothèque wrappe tous les appels système. Cela signifie que la libc, par exemple, ne doit pas être utilisée par le développeur, mais la NSPR propose des fonctions équivalentes et garantie que ces fonctions auront le même comportement sur toutes les plateformes.

Par ailleurs, la NSPR redéfinit les types primitifs de données, et garantie par exemple que le type PRUint32 sera un entier 32 bits non signé, et ce, quelle que soit la plateforme.

La NSPR définie également des structures de données d'assez haut niveau, telle une table de hashage.

Enfin, des règles sont définies dans le document C++ portability guide. Ces règles définissent la manière d'écrire du code qui sera compris de la même manière par tous les compilateurs. Par exemple, le document indique qu'il ne faut ni utiliser les exceptions, ni les classes templates (sauf pour les smart pointers).