Vous venez de télécharger une mise à jour riche en fonctionnalités pour votre application open source préférée. Tout fonctionne bien et vous l'utilisez sur vos autres appareils. Il est donc temps de le déployer également sur ceux-ci.
Sauf que votre nouvel ordinateur portable Linux brillant n'est pas compatible avec votre package d'installation Windows. Et votre tablette Android ? iPhone ? PS4 ? Pourquoi ne pouvez-vous pas simplement prendre ce logiciel et l'utiliser où bon vous semble ? Explorons différents obstacles au rêve de "acheter une fois, courir n'importe où".
Comprendre pourquoi les logiciels ne fonctionnent pas sur tous les systèmes d'exploitation nécessite un peu (juste un peu, je le promets) de savoir comment les logiciels sont créés.
Dans un flux de développement logiciel très basique pour ordinateur de bureau, serveur et mobile (c'est-à-dire pas Web), un programmeur :
C'est une combinaison des première et deuxième étapes qui nous intéresse ici. Le processus de compilation logiciel, ou le transformer du code en un et zéro qu'un ordinateur comprend (langage machine) est complexe. Nous n'entrerons pas dans les détails, mais il est utile de comprendre à un niveau élevé ce qui se passe.
Un point important à comprendre est qu'un système d'exploitation n'est pas une entité unique. Il est plutôt composé de couches de logiciels.
Le noyau d'un système d'exploitation est responsable de la communication avec le matériel de l'ordinateur. Le logiciel communique ses commandes au noyau, qui à son tour envoie des commandes au matériel pour (par exemple) lire un fichier sur le disque dur ou dessiner une fenêtre à l'écran. Il coordonne essentiellement toutes les informations (qu'il s'agisse de données stockées, de calculs ou d'entrées utilisateur) entre le matériel et divers logiciels. Le noyau met toutes ces fonctionnalités à la disposition des logiciels via des appels système .
Le noyau de chaque système d'exploitation implémentera les appels système différemment, en fonction de ceux qui sont disponibles, de leur nom ou des options qu'ils prennent. Par conséquent, le logiciel doit prendre en compte les appels système pris en charge par le noyau de chaque système d'exploitation qu'il cible. L'appel système que vous utilisez pour envoyer des données au GPU sous Linux peut avoir un nom différent, une liste d'informations que vous devez fournir, ou les deux sous Windows. Cet appel exact peut même ne pas être là du tout.
Dans de nombreux cas, le logiciel n'appelle pas directement le noyau. Au lieu de cela, il appelle les bibliothèques système , ou des collections de fonctions de base. Les bibliothèques existent donc (par exemple) chaque programme qui enregistre des fichiers sur le disque dur n'a pas besoin d'écrire une fonction pour le faire. Au lieu de cela, il se contente de liens vers une bibliothèque système et utilise une fonction existante. La bibliothèque GLibC pour Linux en est un excellent exemple, tout comme les fichiers .DLL de l'API Win32 ou le contenu du répertoire /System/Library d'un Mac.
Les bibliothèques système agissent comme une sorte de traducteur entre les applications et le noyau pour les tâches de routine. Les applications effectuent des appels de fonction à ces bibliothèques, qui gèrent une grande partie des détails de bas niveau. Ils peuvent également effectuer des appels système au noyau pour plus de commodité. Comme vous l'avez peut-être deviné, cela signifie que ces bibliothèques sont écrites pour un noyau particulier et ne peuvent donc pas être utilisées sur des systèmes d'exploitation avec des noyaux différents.
Le dernier obstacle au logiciel universel est le format des fichiers exécutables pour les systèmes d'exploitation. Un système d'exploitation s'attend à ce que les fichiers qu'il exécute suivent un format de fichier binaire particulier. Par exemple, les fichiers ELF (Executable and Linkable Format) qui s'exécutent sur des systèmes d'exploitation tels que Linux et FreeBSD doivent spécifier certaines propriétés du fichier dans certains octets, comme indiqué dans l'image ci-dessous.
L'interface binaire d'application (ABI) montré capable revêt une importance particulière. Une combinaison des appels disponibles à partir des bibliothèques du processeur, du noyau et du système, une ABI est similaire à une interface de programmation d'application (API) en ce qu' il définit comment deux programmes communiquent entre eux. Mais l'API est quelque chose qu'utilisent les programmeurs (humains) dans le code source pour indiquer que deux logiciels devraient Parler l'un à l'autre. L'ABI est ce qui leur permet réellement de le faire une fois que le logiciel est compilé et exécuté. Chaque système d'exploitation implémente un ABI particulier, qui peut ou non changer entre les versions de ce même système d'exploitation.
En général, les systèmes d'exploitation implémentent leur propre ABI, déterminée par une combinaison du type de processeur, du noyau et de toute bibliothèque système standard. Mais parfois, un système d'exploitation en implémentera plusieurs. FreeBSD prend en charge les binaires Linux, par exemple, car il fournit une ABI Linux en tant que module complémentaire du noyau FreeBSD (au lieu du noyau Linux). Ceci est différent des programmes de virtualisation tels que VMWare ou VirtualBox, qui utilisent un logiciel pour simuler une machine entière (matériel et tout). En conséquence, ce type de compatibilité ABI est plus rapide, mais nécessite beaucoup plus d'efforts à maintenir. C'est pourquoi c'est rare, bien que Microsoft ait récemment compris l'intérêt de le faire.
Sur la base de ce qui précède, nous avons appris que les développeurs écrivent des logiciels pour un et un seul type de système cible. Sauf quand ils ne le font pas. Il existe de nombreuses applications que vous pouvez télécharger et exécuter sur un Mac, puis copier et exécuter sur Windows, et peut-être même copier à nouveau et exécuter sur Linux sans problème. Comment est-ce possible ?
Est-ce que j'ai menti jusqu'à maintenant ?
Il s'avère qu'il existe une catégorie de logiciels qui, à première vue, semblent "fonctionner partout". Vous pouvez le télécharger et l'exécuter sur n'importe quelle plate-forme prise en charge, le mot clé étant « pris en charge ». En fait, vous téléchargez le code source de l'application, tandis qu'une autre application (l'interpréteur ) exécute en quelque sorte le code source directement en temps réel. C'est quelque chose d'une simplification excessive, alors regardons exactement comment cela fonctionne avec quelques langues.
Lorsque Java est sorti pour la première fois, sa promesse était (littéralement) "écrire une fois, exécuter n'importe où". L'idée était de créer des applications en utilisant des fonctions Java pour enregistrer des fichiers, effectuer des calculs ou créer une fenêtre d'application. Puis un environnement d'exécution Java (JRE) pour chaque plate-forme informatique prise en charge, exécuterait le code et le traduirait en fonctions natives du système d'exploitation. L'astuce de Java est donc qu'il ne s'exécute pas "directement" sur le système d'exploitation. Il s'exécute dans une partie du JRE appelée Java Virtual Machine et c'est ce qui s'exécute sur le système d'exploitation.
En insérant cette couche logicielle supplémentaire entre l'application et le système d'exploitation, Java vous permet de vous concentrer sur un ensemble de fonctions identiques sur tous les systèmes d'exploitation. Vous dites à Java ce que vous voulez faire et laissez la JVM de votre système se soucier de la manière de le faire. L'image ci-dessous montre cela en action, où Java Desktop Application Framework de JIDE Software affiche la même application pour Mac (en haut), Windows (au milieu à gauche), "pure Java" (au milieu à droite) et Linux (en bas).
Les programmes Java ne se "compilent" pas précisément en temps réel. Au lieu de cela, le compilateur Java les rendra en "bytecode". Vous pouvez considérer le bytecode comme un programme à moitié cuit. Lorsque le développeur publie l'application, elle est compilée autant que possible sans savoir sur quel système d'exploitation elle va s'exécuter. Lorsque vous le lancez réellement, la JVM "fait cuire le reste du chemin" pour s'adapter aux fonctions particulières du système d'exploitation hôte.
Un langage interprété populaire est Python. Lorsque vous exécutez un script Python, l'interpréteur Python traduit le code en instructions pour le système d'exploitation. Il peut également fonctionner de manière similaire à Java :lorsque vous "importez" du code de l'extérieur de votre application, il est compilé en bytecode la première fois qu'il est exécuté. Ensuite, l'interpréteur saura si, lors des exécutions suivantes, le code d'origine a changé, auquel cas il le recompilera avec un nouveau bytecode.
Un sous-produit intéressant de cette exécution "à la demande" est que vous pouvez utiliser l'interpréteur pour développer vos scripts de manière interactive. En tapant simplement "python" sur la ligne de commande, vous démarrerez l'interpréteur, et vous pourrez exécuter du code et voir les résultats immédiatement.
Cela signifie que les développeurs peuvent jouer et modifier les choses "en direct". Ensuite, une fois qu'une ligne de code fait ce qu'ils veulent, copiez-la et collez-la dans un fichier de script (ce qui est beaucoup plus efficace que le cycle "code-compilation-test" que les programmeurs de langage non interprété doivent faire).
Malheureusement pour les utilisateurs, l'industrie technologique n'a pas développé de format vraiment "universel". Et il se peut qu'il ne le fasse jamais. L'introduction de ces types de normes aboutit souvent à une solution du "plus petit dénominateur commun", avec des concessions dans l'intérêt de l'approbation de tous.
Qu'en pensez-vous ? Préférez-vous avoir un logiciel universellement compatible, même si cela signifie qu'il n'est pas aussi bon ? Ou êtes-vous d'accord avec le système d'exploitation que vous utilisez et n'avez-vous aucun intérêt pour les applications d'autres plates-formes ? Faites-le nous savoir ci-dessous dans les commentaires !
Crédits image :Masterchief_Productions/Shutterstock
